|
Hi Dale
It sounds like that you have LVLCHK *YES on the logicals that the programs use.
Alan Shore
Programmer/Analyst, Direct Response
Dale,
We are a larger shop, but I too am struggling with the same thing in
that the PHP/MYSQL people scratch there head (more like point fingers at
me and snicker) when we struggle with level check.
I have a project to convert DDS to DDL, but I am waiting for IBM to
change the QSQGNDDL api, to include the record selection into a SQL
index. We had been thinking that we could somehow migrate the database
from DDS to DDL, and keep the same format level.
When a shop is converting from DDS to DDL, should we turn off level check?
The purpose of level checks is to safeguard against a program
unwittingly accessing a different version of a file from that it was
compiled against. If you are only adding new fields to the end of a
file, the question is, how much impact on your system will it have if
records are written to this file without data in these new fields? If
the answer is none, then go ahead and turn level checking off. At least
with RPG you had this option, evidently PHP programs could corrupt your
database whatever your level check setting was!
Trevor Briggs
YES, YES, YES...a thousand times YES. Level checks are useful and it is a
horrible idea to turn them off.
If you want to add fields without recompiling....
1) create a new physical with the new fields (using DDS or SQL DDL)
2) create a logical with the same name and format (fields and keys) as the
original physical
3) repoint existing logicals to the new physical (need to explicitly list
fields if they don't already have their own format)
4) create new one or more new logicals (specifying all fields now in the
new physical)
When you do this process correctly, you end up with every
originally existing object having the same "format level identifier" and
thus it will not cause level checks.
Make sure that from now on your RPG programs using RLA only access a
through a logical and you'll be able to add new fields to the physical
without doing anything to existing logicals or programs. Sure you'd need a
one or more new logicals that include the new fields. But as long as the
new logicals have the same key as an existing, there basicaly no overhead
for them beyond a few bytes of space for the object definition itself. In
addition to not using the new physical on a f-spec, don't use it for
anything like defining a DS with EXTNAME(). The idea is to separate the
physical format of the data from what your HLL apps see.
SQL does this automatically, so SQL programs can access the physical, just
make sure you don't use SELECT * FROM MYNEWPF...
HTH,
Charles
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.