|
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
On Thu, Nov 1, 2012 at 9:17 AM, dale janus<dalejanus@xxxxxxxxxxxxxxxxx>wrote:
We are in the slow, gradual process of changing from DDS to DDL.
Actually, we are creating new files with ops navigator and usually
not keeping the create specs. We just use navigator to change the
file when needed. Mostly we need record ID and timestamp, or date fields added.
But we have lots of old files. Yesterday, we needed to add 2 fields
to a file (a timestamp and a record id, both added with DDL in ops
nav.) Since we are adding the fields to the end of the files, we
figured this would be a good time to remove level check from the
file. But it did not work.
Here is our process for adding new fields to a file. We have a
library that contains all our RPG, DDL, CL etc. but no data. We add
the new fields to the file (called DIRECT). We change to level check
*no. This creates an empty file with the new fields.
We write a CL program to copy the data from production library to
empty library using CPYF with *nochk. Then in the production library
we delete all the logicals, rename the existing file to DIRECTOLD.
Next CPYF from the empty library file (now filled with production
data and new fields) to the production library, CRTFILE(*YES) then recreate the logicals.
When checking with DSPFD, both the file in the empty library and
production library say:
Record format level check . . . . . . . . . : LVLCHK *NO
Yet when I run programs against the file DIRECT or its logicals, I
get level check CPF4131errors.
So I had to recompile all the programs anyway.
We are a small shop with just 2 of us. We write all our own code, so
we are quite sure that adding fields to the end of a record will not
affect old programs.
I am RPG guy, my associate is PHP/WEB guy. He just kind of rolls his
eyes at me when I jump through all these hoops to add fields. His
PHP programs just keep on rolling, no matter what the file looks like.
So this long discourse asks two questions.
Why do my RPG programs (some RPG III, some ILE) insist on level check
when the file says LVLCHK *NO?
And
Is level check still useful? The ability to quickly add fields to
files seems to outweigh the comfort of your rpg programs knowing
exactly what the file looks like. Especially when half (uhh, maybe
not half but lots of them) of your programs are PHP.
---Dale
--
This is the RPG programming on the IBM i / System i (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/rpg400-l.
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.
midrange.com
