Page 1 of 1

Dynamic allocation using COBOL

PostPosted: Wed Mar 24, 2010 3:40 pm
by Nireesha234
I'm trying to allocate the file dynamically using the pgm 'BPXWDYN' in COBOL. But, I'm receiving the following error:

IGZ0037S The flow of control in program B4453DYN proceeded beyond the last line of the program.
CEE3250C The system or user abend U1037 R=00000000 was issued.
From compile unit CEEWUCHA at entry point CEEWUCHA at compile unit offset +0000016C at entry offset +0000016C
at address 19E0F794.

My pgm looks like this:

01 CONSTANTS.
05 BPXWDYN-PGM PIC X(008) VALUE 'BPXWDYN '.
05 ALCT-LIT-SRC PIC X(100) VALUE
'ALLOC DD(B4453.TEST) NEW CATALOG SPACE=(CYL,(1,2))
- 'UNIT(SYSDA) BLKSIZE(800) LRECL(80) RECFM(F)'.
05 FREE-LIT-SRC PIC X(016)
VALUE 'FREE FI(SYSUT1A)'.

01 WORK-AREAS.
05 BPXWDYN-PARM.
10 PIC S9(004) COMP-5 VALUE +100.
10 BPXWDYN-PARM-TXT PIC X(100).

MOVE ALCT-LIT-SRC TO BPXWDYN-PARM-TXT

CALL BPXWDYN-PGM USING
BPXWDYN-PARM
END-CALL

IF RETURN-CODE = 0
CONTINUE
ELSE
DISPLAY 'RETURN CODE NOT 0'
END-IF.

Is there something missing in the code?

Re: Dynamic allocation using COBOL

PostPosted: Wed Mar 24, 2010 5:18 pm
by Robert Sample
Your BPXWDYN command is invalid. Instead of SPACE=(CYL,(1,2)) you need CYL SPACE(1 2) in the allocation command.

The IGZ0037S message indicates your program didn't hit a STOP RUN, EXIT PROGRAM, or GOBACK before ending -- this can cause issues.

Re: Dynamic allocation using COBOL

PostPosted: Wed Mar 24, 2010 5:23 pm
by Robert Sample
I just noticed that you're not giving the DD name in your ALLOC command -- how on earth do you expect it to work without a key piece of data?

Re: Dynamic allocation using COBOL

PostPosted: Wed Mar 24, 2010 11:20 pm
by dick scherrer
Hello,

Is there some reason this was posted twice?

The "other" is being deleted. . .

d

Re: Dynamic allocation using COBOL

PostPosted: Thu Mar 25, 2010 10:52 am
by Nireesha234
My program works. Thank you.

Re: Dynamic allocation using COBOL

PostPosted: Thu Mar 25, 2010 6:28 pm
by Robert Sample
Glad to hear it is working!

Re: Dynamic allocation using COBOL

PostPosted: Tue Mar 30, 2010 11:59 am
by Nireesha234
In my program I need to create n number of files about which we wouldn't know before the execution of the program.
Hence, I've created GDGs in the dynamic COBOL program.
But, the problem here is, I'm not able to assign different GDG versions to the same DD.
Hence I will need to create n number of SELECT statements in the environment division.
Is there a way to dynamically pass the contents to the ASSIGN clause in the ENV division? (thru subroutine or main program)

This is how I'm handling creating the GDG versions:
05 WS-ALLOC.
10 WS-ALLOC-REC1 PIC X(33) VALUE
'ALLOC DD(SYSIN1) DA(B4453.TEST2(+'.
10 WS-NUMBER PIC 9. ===> I keep adding WS-NUMBER to create new GDG versions.
10 WS-ALLOC-REC2 PIC X(106) VALUE
')) NEW CATALOG CYL SPACE(1,2) UNIT(SYSDA) BLKSIZE(30008)
'LRECL(30004) RECFM(V,B) REUSE'.

This is what I'm planning on doing:
I'll be dynamically changing the DD to SYSIN1 to SYNSIN2....SYSIN5....etc in the above WS variable WS-ALLOC-REC1 (ALLOC DD(SYSIN1) DA(B4453.TEST2(+'.)

I should be able to change the parameter in the ASSIGN clause from SYSUT1 to SYSUT2....etc..dynamically while the pgm is executing
SELECT OUT-FILE
ASSIGN TO SYSUT1
FILE STATUS IS WS-OUT-FILE-STAT.

Is it possible?
Any ideas to get this done will be highly helpful.

Re: Dynamic allocation using COBOL

PostPosted: Tue Mar 30, 2010 5:08 pm
by Robert Sample
Terminology is critical in IT. For a GDG, both version and generation are valid terms but mean extremely different things. You said
But, the problem here is, I'm not able to assign different GDG versions to the same DD.
but the context of the reference is generation, not version. This confuses your question, and does not impress responders with your level of understanding.

You can write the SELECT statements for all nine SYSINx files -- the system won't actually attempt to access them until opened. You cannot, however, decide at run time that you need six SELECT statements since the COBOL code must be compiled and the number of SELECT statements will be fixed when the compile is done.