Re: date processing in z/OS

On 9/27/2008 at 1:38 PM, in message
<HJadnXC5cL8nFkPVnZ2dnUVZ_tbinZ2d@xxxxxxxxxxxxx>, Joel C.
Ewing<jcewing@xxxxxxx> wrote:
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.

This one seems to be an acceptable, if not ideal, answer. It would be nice
if I could just query the BUSDATE parameter directly, but from all I've read
today the symbolic parameters are replaced prior to the job being executed,
and are not available at run time. (Interestingly, VSE allows symbolic
parameters to be queried at run time!)

If we did this we would definitely take advantage of the INCLUDE statement,
as this is very similar to what we do now. Currently at around 7pm the
operator changes the DATE card to be the current day. So every job that
includes this special member will process with the same business day from
7pm to 7pm.

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.

Yeah, this could work, though I have the feeling the operators like being in
control by changing the business day manually. I don't recall ever hearing
of them screwing this up. Which is surprising, to be honest! :-)

Thanks for the ideas!

Frank

.

Relevant Pages

  • 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 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 a value that can be determined automatically. ... 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)