Mainframe, MVS and zOS Discussion

Hi,

I have a JCL which would be invoked by the CA-7 scheduler.I'm trying to get the the RUNDATE and TIME information when CA-7 submits the Job.

Is this doable?

Look at the CA-7 Interfaces manual and in particular at the CA-7 Driver functionality. CA-7 Driver allows you extensive date processing functionality in your scheduled jobs. Note, however, that submitting such a job from TSO or batch internal reader requires manual changes before the job will pass the JES converter / interpreter.

Thanks Robert.

I'm exploring the options for CA-7, as you've suggested and in touch with the scheduling team.

I was just thinking if such a thing can be done by some utility program also, to get the RUNDATE?

Sort allows you to use the date; or, a program written in the language of your choice will allow you to access the date.

However, one thing you need to consider: what is RUN DATE? Example: the job is scheduled in CA-7 to be submitted at 11:55 PM. Even though the job is submitted and eligible to run, there are no initiators for the job class available so the job does not start running until 12:05 AM. What is the RUN DATE in this case -- the date the job was read in, or the date the job actually started executing? For long-running jobs or jobs that start executing before midnight and complete execution after midnight, the end date could be different from the date the job started executing, too. SMF records when the job was read into the system, when the job was processed through the JES converter / interpreter, and when the job actually started executing -- so just for start time you have at least 3 different choices.

Thanks Robert.

We're thinking to a file with a date in it and this will be considered as run-date. As of now when the Job is submitted is treated as run-date. Thanks again for your insight on this.

Kanika,

That is a good way to go. You can also put a bit more into it, like have "yesterday" and "tommorow" and "last working day of the week", etc, etc. Cycle the file round from one "run" to the next. Maintain the file automatically as the first thing the "batch" does. Have a screen/something for formal manual update (with logging) of anything if ever required. The all the "date processing" is in one place, and any programatic use of a date just has to use the correct one from the run-date-control-file.

Thanks William - we're working on the same lines. Hopefully we'll roll out this all soon.

Thanks for your comments,