I think see what you are trying to do, but have doubts as to whether it will work. These are my thoughts:
- I have only ever seen the &TIME1(c) character string used for output. For example: OUTREC BUILD(1,11,12,&TIME1(:))
will place the current time in HH:MM:SS format into the output record starting at position 12. To the
best of my knowedge, TIME cannot be used in an ICETOOL/DFSORT COND statement as you have indicated in your question.
- Even if TIME were supported within COND statements, the +/- operators are not supported as you might
have seen with DATE (eg. DATE1+1 to get current date plus 1 day). Adding some constant to a TIME
is not supported.
- Have you given any consideration to what would happen if your job were to run a few minutes
before midnight? Adding an hour to the time causes a roll over to morning of the next day. At that point you
need to take the date into condideration in the COND.
Something that might work: Add a pre-step to run a REXX, or some other, prgram. Let this program
generate all or part of the
INCLUDE statements used in a subsequent ICETOOL step. Here is an example REXX procedure that
will create an INCLUDE statement similar to the one given in your question. The record is
written to the file allocated to DD CNTLREC:
/* REXX */
PULL DELTA /* Number of hours to add to current time */
PARSE VALUE TIME('N') WITH HH ':' MM ':' SS /* current time */
HH = LEFT((HH + DELTA) // 24, 2, '0') /* add DELTA, check rollover */
QUEUE " INCLUDE COND=(12,8,CH,GE,C'"HH":"MM":"SS"'),"
EXECIO * DISKR CNTLREC(FINIS
EXIT
Assign this file to the appropriate ICETOOL control statement DD and it should work for you.
Warning: This example does not deal with adjustments that might be
required to the COND parameters in the event of a rollover midnight.
Note: If you stored the above REXX procedure in a PDS as: "MY.REXX(FOO)", your pre-step
JCL would look something like:
//RUNREXX EXEC PGM=IKJEFT01
//SYSEXEC DD DSN=MY.REXX,DISP=SHR
//SYSTSPRT DD SYSOUT=A
//SYSTSIN DD *
%FOO
1
/*
//
The '1' following %FOO is the DELTA number of hours referenced in the procedure.
Best Solution
Since 12,200 people have looked at this question and not got an answer:
DFSORT and SyncSort are the predominant Mainframe sorting products. Their control cards have many similarities, and some differences.
A "JOINKEYS" is made of three Tasks. Sub-Task 1 is the first JOINKEYS. Sub-Task 2 is the second JOINKEYS. The Main Task follows and is where the joined data is processed. In the example above it is a simple COPY operation. The joined data will simply be written to SORTOUT.
The JOIN statement defines that as well as matched records, UNPAIRED F1 and F2 records are to be presented to the Main Task.
The REFORMAT statement defines the record which will be presented to the Main Task. A more efficient example, imagining that three fields are required from F2, is:
Each of the fields on F2 is defined with a start position and a length.
The record which is then processed by the Main task is 5311 bytes long, and the fields from F2 can be referenced by 5201,10,5211,1,5212,100 with the F1 record being 1,5200.
A better way achieve the same thing is to reduce the size of F2 with JNF2CNTL.
Some installations of SyncSort do not support JNF2CNTL, and even where supported (from Syncsort MFX for z/OS release 1.4.1.0 onwards), it is not documented by SyncSort. For users of 1.3.2 or 1.4.0 an update is available from SyncSort to provide JNFnCNTL support.
It should be noted that JOINKEYS by default SORTs the data, with option EQUALS. If the data for a JOINKEYS file is already in sequence, SORTED should be specified. For DFSORT NOSEQCHK can also be specified if sequence-checking is not required.
Although the request is strange, as the source file won't be able to be determined, all unmatched records are to go to a separate output file.
With DFSORT, there is a matching-marker, specified with ? in the REFORMAT:
This increases the length of the REFORMAT record by one byte. The ? can be specified anywhere on the REFORMAT record, and need not be specified. The ? is resolved by DFSORT to: B, data sourced from Both files; 1, unmatched record from F1; 2, unmatched record from F2.
SyncSort does not have the match marker. The absence or presence of data on the REFORMAT record has to be determined by values. Pick a byte on both input records which cannot contain a particular value (for instance, within a number, decide on a non-numeric value). Then specify that value as the FILL character on the REFORMAT.
If position 1 on F1 cannot naturally have "$" and position 20 on F2 cannot either, then those two positions can be used to establish the result of the match. The entire record can be tested if necessary, but sucks up more CPU time.
The apparent requirement is for all unmatched records, from either F1 or F2, to be written to one file. This will require a REFORMAT statement which includes both records in their entirety:
DFSORT, output unmatched records:
SyncSort, output unmatched records:
The coding for SyncSort will also work with DFSORT.
To get the matched records written is easy.
SAVE ensures that all records not written by another OUTFIL will be written here.
There is some reformatting required, to mainly output data from F1, but to select some fields from F2. This will work for either DFSORT or SyncSort:
The whole thing, with arbitrary starts and lengths is:
DFSORT
SyncSort