Remember your "Record Resulting Indicators?"
In Ye Olden Dayes of programming, back when cards of chipboard were
common, you'd enter an order by preparing a Header card with order
number. It would contain the customer number, order date, etc. etc.
Then there'd be a Ship To card. It would also have the order number,
but one or more columns would have a code indicating "Ship To." Then
there was the "How To Ship" card, then one or more "Detail Item"
cards. And you'd stack them up and feed them into the computer.
Good ol' RPG II would read the cards, and, using the Record Resulting
Indicators, turn on 01 for Header, 02 for Ship To, 03 for How To
Ship, 04 for Detail.
When these applications were migrated to a disk-based system, it was
common (wasn't it?) to have an 'open order file,' with all of these
record types in a single file, still using the record resulting
indicator to sort things out.
Of course, the data structure of each record was totally different:
text aligned with numbers aligned with dates (with or without
And when these old applications migrated to the S/38, you'd have to
allow for a file that had mixed record types. I think that's why you
can have different file formats in a single file...
And you'd have to say LVLCHK(*NO) because of the mixture of data types.
Of course, these applications would all be quickly re-written using
multiple files and a join logical to simulate the mixed format file.
--Paul E Musselman
At 10:52 AM -0500 9/5/09, Booth Martin wrote:
I am curious...
One of the strengths of the IBM midrange platform is that IBM has been
extraordinarily diligent in protecting us from ourselves. Bearing that
in mind, there must have been some overwhelming reason that allowed
LVLCHK(*NO) to make it into the parameter list in the first place. What
could it possibly have been, and is it still relevant?