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 / \
--------------------------------------------------------------------
midrange.com
