View previous topic :: View next topic
|
Author |
Message |
V S Amarendra Reddy
Active User
Joined: 13 Sep 2006 Posts: 216 Location: USA
|
|
|
|
Hi,
My input file is of 1164 bytes and RECFM is FB. I will get one header as the first record followed by the detail records and atlast a trailer record. Now this file will be given as input to a cobol program which validates Header and trailer first before starting to process any detail record. Since this is a sequential file, the program cannot access the trailer unless it reads all the detail records. So my idea is to just move the trailer to second position which means following Header record. This way first header will be validated and then in the next read trailer can be read. I have written the control card as below.
Code: |
INREC IFTHEN=(WHEN=(1,3,CH,EQ,C'HDR'),OVERLAY=(1165:C'1')),
IFTHEN=(WHEN=(1,3,CH,EQ,C'TRL'),OVERLAY=(1165:C'2')),
IFTHEN=(WHEN=NONE,OVERLAY=(1165:C'9'))
SORT FIELDS=(1165,1,CH,A)
OUTREC BUILD=(1,1164) |
But my worry is if the detail records are too many then it becomes too much work to sort those many records where actually there is no sort happening on detail records.
Can someone please suggest any way to improvise the code?
Regards
Amar
EDIT: I have changed the subject to be more clear.
For those wanting to stick to the DFSORT stuff, click here.
For those who want to know about trailer processing, read on.
I have done this as I can't think of an reasonable way to split/tidy the topic at this late stage :-)
Bill Woodger |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
yeah, change the stupid cobol program to validate the trailer
(by the way, trailer indicates at the end)
as the last record against the accumulated totals of the detail records,
as every other program on the planet does for this kind of activity.
and, what pray tell, are you going to validate the trailer against
if it is the second record - thus preceding all the detail records.
actually, you could do this validation in a sort step,
instead of the cobol program that you seem to incompetent to write,
using sort, you could ask others to accomplish your task...... |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Wow. That is an interesting way to "validate" a trailer. What dbz said on that.
Not sure about the use of validating the trailer itself with Sort, except as an "ad hoc" thing, maybe.
The point of validating in the program is two-fold. File integrity (limited, but usually sufficient, given "diminishing returns"). Program integrity (dito).
If you take the trailer processing out of the Cobol program, you lose on the latter.
Obviously, checking the trailer as the "second" record provides you with neither. Nothing. Zilch. Etc. I've never heard of that. Can't be much useful information on the trailer anyway. Let me guess. "TRL" followed by a date (undoubtedly the "system date" so that it will screw-up if run after midnight, on re-runs, useless in system-testing and onwards, etc). |
|
Back to top |
|
|
V S Amarendra Reddy
Active User
Joined: 13 Sep 2006 Posts: 216 Location: USA
|
|
|
|
Thank you for the replies.
The requirement is to validate the number of detail records received in the input file against the count placed in the trailer record. I can do that in DFSORT too, that is not a problem. But the requirement was to display an error message in the SPOOL and a return code and then abend the program.
So I chose this method.
Regards
Amar |
|
Back to top |
|
|
V S Amarendra Reddy
Active User
Joined: 13 Sep 2006 Posts: 216 Location: USA
|
|
|
|
Oh by the way I used DFSORT itself to get the actual count of detail records received too. I have not pasted that control card here. Let me paste it here.
Code: |
COUNT FROM(IN) SUB(2) WRITE(T2) DIGITS(9) WIDTH(80)
|
|
|
Back to top |
|
|
V S Amarendra Reddy
Active User
Joined: 13 Sep 2006 Posts: 216 Location: USA
|
|
|
|
I can ask the people to change the cobol code to validate the trailer at the end itself. But I have got a question in my mind. which is the very important reason for me to place the trailer in second position. Normally we tend to receive million detail records. So, let's say we start validating the trailer at the end itself. Now the program has validated Header and processed all the million records successfully but the trailer record is having a wrong detail records count and at this point we must abend the program after doing that much process. So to save the process time and effort, I chose to keep the detail in the second. Please provide your thoughts. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
to check if the < whatever total> matches You will have anyway to read all the detail records
|
|
Back to top |
|
|
V S Amarendra Reddy
Active User
Joined: 13 Sep 2006 Posts: 216 Location: USA
|
|
|
|
yes, but I am doing it in JCL using the DFSORT control card I have pasted above. which will provide me the count in a file and this one I am using as the another input to cobol program which will be assumed as the actual number that should be present in the trailer record.
Regards
Amar |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
back in the age of antiquity:
headers contained - an effective date
- a designation of the source
trailers contained - a count of transactions (detail records)-sometimes broken down into a number of
- non-monetary
- debits
- credits
- a total of the monetary values -sometimes broken down into total amount of
- non-monetary (zero)
- debits
- credits
detail records were validated for validity - numerics in number fields
- alpha in x-type fields
- and occasionally check-digit for account numbers
Back in the days before the Sort utilities nearly made ezytrieve obsolete
the validation programs where written in a HLL
before the batches were processed against a masterfile.
and normally the files were contructed: header, detail, trailer.
now, if someone got clever and decided to output the trailer as the second record,
I see no great problem in saving the trailer record
and then validating it against accumulated detail totals.
If someone (the TS) is now trying to process a header, detail, trailer file
with a program that is designed to process header, trailer, detail
it is very poor IT protocol to manipulate the file to fit the program,
thus avoiding any potential mangling of the data.
If the site has both types of file formats (really good IT),
then the program should be written to handle both.
screwing with the file to fit the program is not suggested.
Quote: |
yes, but I am doing it in JCL (sic) using the DFSORT control card I have pasted above. which will provide me the count in a file and this one I am using as the another input to cobol program which will be assumed as the actual number that should be present in the trailer record.
|
which means you are potentially changing a trailer record,
which has already been created somewhere else, by someone else,
and those are the totals that have been recorded as transmitted to your little circus
thus, no audit trail is keep, what a zoo! |
|
Back to top |
|
|
V S Amarendra Reddy
Active User
Joined: 13 Sep 2006 Posts: 216 Location: USA
|
|
|
|
Thank yo for the useful information provided. I agree to that.
Then, could you please suggest me an alternate way to save the effort yet we don't abend simply on trailer after processing all of the details.
Would there be any other way at all or we must only choose to process the million and trailer atlast?
Please suggest. If that is the only way, then I would be happy to change the code to validate the header, detail and trailer record which should make the program to look good.
Regards
Amar |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
Quote: |
Would there be any other way at all or we must only choose to process the million and trailer atlast? |
what is that You do not understand
first,last,middle another file, ..anywhere You wish
if You need to check some <total> You will have to process all the detail records full stop |
|
Back to top |
|
|
V S Amarendra Reddy
Active User
Joined: 13 Sep 2006 Posts: 216 Location: USA
|
|
|
|
Ok... I would change the code to perform the same way. Thank yuo all for your time and responses. |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
why are you abending?
Quote: |
which should make the program to look good |
if by 'look good' you mean to properly process the file,
ignore my next comment.
what do you mean by 'look good'? |
|
Back to top |
|
|
V S Amarendra Reddy
Active User
Joined: 13 Sep 2006 Posts: 216 Location: USA
|
|
|
|
I meant that I will be changing the cobol code to validate the input file on header,detail and trailer basis as suggested by you. Will remove the DFSORT process to mangle the trailer. So the file will be properly processed as suggested by you. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Read through dbz's second.
If you have a huge file and you don't want to back-out lots of processing when the first program through discovers that the trailer is does not represent the data (remember, you don't know which, if either, is "correct" in this situation) then you pre-process the file for the "file integrity".
Then you know trailer reflects data before kicking-off your first processing program.
But you STILL do the trailer processing in all the programs that read the file. This gives you the "program integrity" in relation to the file processing.
Even with a trailer with just a "count" (that's dumb as all heck, to me) this gives you at least something.
The trailer must trail. |
|
Back to top |
|
|
V S Amarendra Reddy
Active User
Joined: 13 Sep 2006 Posts: 216 Location: USA
|
|
|
|
Quote: |
Even with a trailer with just a "count" (that's dumb as all heck, to me) |
Not sure why the other system creates trailer like that
I understood the trailer part, I will create a preprocessing that ensures the file integrity before the actual program is kicked off. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
You should CYA. Raise a "change" however that is done at your site. Request a (more) useful Trailer. Then when all the "credits" on the file are reversed in error before the file is presented to you, no-one can say "why didn't you mention that this was not verified when you were looking at the Trailer-processing three months ago"? |
|
Back to top |
|
|
V S Amarendra Reddy
Active User
Joined: 13 Sep 2006 Posts: 216 Location: USA
|
|
|
|
ya this looks better idea to proceed with rather than allowing them to create such kind of trailer. I will raise a change request for that. Thank you Bill for your suggestion. |
|
Back to top |
|
|
Skolusu
Senior Member
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
|
|
|
|
V S Amarendra Reddy wrote: |
Thank you for the replies.
The requirement is to validate the number of detail records received in the input file against the count placed in the trailer record. I can do that in DFSORT too, that is not a problem. But the requirement was to display an error message in the SPOOL and a return code and then abend the program.
So I chose this method.
Regards
Amar |
V S Amarendra Reddy,
well there are ways to validate the trailer count with the number of detail records you have. If your sole intention is to bring the trailer record to be the second record then it can be done without a sort. Use Joinkeys with seqnum as matching key and use the same file as both JNF1 and JNF2. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
Maybe like this:
Code: |
//MOVETRL EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTOUT DD SYSOUT=*
//SYSIN DD *
OPTION COPY
JOINKEYS F1=INA,FIELDS=(7,7,A),SORTED,NOSEQCK
JOINKEYS F2=INB,FIELDS=(7,7,A),SORTED,NOSEQCK
JOIN UNPAIRED,F1
REFORMAT FIELDS=(F1:1,5,?,F2:1,5)
OUTFIL IFOUTLEN=5,
IFTHEN=(WHEN=(6,1,CH,EQ,C'B'),
BUILD=(7,5,/1,5))
//JNF1CNTL DD *
OPTION COPY
OMIT COND=(1,3,CH,EQ,C'TRL')
INREC OVERLAY=(7:SEQNUM,7,ZD)
//JNF2CNTL DD *
OPTION COPY
INCLUDE COND=(1,3,CH,EQ,C'TRL')
INREC OVERLAY=(7:C'0000005')
//INA DD *
HDR
DAT 1
DAT 2
DAT 3
DAT 4
DAT 5
DAT 6
DAT 7
TRL
//INB DD *
HDR
DAT 1
DAT 2
DAT 3
DAT 4
DAT 5
DAT 6
DAT 7
TRL
|
For additional excitement (to demonstrate flexibility) I've placed the trailer at the position of the fifth record (counting the header).
Code: |
HDR
DAT 1
DAT 2
DAT 3
TRL
DAT 4
DAT 5
DAT 6
DAT 7
|
Although the file is read twice, it will use less resources than sorting the file (generally).
The "/", the "slash operator", which is only available on OUTFIL, causes an additional record to be written.
On one "side" the trailer is excluded and sequence numbers are appended. On the other side only the trailer is included, with its "sequence number" set to the position you would like it to occupy.
The one match on the file is identified in OUTFIL, by use of the ? matching-marker. At that point records from F2 and F1 are output separately in that order. All the other records, all from F1, are written by default, with a length of 5 (due to the IFOUTLEN=5).
Note: the above is for a fixed-length records. For variable-length records the code differs. |
|
Back to top |
|
|
|