IBM Mainframe Forum

Sure it will, just add the 'gdgnt' option to set the S99GDGNT flag in the S99FLAG1 field. See Table 5. Additional keys used for dynamic allocation in the 'Using REXX and z/OS UNIX System Services' manual.
sample:

These users thanked the author willy jensen for the post:

Jeff R (Tue Jan 03, 2023 9:59 pm)

now I'm trying to write the contents of the modified ISPSLIB member to the newly created GDS.
After the ISPSLIB member is modified, CLOSED and FREED, I reallocate it as DD2 and write to the GDS (DD1) :

ADDRESS TSO "ALLOC F(DD2) DA("FILE_NAME") SHR"
"EXECIO * DISKR DD2 (STEM RECORD. FINIS"
DO I = 1 TO RECORD.0
QUEUE RECORD.I
END
"EXECIO * DISKW DD1 (FINIS"
/* "EXECIO 0 DISKR DD1 (FINIS" */
/* "EXECIO 0 DISKR DD2 (FINIS" */
"FREE DDNAME(DD1)"
"FREE DDNAME(DD2)"
EXIT

the issue I get is I have to hit enter a second time for the REXX to complete
(the commented EXECIOs are just because I moved the FINIS to the DISKR/DISKW for DD1/DD2)

There really is no reason to copy the stack to a stem, you can use the stack directly in the write, i.e.:

Note the NEWSTACK and DELSTACK commands, they are there just in case you already have something in the stack.
You might also get away with using the REPRO command, i.e.

Note that the REPRO command does accept INDATASET(dsn) and OUTDATASET(dsn), so you can sometimes avoid the ALLOCATEs, but it allocates using DISP=OLD.

These users thanked the author willy jensen for the post:

Jeff R (Tue Jan 03, 2023 10:47 pm)

I have to hit enter a second time for the REXX to complete

Nothing in the code shown should do that. Put in some SAYs or some TRACE R to determine where that extra prompt occurs.

I went with the first option and that did eliminate the need to press ENTER a second time

And then again - never ever use the '*' in EXECIO DISKW, always put a number in there. The '*' will stop when a null record is encountered, which might not be what you want.

Not sure if this is the appropriate place to ask this...
I have Skeleton (ISPSLIB) members with specific Jobnames (example UL04LBOX) but when the are submitted (via TSO SUBMIT) they always have my userid (UL04JDR) and an 'X' (i.e. UL04JDRX) as the Jobname
How do I get it to use the ISPSLIB member Jobname ?...I tried TSO SUBMIT file_name NOUSER but no difference

re: jobname

I doubt that it is an ISPSLIB issue. Are you able to submit a job from a PDS, with a non-userid jobname?

Or do a submit of the ispslib member directly from ispf 6?
Circumvention - build the job directly to INTRDR:

One advantage with the ISPFILE -> INTRDR approach is that you are not limited to 80 bytes lrecl.