JCL to Cobol to JCL?

NoSleep319 · Posted: Mon Apr 11, 2016 11:18 pm

I need some high level analysis in a mainframe scenario. There is a table that will be populated with mainframe IDs that need to be either deleted or created, depending on specific columns being used as flags. A scheduled job will be running ever 15 minutes to find updates to this table and react to them.

I am somewhat new to Cobol and JCL, but my proposal was to generate a list of ADDUSER and CONNECT statements based off of the table query through the Cobol program, store those commands in a dataset, and kick off another JCL to execute the statements in that dataset.

My main question is whether this sounds like a sound approach to the problem. Does anyone see a faster/cleaner solution to pursue?

My other question is what would be cleaner, JCL somehow executing the commands via some avenue, or Cobol pulling a routing template for the JCL, adding the commands in the SYSIN, and then executing that new dataset?

Overall, I want to make sure this is being written in the most efficient way, but I also want to use this as learning experience to be able to anticipate future mainframe solutions.

Thank you for your help, and I will try to answer any questions if I can.

Robert Sample · Posted: Tue Apr 12, 2016 12:03 am

Your approach seems fairly clean -- you would execute batch TSO (IKJEFT1A or IKJEFT01) to execute the commands, and if the COBOL program specifies the data set as DISP=OLD, you could just have the commands executed in the next step without having to create another job. As long as there's not too much variation in the ids to be created (OMVS or not probably being the big one -- but there's a lot of RACF options), your approach will work well.

Execute the command file by providing it as input to a TSO step -- you really don't want to add learning the RACF API to learning about COBOL and JCL.

NoSleep319 · Posted: Tue Apr 12, 2016 12:15 am

Having one job with multiple steps does sound more efficient. Thank you for your help! So logically, the scheduled job would call the Cobol program, which would query the table, generate statements for all new instances and store them in a dataset file, then, in the next step, execute those commands through IKJEFT1A or IKJEFT01.

If I wanted to update the table after those statements were executed to timestamp as successful, that would have to be another step, and a separate Cobol program, correct?

steve-myers · Posted: Tue Apr 12, 2016 12:18 am

In most installations, adding a new user requires much more than the RACF ADDUSER command. The good mews is it is usually possible to automate all this in CLIST or a Rexx exec.
Similarly, in most installations, removing a user requires much more than a RACF DELUSER command. Not all of this can be automated in a CLIST or Rexx exec, though the automation when creating the userid can be undone in a CLIST or Rexx exec.

Robert Sample · Posted: Tue Apr 12, 2016 12:36 am

Yes, you could pass the output of the RACF commands to another program and that program could parse the output to identify successes and failures.

As mentioned, though, there is more than just RACF commands for setting up / removing users -- the high-level qualifier for the TSO user, for example, needs to be established.

NoSleep319 · Posted: Tue Apr 12, 2016 12:37 am

I am actually a lot more familiar with Rexx and Clist, but, unfortunately, the company direction and support is toward Cobol. We've created an ID with such authority. Now I just have to utilize it to do so...

This is definitely an opportunity to grow and expand my skills, but knowing a language is one thing, and know 2 languages and figuring out how to fuse them together in just the right way is another beast entirely.

PeterHolland · Posted: Tue Apr 12, 2016 10:41 am

Around 10 years ago I had to do the same not for mainframes but for a few thousand ATM's.

The solution i created was a Rexx with the following inputs :

ATM table
RACF control records for USER definitions
RACF control records for CERTIFICATE definitions
RACF control records for RING definitions

All changeable parameters in the RACF control records contained
variable names that were solved by the Rexx.

The Rexx output was input for the subsequent IKJEFT01 steps.

NoSleep319 · Posted: Tue Apr 12, 2016 7:58 pm

That's pretty interesting! I knew that CICS was used in conjunction with ATM's, but I never new Rexx was. You learn something new every day!

PeterHolland · Posted: Thu Apr 14, 2016 9:17 am

The Rexx has nothing to do with CICS, it is just a vehicle to generate massive loads of RACF control cards.