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



I agree with Bill in that tools we have today, and a properly managed source code library, we can change the database and recompile all objects without having problems. You can't do it every other day, but
should be able to get it done on a Sunday afternoon.


however, how many of our shops are like mine?:
the "non-RLA" side of the house points to DB2/i as being too rigid,
and our "RLA" people claiming extreme pain and suffering will take place if we try to add fields and re-compile objects.


Who has turned off level-check?

Who has thought hard about it, but decided not to?
Why?








On 11/1/2012 12:53 PM, WAJE0822 wrote:
If you use a change management system (like Aldon) and a system documentation tool like Hawkeye changing physical files, recreating based on logicals, and recompiling all programs using the file set can be done automatically. The amount of time required is based on the number of programs but it is a much better approach that taking a chance turning off the level check parameter. You are talking about corrupting your database's integrity if you willy nilly turn off level checking.
Bill Erhardt

On Nov 1, 2012, at 12:46 PM, Charles Wilt<charles.wilt@xxxxxxxxx> wrote:

On Thu, Nov 1, 2012 at 12:06 PM, dale janus<dalejanus@xxxxxxxxxxxxxxxxx>wrote:


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.


It's not really complicated...as you basically cut&paste everything...

The only real effort is checking to make sure the new objects format level
IDs match the existing. Even that can be done quickly with a DSPFD
TYPE(*RCDFMT) OUTPUT(*OUTFILE) and the use of SQL.

A lot less work than recompiling, especially if you consider the time to
test the recompiled programs.

Additionally, the work only needs be done once for any given file. From
that point forward, you can add fields without doing anything.

Lastly, the difference between this method and LVLCHK(*NO) is that this
method is much safer. If you screw it up, you'll simply get a level check.


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

Replies:

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.