|
Perhaps true but..... all data on a mainframe is ended with a card coded as /* to the operating system this means end of data. There could be other decks behind each ending with a /* and a final card with a /& that indicates end of job. So the point being, that what you heard is true but only if someone not familiar with job setup is stacking the deck. Again within any one of the data decks, that is any card data between the first data card and a /* card could conceivably contain many logical subsets of data each needing to be terminated by something, your example is picking the/an date field containing 09/09/99... This would not be my first choice even if the current date were 1/1/1959. Jim Langston wrote: > > When I learned COBOL it was on a mainframe that used punch cards. > If you were reading data and you did not look for a "special" card you > coded with a "special" value, it would just read through the rest of the > deck, including any other programs after yours, thinking it was data. > > If you did not enter the data in the format your read was expecting it, > you would get a run time error. > > The solution was to put a "special" value in one of your fields. If you were > reading string text, you could use *** EOF *** or something like that, but > if you were reading numeric fields, you had to put in a numeric value, and > all 9's was commonly used, and was in fact called the "9's rule". > > Jon.Paris@halinfo.it wrote: > > > >> From all the discussion I've heard on it, that was a common practice in > > COBOL programs as COBOL has no real EOF function (or didn't anyway). > > > > I don't recall any point in history when COBOL did not have an AT END option > > (i.e. EOF). On some systems I have worked with placing a high value (all >9s) in > > a dummy record at the end of file was done to allow you to position to > > (effective) EOF and read backwards - or is this what you meant by EOF >function ? > > > > Either way, it would never finish up as 09/09/99 it would have been >99/99/99. > > > > +--- > > | This is the Midrange System Mailing List! > > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > > | Questions should be directed to the list owner/operator: >david@midrange.com > > +--- > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.