Any way to pass JCL variables to the STDENV script?

[jvanparijs]

Hi,

We currently run a Java application as a z/OS STC. We start a shell script through BPXBATCH, that sets all variables, and ultimately runs our Java class. Some time ago, I tested this with the JZOS launcher, integrating the JZOS set up in our script and that worked ok.
But... in the mean time, we've parameterised some of the script processing, and we now pass an argument to it, as follows:
//CRESRQAG EXEC PGM=BPXBATCH,REGION=0M,
// PARM='SH &HOME./requestAgent &LOGPATH.&LOGDIR'
allowing to change this value when starting the task.
Note that we need the variable in the shell script...

Is there any way that we could get the LOGPATH and LOGDIR variables passed to the STDENV script, or run the STDENV script with arguments?

[dovetail]

You can pass a JCL variable into the STDENV shell script via an environment variable which you set via LE parms. For example:

// EXEC EXJZOSVM,
// JAVACLS='com.my.pkg.MyClass',
// ARGS='my args to main class',
// LEPARM='ENVAR(LP=&LOGPATH,LD=&LOGDIR)'
//STDENV DD *

//

This will set the LP and LD environment variables when the program starts, so that they can be used by your STDENV shell script. The LEPARM proc argument simply sets the before-slash part of the PARM=, which z/OS uses to set LE parms before the program is started.

A possible problem with this will be that you will quickly exceed to total length of the PARM= keyword, which for 64-bit z/OS is still limits to 100 bytes. You can get around this with the JZOS launcher by using the MAINARGS DD to pass in the name of your main class and arguments. Something like this:

// EXEC EXJZOSVM,
// LEPARM='ENVAR(LP=&LOGPATH,LD=&LOGDIR)'
//MAINARGS DD *
com.my.pkg.MyClass some args to main
and some more args to main
//STDENV DD *

//


Another option if you are using a started task, is to just have your java program read the options on the MVS START command when it starts.
See the javadoc ZUtil.setMvsCommandCallback() method and MvsCommandCallback.handleStart() methods for more information.

I hope this is helpful to you.

[jvanparijs]

Thanks for - again - the quick and to the point answer.

In our case we'll need to stick with the LEPARM argument as we need to pass the variables to the script, not directly to our Java main class. So I guess we'll have to live with the severe length restriction, but that's something you can't do anything about.

Moving the class name (and eventual arguments) to the MAINARGS DD allows to remove those arguments from the PARM all toghether. Allowing for the trace option, and the fixed text of the ENVAR() LE option and the slash, this leaves 90 bytes (if my arithmetics are still Ok) for the variable names and values.

To save on the scarce space, one can always use a one character variable name, and concatenate the JCL variables into one USS variable, leaving it up to the script to split the values again if necessary.

[dovetail]

Your analysis seems right to me.

I heard somewhere that IBM has accepted a requirement to remove the length restriction on the PARM= field, but I don't know if it has been announced. Maybe someone else in the forum knows for sure.

[fredroe]

One comment I have is that if you are a "z/OS traditionalist" meaning you know rexx, then that can be used with BPXBATCH. We use it all the time for all our USS type script work.