IBM Mainframe Forum

I have a script that needs to read the contents of a dataset into a JCL variable. The contents of the dataset will change with every run of the job. I've tried sourcing it in and setting it equal to the variable and Zeke scheduling variables but can't get either to work. Is there a simple way to get this data into a variable?

Hello and welcome to the forum,

Suggest you show an example of what you have and what you want done with it.

You cannot change already running jcl "on the fly".

What you can do is read the dataset, use it to modify/create the needed jcl, then submit the generated jcl thru the internal reader.

I don't have a good example I can copy in but I can explain the process better. We have start with a dataset that contains information for a vendor. The vendor requires a date/time stamp in the filename when it's uploaded to their server. They also require encryption. The dataset with vendor information is sent to Megacryption for encryption and the resulting filename is pushed into a dataset. We need to use this filename to transmit the file to the vendor. This wouldn't be generating JCL on the fly; rather, it would be reading in a static DSN containing variable data to be used later in the script. What I need is the equivalent of a cat statement in Unix: variable=`cat file_containing_dynamic_filename`

Hello,

It will help if you post the "script" that is being used to transmit the file. De-sensitize as necessary (i.e. ip-address, host, userid, etc).

We use various utilities (SAS and File Aid mostly) to customize the file names in a PDS member where the FTP step of the job that runs after the customization step points to that file member.

Read the dataset and generate a JCL SET statement for the output:

// SET DSN='SOME.DATASET.NAME'

and write that into a member of a PDS, i.e. 'PROD.PARMLIB(JCLPARM)'

then use that PDS in the subsequent job (a JCLLIB statement may be necessary):

//JOBNAME JOB (.....
//*
// JCLLIB ORDER=PROD.PARMLIB <= maybe
// INCLUDE MEMBER=JCLPARM
//*
...

INCLUDE STATEMENT.

JCLLIB STATEMENT.

SET STATEMENT.
Now you can properly use the variable &DSN anywhere in that job.

JCL is fully expanded before the job actually starts. I get the sense that what harryseldon really wants is to resolve the data set name while the job is executing. This is not a JCL issue, because the JCL for the job has been fixed and cannot be altered. This is a dynamic allocation issue. There are several ways to handle this; the most popular is a function called BPXWDYN. BPXWDYN takes a character string that is similar to, though not identical to, the TSO ALLOCATE or FREE commands. The documentation for BPXWDYN is available in IBM documentation, though it is very hard to find, and I have found it to be incomplete at times.

DYNALLOC (SVC99) can be used to allocate the output dataset with a name constructed by the program as opposed to hard coded in the JCL. Once the DYNALLOC is issued and a successful return is received, the dataset can then be OPENed, PUT to and CLOSEd. Deallocation will take place at the end of step automatically or accomplished using the SVC99 again. DYNALLOC is documented in the Authorized Assembler Services Guide. An online overview with links to the relevant information can be found at http://publib.boulder.ibm.com/infocente ... ynrtcd.htm
It's not too tricky but don't try to get overly creative.

Schubie's discussion about dynamic allocation is valuable, but it requires Assembler knowledge to use it. This is why I discussed BPXWDYN, which is readily available to high level or some ways Rexx can be used.
There are a few JCL constructions, such as relative generations, that are best avoided in dynamic allocation (including BPXWDYN), and some tape related combinations that can't be done at all. For example, JCL like this -can not be done in dynamic allocation. The SORTIN DD statement can be done in dynamic allocation, but the UNIT=AFF business in the SORTOUT DD statement to use the same drives as were uses by the SORTIN DD statement cannot be done in dynamic allocation. There are other tape related, though uncommon, things you can do in JCL that can't be done in dynamic allocation, though a clever Assembler programmer can replicate them.

Now I've been doing MVS dynamic allocation for more than 30 years, so it doesn't scare me, but most people (and organizations) are terribly afraid of Assembler, so it can't be used much of the time.