Re: date processing in z/OS

If you really want that date value to be something in the job stream that is manually maintained, you could of course include the SYSIN data JCL as you suggested, but would have to set up the usual sequential file and record definitions and do an OPEN, READ, CLOSE to get your data record available to the program. If multiple job steps need the same value, there could be an initial job step added to copy your SYSIN date record to a sequential dataset that would then be referenced by multiple job steps.

If you want something simpler, why not just pass the date in as a parameter on the EXEC statement as in
//STEP0010 EXEC PGM=xxxxxxxx,PARM='BUSDATE=yyyymmdd/LE-runtime-parms'
and make the necessary changes in the program to receive a parameter value "BUSDATE=yyyymmdd". The "BUSDATE=" part is of course not needed and could just be ignored by the program, but it could clarify the function of the value to later maintainers. Note that for COBOL program executions, whether the program parameters come first or the LE-runtime parameters come first is an installation-defined COBOL run-time setting, so the order may vary in your shop.

If there are multiple job steps in the same job that all need the same business date, then one could use a single "SET" statement near the top of the job to define a SET symbol:
// SET BUSDATE='yyyymmdd'
and reference that in multiple later EXEC PARM fields:
//STEPxxxx EXEC PGM=xxxxxxx,PARM='BUSDATE=&BUSDATE....'
If your shop allows JCL statements in production jobs to be INCLUDEd from a library, you could even have the above "SET" statement reside in an include library member referenced by multiple jobs, so that one update could affect multiple jobs.

If the business date is always a set offset from the current date, you should just be using the various date functions in COBOL and/or LE run- time library, rather than forcing someone to manually supply (and possibly make an error in) a value that can be determined automatically. It is fairly simple using relative-day integer date formats as an intermediate format to compute Gregorian dates relative to the current date.

There is also no reason why one can't combine these techniques -- internally compute the business date if it is predictable 99% of the time, but allow an optional EXEC parameter to override for special tests or abnormal runs.
JC Ewing


Frank Swarbrick wrote:
In VSE there is a "DATE card" that can be placed in the JCL with any valid
date, and when you use "ACCEPT FROM DATE" you will retrieve this date
instead of the actual system date.

Apparently this is not available on z/OS.

We have jobs that run early in the morning but are really part of the
previous day's business. In these cases we have the JCL include a statement
that picks up a library member that has a DATE card specifying the business
date. This allows us to get the proper date on reports and, more
importantly, use the proper date for business logic. In some cases we have
the first job in the stream get the business date, and it then loads the
business date in to a database. But for one off things we don't bother
reading the date from the database. We just use ACCEPT FROM DATE.

I'm not quite sure what we should do for z/OS, though... Up to this point
we have only one application on z/OS, and it doesn't run after midnight for
the previous days processing. But if we move more things over there... What do we do?

It's even worse for testing. The first job I tried to run on z/OS has logic
that actually checks to make sure that the "current date" matches the
processing date that's on the database. But if I'm reading the database
from yesterday (or earlier) they will never match!

Ideas?

I was hoping I could use SPECIAL-NAMES and do something like this:

SPECIAL-NAMES.
BUSDATE IS BUSINESS-DATE.

PROCEDURE DIVISION.
ACCEPT BUS-DATE FROM BUSINESS-DATE.

And then have in my JCL something like:

//BUSDATE DD *
20080925
/*

(Well, I'd actually point to a DSN that has the date in it, of course. Except for testing when we'd have the inline file.)

But, at least according to the documentation, this will not work.

Obviously I can have BUSDATE defined as a file, but then we'll have to
change the Cobol programs to open the file, read the record, and close the
file. I hope to avoid that.

I may end up coding a small subroutine that does just that, and then call it
where I previously had done ACCEPT BUS-DATE FROM DATE I'd have
CALL 'BUSDATE' USING BUS-DATE BY CONTENT 'YYYYMMDD'
or
CALL 'BUSDATE' USING BUS-DATE BY CONTENT 'YYMMDD ' (now here is a case
where OMITTED might be useful. Probably better to have them code
CALL 'BUSDATE' USING BUS-DATE OMITTED, otherwise they're likely to forget to
code the trailing spaces after 'YYMMDD'.)

Probably not too had, but I'd still like to avoid it if there's a better
way.

Thanks,
Frank



--
Joel C. Ewing, Fort Smith, AR jREMOVEcCAPSewing@xxxxxxx
.

Relevant Pages

  • Re: date processing in z/OS
    ... you could of course include the SYSIN data ... If there are multiple job steps in the same job that all need the same ... If your shop allows JCL statements in production jobs to be INCLUDEd ... includes this special member will process with the same business day from ...
    (comp.lang.cobol)
  • date processing in z/OS
    ... In VSE there is a "DATE card" that can be placed in the JCL with any valid ... previous day's business. ... BUSDATE IS BUSINESS-DATE. ... ACCEPT BUS-DATE FROM BUSINESS-DATE. ...
    (comp.lang.cobol)
  • Re: date processing in z/OS
    ... run-time option and then queried within a COBOL program. ... If there are multiple job steps in the same job that all need the same ... includes this special member will process with the same business day from ...
    (comp.lang.cobol)