What command can I use in a JCL + NDM script to make the transmissions wait?

Question

Working on a z/OS system, and I'm not part of the programming team, but I know some programming stuff. We have a tool that we're working with that can output JCL + NDM to send files from the company to the client. I can manually add and review the output before submitting the card.

I'm looking for a way to affect the timing of the transmissions, per the clients request. I'd like to keep it simple and just modify the JCL + NDM before submitting it. They would like several minutes in between each transmission (execution of NDM script), and the time to transfer the file may vary.

What commands are available to me for that? I did some searching and it looks like most people think this is a terrible idea, though I'm not clear why (still new to mainframes).

I came across NDM's MAXDELAY, but I am not convinced that will help, it looks more like a queuing mechanism than a delay.

Another guy mentioned JCL's STARTT which could space them out.... if we knew how long it would take for them to send.

I was hoping there was something that inserts a delay. We're already setting a priority to single thread the script and send things one at a time.

Since I have JCL and NDm in the same script, I can use either to make the delay.

For reference, in other languages, most languages have a wait, delay, or other command available. Also, sometimes those commands have idiosyncrasies; Arduino stops all execution during a delay, so it's not recommended.

Answer 1

If you can add a step to the JCL, then...

//WAITABIT EXEC PGM=BPXBATCH,PARM='SH sleep 10s'
//STDOUT   DD  SYSOUT=*
//STDERR   DD  SYSOUT=*

...might be what you're looking for. The sleep shell command is supplied with z/OS.

Some people worry that this ties up an initiator unnecessarily.

Answer 2

z/OS 2.2 did introduce the SCHEDULEstatement which allows to submit the job but delay execution until some specific date/time.

It could look like this:

// SCHEDULE HOLDUNTL=('02:37','02/13/2020')

But neither the HOLDUNTL nor the STARTBY parameter make any guarantees as to the exact start time.

So if you want to have a short delay you could go with cschneid's solution, for a fixed start time some later time in the future the above solution would avoid unnecessarily blocking an initiator.

Answer 3

FYI, NDM (Network Data Mover) has been called Connect:Direct for quite some time now.

Have you considered using DGADWAIT, the Run Task Wait Program?

Answer 4

That's not the way mainframes work. The idea of putting a fixed delay into a batch job means you haven't defined your process properly (Why are you waiting? What are you waiting for? Why not just use some of the myriad of tools available to you to schedule the second part of the process once whatever you are waiting for has occurred?).

If you have a bunch of files to transfer, then just submit a batch job or jobs to transmit the files and they get there when they get there. If you have a specific requirement to run the batch jobs at specific intervals then either have the process that creates and submits the JCL only do so at intervals, or you could get the software to write each file to a dataset and have another process read that file every xxx minutes and build a transmission job for the eligible files.

The problem you have is that you are trying to modify a perfectly acceptable process (build a batch job to send a file and then submit the job) to do something different, because either the client's requirements have changed (they can't receive the files in an ad-hoc fashion anymore - usually because their processes around incoming files are bad) or were not properly understood from the outset.

If you can't modify the process, then you're going to have to ad-lib it. One option would be to direct the transmission jobs to an inactive initiator (the part of the system the executes jbatch jobs) and then have some automation to briefly start and then stop the initiator every xxx minutes, allowing just one job to run at a time.

If you want each transmission to run in sequence once the previou sone has completed, then just give all the batch jobs the same name (so they have to run single-stream) and use MAXDELAY=0.