Re: members in a file

Mark S. Waterbury wrote:

Generally, IBM is pretty good about ensuring "upwards compatibility" from one release to the next. Even if an outfile layout changes, IBM always adds any new fields to the end of the record, so old programs will continue to work, though you probably will need to issue an OVRDBF with LVLCHK(*NO) or compile the program with a version of the file that has LVLCHK(*NO) specified.
Also, if you access the *OUTFILE as a table with embedded SQL statements, instead of "native I/O" then this notion of "level checks" does not even apply. With SQL, data type compatibility checking is done on a column-by-column basis, rather than for the entire row or record (as with native I/O). Also, IBM usually leaves any unused fields in place, and they will contain blanks or zeros after a new release that no longer uses those fields.

Another alternative that I've used is simply to CRTDUPOBJ of the appropriate QSYS model file for the current release (e.g., V4R5). I compile over that duplicate *FILE object and keep it around. They're almost all just another *FILE object.

When I need to use a command that gives *OUTFILE support, I run the command to a QTEMP version of the model file for the current release (e.g, V5R3). I can then use CPYF (*MAP *DROP) into the format that was saved from the earlier release and that was used for the compiles.

Practically speaking, the actual number of records for a given *OUTFILE is usually pretty small compared to many databases. The overall I/O is often trivial.

It's pretty much self-maintaining and can provide a stop-gap method of processing when a SQL pre-processor isn't easily available or when sites aren't ready for even simple APIs.

Tom Liotta