Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
khamarutheen,
I don't see any thing obvious that would pinpoint as to why it does not work for you. Run this job and see how many records you got in your sortout dataset.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
khamarutheen,
I looked at the offline messages and the OPTION SOLRF is the culprit. If your System Programmers changed the shipped default from SOLRF=YES to SOLRF=NO, you might want to ask them why they did that as it can cause some very unexpected results.
So you need to Override that parm with the following statement. Add the OPTION SOLRF as your first statement in SYSIN and then followed by your sort fields and Inrec statements. Use the following control cards and re-run your job.
Joined: 28 Jul 2006 Posts: 1702 Location: Australia
Hi Skolusu,
you mentioned this
Quote:
I looked at the offline messages and the OPTION SOLRF is the culprit. If your System Programmers changed the shipped default from SOLRF=YES to SOLRF=NO, you might want to ask them why they did that as it can cause some very unexpected results
Why make an option available if the results are unpredictable ?
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
khamarutheen,
Are you sure that you are looking at the correct output file for the count? Are you using the same file as input and output? You canNOT use the same input file for output also for a COPY operation.
Run the following job as with just changing the input filename and show me the contents of OUT from step0200
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
Why make an option available if the results are unpredictable ?
"unexpected" was the word Kolusu correctly used, not "unpredictable".
NOSOLRF works in a perfectly predictable manner, but it may not be working in the manner you expect if you don't understand that the shipped default of SOLRF has been changed to NOSOLRF. SOLRF lets DFSORT use the length of the reformatted record as you would expect it to do. NOSOLRF prevents DFSORT from using the reformatted record length and instead uses the input length. That's NOT what you want to do in most cases and you may not realize the default option has been changed so to you that's an unexpected result. But it is predictable.
The reason we allow the user to change the shipped default from SOLRF to NOSOLRF is to allow DFSORT to work the way it used to work when it only worked as if NOSOLRF was specified (before we added the SOLRF option). Some customers (especially those from Japan) always want to be able to have DFSORT run the way it used to run, so when we supply a new option that changes things, we give them an option to do it the old way. SOLRF is the new way. NOSOLRF is the old way. We recommend using SOLRF as shipped, but we allow them to set NOSOLRF if they really want to. They would have gotten really angry if we didn't let them do it the old way. We would have preferred to do only do it the new way, but they don't give us that choice. The best we can do is set the new way as the shipped default and let them change it if they want to which is what we did. Developers and customers don't always see eye to eye on the right way to do something so we sometimes have to compromise.
Now the concern is, in my JCL STep1 --> copies the header record, Step2--> copies the particular account number STep3 --> Copies the trailer record. Now after copying the trailer record we need to update the total count. What should be modified now? Please advice.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
khamarutheen,
*Sigh*. For about a week the provided job is indeed providing the correct results. However you coded your own logic to copy the header and trailer records and you complain that the suggested solution does not work.
It is really hard to provide solutions with a moving target. After 3 pages of discussion and solutions provided now you are telling that you have a new requirement?
Just for the record you really don't need 3 different steps to copy the records with header and update the trailer accordingly.
Unless you provide the complete details there is nothing I can do to help you.
1. What is the LRECL and RECFM of the file
Record format . . . : FB
Record length . . . : 2000
Block size . . . . : 18000
2. How is the header record identified?
Step "TAPE" Will identify the header record
3. How is the detail record identified?
Step "STEPM1" Will identify all the details inside the record
4. How is the trailer record identified?
Step "STEP1" was coded before now it was commented
5. Do you need to eliminate any records ?( ex duplicates...or include cond)
Yes . INCLUDE COND=(1,2,CH,EQ,C'SD') Here "SD" is the particular account group to be elimnated
6. Does the count on trailer include the header and trailer records also? Assuming you have
10 detail records and 1 header and 1 trailer , does the count on the trailer record say 12 or 10 considering only the detailed records?
Everything is included