INPUT CARD FROM JCL - OPTIONAL

, ,
1

The subject reminds me of Elaine’s (of Seinfeld) rule: 'CALLING THE NEXT DAY - OPTIONAL!" :slight_smile:

I am making a change to an existing production utility program, said change to include an optional INPUT card:


INPUT JOBCARD   /* this is the code
.......................................
//* THE JCL
//* *******
//CMSYNIN  DD *
LOGON MDCCDEVL
MUT900B1
BYPASS          <--- optional card
//*

I would rather not update the Jobs already in production to add a blank card. However if the card isn’t there the program abends with NAT1124.

Is there a way WITHIN THE NATURAL PROGRAM to handle the missing card so the program doesn’t abend? The “*DATA GT 0” check doesn’t appear to work …

2

Hi “Adam”,

have a look at [url]http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat422mf/parms/objin.htm[/url]

OBJIN controls whether INPUT takes input from CMSYNIN or from CMOBJIN.

Some may say: in my batch jobs program input is always taken from CMSYNIN. But this is in most cases not true; input is taken from the stack where the command line from CMSYNIN has been put. For example

MYPROG PARM1 PARM2 PARM3

executes MYPROG. This will be able to input all the three parameters in the INPUT statement (or less or more, but from the fourth parameter on blanks or nulls are read)

So please check the value of OBJIN and the presence or absence of CMOBJIN.

3

Thanks, Wilfried, for your reply.

However, I did not follow your line of thinking (I did read the link). Are you suggesting that instead of reading the optional input card from CMSYNIN, that I read it from CMOBJIN instead (I am assuming that I leave the usual CMSYSIN DD with the library and program names and add a CMOBJIN DD to the JCL) ? And are you saying that I can test whether the CMOBJIN DD exists in the JCL ?

How about a completely different tack. I know Cobol programs can access parameters passed as PARM=‘xxxx’ on the EXEC PGM= statement. How does Natural access this value passed from the JCL ?

4

Since the optional parameter is new, you don’t need to change existing JCL. Change the new job, the one requiring the new parameter, to

//CMSYNIN  DD * 
LOGON MDCCDEVL 
MUT900B1 BYPASS          <--- option on same card 
//*

Now you can check *DATA.

IF  *DATA > 0 
  THEN 
    INPUT #OPTION 
END-IF
5

Of course, it is possible to provide PARM=, but you can not access it in Natural programs, but Natural will do it for you.

//STEP    EXEC PGM=mybatnat,                         
//         PARM=('PROFILE=myparmmodule',                       
//     'STACK=(LOGON mylibrary;myprogram myparms)')

You can provide multiple commands with parameters in stack. Each command (including the parameters) is delimited by input delimiter, the parameters are preceded by blanks.
The advantage over SMSYNIN is:
As it is no inline dataset, you can see the contents in sd.st or any other product that displays the jcl.

OBJIN determines where to read the input data from. OBJIN is set either in the parameter module (PROFILE=) or in the “PARM=(OBJIN=value…)” or in CMPRMIN containing a line "OBJIN=value).
First, INPUT is taken from the stack, provided in the parm line or in the command line of CMSYNIN. If additional inputs are issued or no program parameters are specified, OBJIN is evaluated:

  • if OBJIN=Y input is taken from CMOBJIN,
  • if OBJIN=N input is taken from CMSYNIN, treating the next line as data instead of command
  • if OBJIN=R input is taken from the first available dataset: if CMOBJIN is specified, input is taken from there, else input is taken from CMSYNIN.
    If INPUT leads to an end-of-file condition, you will get an error.

So, check your JCL and your parameter module for the absence or presence of the parameter OBJIN, and the dataset CMOBJIN.

6

Thanks, Wilfried, for your kind response.