mainframe jcl -- control order of when jobs run
 

hi, we have been using zeke to schedule 108 jobs but it is starting to be a pain in my ass (it is far more complicated and far less capable than cron).

so i did a few google/duckduckgo searches and i took the initiative to modify the ends of the jobs to look like this:the problem i have now is that i want 2 jobs to run at the same time and i want the next job to run when both jobs finish.

kinda' like using & and the wait command in bash ?

[OT] Dillon's cron
 

[Off Topic] No help for the OP, but for others reading this, Dillon's cron, which is Slackware's default cron daemon, can do this. It is a light-weight cron daemon with some surprisingly smart and useful tricks.

It has been decades since I used in-line TSO commands. If IKJEFT01 supports the OPER command and OPER supports a reasonable set of console commands then you can do what you want this way:

You have jobs A, B, C, and D

Job A submits jobs B, C, and D. B and C are submitted to be immediately runnable. D is submitted at priority 0 and also held.

The last step in job B runs OPER under IKJEFT01 to release job D.

The last step in job C runs OPER under IKJEFT01 to set job D to normal priority.

Back in the day I used have my JCL clerks do this sort of thing using a home grown program which entered operator commands. It is not that difficult to write. If the set of allowable OPER subcommands is not rich enough to do what you want I suggest you roll your own version of a job stream OPER.

-------------------------
Steve Stites

^ thanks can you recommend a jcl site that can help me understand your suggestion a little better ?

:hattip:

See also this page: http://docweb.cns.ufl.edu/docs/d0070/d0070.html about RELEASE.

The statement PRTY=0 on the JOB card has the same effect as a hold. When you change the priority to a positive number the job becomes runnable.

http://publib.boulder.ibm.com/infoce...00/xjbprty.htm

The TYPRUN=HOLD parameter on the JOB card will hold the job until it is released.

http://www.isc.ucsb.edu/tsg/jcl.html#typrunparameter

------------------------
Steve Stites

thanks, seems like i will need to read up to gain some jcl skills. i think my original post is understandable but here is a practical example in bash:now i got to learn how to translate this bash into something the mainframe can understand.

For anything more complex than serial chaining of jobs, your best bet is to use the scheduling software provided on the mainframe. The scheduling software does more than just submit jobs to the system. It also allows you to define the dependencies between jobs and define the success criteria that allows a dependent job to be triggered. You have a job that has a dependency on the successful completion of two other jobs that you want to run concurrently. That is what the scheduling system is there for. I don't have any experience with Zeke, but you should be able to get help from someone who works with batch job scheduling on the mainframe.

If your job log has IAT messages in it, the system is using JES3. If you see $HASPnnn messages, it's JES2. JES2 is far more common than JES3. If the job entry subsystem is JES3, you can try defining a dependent job control (DJC) net. JES2 doesn't support DJC. Even on a JES3 system, DJC may not be enabled. Google it and refer to the IBM manuals if you have JES3.

To serially chain jobs so that one runs immediately after another, your technique using TSO SUBMIT from a batch terminal monitor program (IKJEFT01, IKJEFT1A, IKJEFT1B) might work, but SUBMIT is often subject to installation defined controls imposed via an installation exit. A slightly more generic method is to use IEBGENER and output the next job in the chain directly to an internal reader.

It can include a step to submit the next job in the chain, and so on.

There are games you can play with enqueued data sets to help serialize jobs, but the systems programmers won't like it if you have jobs tying up initiators waiting for a data set to become available.

If you have SDSF, and if you have the requisite authority, you could submit all your dependent jobs on hold as jailbait said, and then use SDSF in batch to find and release them as needed.

But honestly, I'd suggest you make friends with someone in the batch scheduling group and learn how to use your scheduling system.

By the way, cron is available on the mainframe under Unix Systems Services. USS is ignored or minimally configured on very many z/OS systems, so cron may not be set up. Even if it is, you may not have authority to use it. But it's worth checking. If you can login to a TSO account on the mainframe, the OMVS command will get you to a command line prompt, provided you've been given a Unix uid and gid on the mainframe. Telnet or ssh may be enabled, so you could try those to get to a native Unix command line.

One other "by the way"...

If the mainframe system is z/OS 1.9 or later, SDSF supports a Rexx interface that you could use to write your own job scheduler. Rexx is an interpreted high-level programming language. It's very powerful, but like any language, you'll have to invest some effort into learning it.

good point. not to bore you with the corperate politics but the person ive been working with is now billable. i know that posix is different from z/os-mvs but i find it frustrating that a 4 letter bash command requires billable hours to be done on the mainframe.
i tried running omvs from the ispf command shell and it shows me copyright/trademark notices from ibm then the last line says -- the session has ended. press enter to end omvs.

seems like i'm getting somewhere

When you say "ispf command shell", you don't mean ish or ishell, the ISPF shell panel do you? That's a weird interface. I wouldn't suggest using it. Normally you enter OMVS from a TSO line mode READY prompt, from ISPF option 6, or by entering TSO OMVS from a command line on just about any ISPF screen.

But based on your results, I suspect the problem is that there is no Unix uid/gid defined for your userid. If your security system is RACF, you need to have the security folks define an OMVS segment for you. (Billable, no doubt.) That is where your uid, gid, shell, and home directory get defined.

i am now submitting jobs via bash from the unix system using ftp(messy hack -- i hate having passwords written in a script. wish there were ssh keys for mainframe).

after issuing quote site FILE=JES i can upload the jcl and it automatically runs. now the script sleeps for 3600 seconds (1 hour) between jobs. but some jobs finish in a few minutes (1 of them takes longer than an hour sometimes).

is there a way to know when a job completes via ftp ?

There are a couple of SSH options available for the z/OS mainframe, but they may not be set up at your shop. IBM has a port of openssh available that can run under Unix Systems Services on z/OS. It's not installed or configured by default. Tectia has a mainframe ssh server product, and there are a couple of others out there. But none of that helps you if it's not available on your mainframe.

FTP can't initiate a shell script on the Unix/Linux side, but z/OS does have a native rexec client that can initiate a script via your rexecd server, if you are running one. rsh is also available.

You could add a final job step to your mainframe batch job to invoke rexec, if you are running the rexec server on the *nix side. If you don't, then your final step could ftp a file to your Linux system, and you could watch for it via the inotify interface.

This is about as bizarre a thread as I would expect to see here. You can submit JCL and get the output back automatically; see here.
I might expect this from a (z)linux instance - but I guess you could do it from OMVS.