Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Small cobol run-time errors, please help 2
- Thread starter Guest_imported
- Start date
- Status
"Read for update is a CICS function, along w/readprev and others, which are not available to a batch pgm."
That's what I thought. I didn't think that there was any sort of equivilent "locking" function for batch as there is for CICS.
So then why would anyone believe that an initial read is necessary for a batch program?
Nina Too
That's what I thought. I didn't think that there was any sort of equivilent "locking" function for batch as there is for CICS.
So then why would anyone believe that an initial read is necessary for a batch program?
Nina Too
Hi Nina,
There are 2 reasons that I know of:
1) In most cases the first read EOF (or part of a file, e.g. start/readnext) is treated differently than an EOF at any other time. On 1st read eof you may want to end the pgm w/a user abend, or display a worning msg, or wirte a "no data to report this period" line to your report, or modify the porcessing path of your pgm or, well, you get the idea.
2) It facilitates control break logic. Example:
read at end display 'no data' goback end-read
perf proc-accts until ip-eof
perf end-it
goback
proc-accts.
blah, blah, blah
perf proc-invoices until acct-is-fin
blah, blah, blah.
proc-invoices.
blah, blah, blah
perf proc-trans until invoice-is-fin
blah, blah, blah.
proc-trans.
blah, blah, blah
perf read-ip.
blah, blah, blah.
read-ip.
move curr-key to prev-key
read ip-file into ws-curr-ip-rec at end
move hi-vals to ws-curr-ip-rec
set ip-eof to true
end-read
perf set-breaks.
You'll notice that there are no "IFs" in the -proc pgraphs. All the control break logic is done in the perfs. But you need an init read to do it that way. And that's why I like the init read. Some say it's a matter of tast, but have you ever seen that lady on the Drew Carey Show?
Regards, Jack.
There are 2 reasons that I know of:
1) In most cases the first read EOF (or part of a file, e.g. start/readnext) is treated differently than an EOF at any other time. On 1st read eof you may want to end the pgm w/a user abend, or display a worning msg, or wirte a "no data to report this period" line to your report, or modify the porcessing path of your pgm or, well, you get the idea.
2) It facilitates control break logic. Example:
read at end display 'no data' goback end-read
perf proc-accts until ip-eof
perf end-it
goback
proc-accts.
blah, blah, blah
perf proc-invoices until acct-is-fin
blah, blah, blah.
proc-invoices.
blah, blah, blah
perf proc-trans until invoice-is-fin
blah, blah, blah.
proc-trans.
blah, blah, blah
perf read-ip.
blah, blah, blah.
read-ip.
move curr-key to prev-key
read ip-file into ws-curr-ip-rec at end
move hi-vals to ws-curr-ip-rec
set ip-eof to true
end-read
perf set-breaks.
You'll notice that there are no "IFs" in the -proc pgraphs. All the control break logic is done in the perfs. But you need an init read to do it that way. And that's why I like the init read. Some say it's a matter of tast, but have you ever seen that lady on the Drew Carey Show?
Regards, Jack.
Well, if you read my book you'll see I teach a method that does not use the "priming read" or "see read". I've seen more problems caused by these than they solve - especially in maintenance. Often maintenance programmers miss one or the other read - even when the read is performed. Strange things happen in these programs over time.
But this is all just a matter of opinion. I've also worked on systems that use this method - and I retain it while working on these programs -- and in addition any new programs I write also use this method. Why? Because that is what the programmers are used to maintaining.
But this is all just a matter of opinion. I've also worked on systems that use this method - and I retain it while working on these programs -- and in addition any new programs I write also use this method. Why? Because that is what the programmers are used to maintaining.
I would solve the problem of a statement for a prime read AND subsequent reads by having it in its own paragraph. i.e.
Perform 400-read-record.
Perform 300-process
until rcd-eof-flag = "yes".
.
300-process.
.
.
.
perform 400-read-record.
.
400-read-record.
read record
at end move "yes" to rcd-eof-flag.
Seems silly to have it in its own paragraph? Yes. BUT if you change from sequential to random, all you have to change is one paragraph and makes easier maintenance.
I have coded both with a prime read and inline read. When doing the initial student classes on merging two sorted files and updates, having each read in a separate paragraph and using the prime reads makes it easier to understand and follow.
Perform 400-read-record.
Perform 300-process
until rcd-eof-flag = "yes".
.
300-process.
.
.
.
perform 400-read-record.
.
400-read-record.
read record
at end move "yes" to rcd-eof-flag.
Seems silly to have it in its own paragraph? Yes. BUT if you change from sequential to random, all you have to change is one paragraph and makes easier maintenance.
I have coded both with a prime read and inline read. When doing the initial student classes on merging two sorted files and updates, having each read in a separate paragraph and using the prime reads makes it easier to understand and follow.
- Status
Similar threads
- Locked
- Question