Re: Running with LVLCHK *NO in production

On 06/09/2009, at 2:24 AM, PaulMmn wrote:

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...

Don't reckon! An externally-described physical file on S/38 and OS/400 can have only one record format. Only logical, printer, display, and mixed (i.e, communications) files support multiple record formats in the same file.

To migrate those old applications required you to either continue with program-described file layout or (as you mention below) split the so- called "mixed-record-type" files into separate physical files. A logical file could then be used to merge the separate files into appearing as a single entity. In either case LVLCHK(*NO) was of little benefit.

And you'd have to say LVLCHK(*NO) because of the mixture of data types.

Nope.

Of course, these applications would all be quickly re-written using
multiple files and a join logical to simulate the mixed format file.
Sure. Yep.

Perhaps not quickly but reasonably fast. If done properly then no code changes are necessary. The database can be changed underneath the program by creating logical files with the same name as the old physical files and ensuring the same record layout. Even here LVLCHK(*NO) doesn't enter in to it given that you'd need to recompile the program source in which case the new level-check identifier would be picked up and stored within the program.

The only reason for LVLCHK(*NO) is to allow files to be extended at the end without requiring a recompile for all programs using that file. Only the programs that used the new fields would need to be recompiled (kind of like previous signature support with service programs). Extending files in this way was a common practice on other platforms and so was supported for migration reasons.

It can also prove useful as a temporary work-around for some IBM defects.

I once encountered a vendor who required LVLCHK(*NO) on all files because in release 5.0 (I think) of CPF IBM code rebuilt all logicals and incorrectly calculated the level check. When customers upgraded to CPF 5.0 the application started failing. Of course, a PTF was quickly forthcoming but the idiot Managing Director decreed LVLCHK(*NO) to avoid the possibility of this ever happening again. They continued with this edict even on OS/400 which is when I encountered it.

In my view the safety net offered by LVLCHK(*YES) far outweighs any perceived benefit of LVLCHK(*NO).

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------