In the header line,
'20090814' is the timestamp when the job runs.
'11112 ' is the sequential number which I want to automatically add 1 to the previous sequential number.
In the trailer line,
'0000005' is the number of records of the second input file(here is FILEB).
there is no bug in the code,
the only bug is in Your way of setting the requirements
from Your original request HDR implies header, TRL implies trailer,
which in any civil country means ...
HDR comes first, TRL comes last, none of it come in within the data,
build better data and the issue will automagically disappear
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
There's no bug in the code -- if you have HDR or TRL in the first 3 columns of records other than the header and trailer, you should have specified that in your original requirements. And you should have specified how to identify the header and trailer records, then.
Your inability to adequately specify your requirements does not constitute a bug in the code -- it merely highlights your lack of ability to create good requirements.
It seems that the latter solution is more effective, both in terms of time and space.
Because in the first step:
In solution 1, all input records are to be processed.
In solution 2, only the first and the last records are to be processed.
In my requirement, the data size between header and trailer is rather huge.
So, I think the second solution is more effective.
Thanks again to everyone concerned, especially Frank.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
In solution 1, all input records are to be processed.
In solution 2, only the first and the last records are to be processed.
Actually, all of the input records are processed with both jobs. As to which one is actually more efficient, you'd have to run them both (with a large number of records) to determine that.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
Generally, for the same input D/S and function, using DFSort is more efficient than using other PGM, right?
Well, DFSORT is very efficient, but it's a generalized utility so it has to handle all kinds of situations which involves overhead that a program written with specific knowledge of the application might be able to avoid. It's certainly possible for a well written program to be more efficient in some cases.
Quote:
Is the DFSort system embedded?
DFSORT is not a "system" - it's a program that runs on the z/OS system. I don't believe it would be considered to be "embedded" in any sense of that word. But maybe you should explain what you mean by "embedded".
But maybe you should explain what you mean by "embedded".
When we use DFSort , we don't specify the path of the PGM, so, I thought it is system embedded(it resides in the default library).
Now, I have a new requirement:
when the sequential number reached 99999, the subsequent sequential number should be set to '00001'.
If so, how should the DFSort be used?
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Quote:
When we use DFSort , we don't specify the path of the PGM, so, I thought it is system embedded(it resides in the default library).
This just means the load module has been placed in a system area (LINKLIST) so you don't have to point a STEPLIB or JOBLIB to it. The site systems programmers will do this for common routines -- often, even vendor software such as Compuware's Xpediter or CA's CA-11 will have entries in the LINKLIST due to frequent use. By no means could such a program be considered "embedded" -- I would consider something in the nucleus to be "embedded" (possibly).
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
When we use DFSort , we don't specify the path of the PGM, so, I thought it is system embedded(it resides in the default library).
I've never heard the term "embedded" used to mean "resides in the default library".
Your System Programmers set up DFSORT at your site so it can be found by default when you specify PGM=SORT. That's called the "system order of search" and is a standard z/OS function.
Quote:
I understood. In other words, DFsort is just like third-part software.
DFSORT is from IBM. For z/OS, "third party software" usually refers to software from companies other than IBM. DFSORT is actually an optional feature of z/OS. It is shipped with z/OS and just has to be enabled/licensed via PARMLIB.
If the INPUT file is VB format, job you provided goes wrong.
Can you help with the following error:
Code:
ICE632I 0 SOURCE FOR ICETOOL STATEMENTS: TOOLIN
ICE630I 0 MODE IN EFFECT: STOP
SUBSET FROM(IN) TO(OUT) FIRST LAST INPUT KEEP USING(CTL1)
ICE606I 0 DFSORT CALL 0001 FOR COPY FROM IN TO OUTFIL USING CTL1CNTL TE
ICE602I 0 OPERATION RETURN CODE: 16
ICE601I 0 DFSORT ICETOOL UTILITY RUN ENDED - RETURN CODE: 16
******************************** BOTTOM OF DATA ********************************
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
You didn't say you had a VB file so I didn't code for that. You have to handle a VB file different than an FB file. A VB file has an RDW in positions 1-4 and variable length records. I'm not feeling well today, so I'll ask Kolusu to help you.
IFTHEN=(WHEN=(5,3,CH,EQ,C'TRL'),
BUILD=(C'TCON1,''',5,13,C'''',80:X))
ICE146I 0 END OF STATEMENTS FROM CTL1CNTL - PARAMETER LIST STATEMENTS FOLLOW
DEBUG NOABEND,ESTAE
OPTION MSGDDN=DFSMSG,LIST,MSGPRT=ALL,RESINV=0,SORTDD=CTL1,SORTIN=IN,S
TOUT=OUT,DYNALLOC,EQUALS,NOCHECK,COPY
OMIT COND=ALL
OUTFIL FNAMES=OUT
ICE201I F RECORD TYPE IS V - DATA STARTS IN POSITION 5
ICE126A 9 INCONSISTENT OUT IFTHEN 1 REFORMATTING FIELD FOUND
ICE751I 0 C5-K90013 C6-K90013 C7-K90000 C8-K42135 E9-K90013 E7-K44563
ICE052I 3 END OF DFSORT
******************************** BOTTOM OF DATA ********************************
