× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Dale
It sounds like that you have LVLCHK *YES on the logicals that the programs use.

Alan Shore
Programmer/Analyst, Direct Response

Yes, I mistakenly assumed if the physical was level check no, the logicals would be as well. I see this is not the case.
I will run CHGLF tonight when no one is using the files.



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?


In PHP and maybe other languages, SQL controls how the file is defined. We always use SQL to access DB2 files in PHP.
Everytime the PHP runs, it gets the latest file definition. So it is sort of level checking every time it runs. If we accessed DB2 files in PHP without SQL, that would be a different story.



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


You have a valid point in favor of level checking for the programs that add records to the file. But what about programs that just read and/or update existing fields? If they don't need or know about the fields, why should they care? This also assumes you are only adding new fields to the end of the record.
RPG is not the only game in town these days. PHP, Java, other SQLs, probably even excel running on a pc could all change/corrupt/whatever DB2 data. (yes, depending on security and access levels)

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



This method seems a little too complicated for our little shop. Yes, this would work, but it is the equivalent amount of work as compiling all the programs. Maybe if we had started that way from the beginning, it would be more practical.

This is sort of the same method as not using level checks. The programs that do not use the new fields continue to run merrily along via their logicals, blissfully unaware that new fields have been added.





We are leaning toward the ability to quickly add fields to the end of our database records as a more valuable thing than the OS insuring that RPG programs are absolutely, positively correct.

If we had more programmers, or interacted with purchased software, level checks would have more value. For a small shop, the ability to react quickly seems more valuable.

---Dale











As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.