Re: Are level checks still useful?

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Yes, those tools make it really easy to recompile...

BUT they don't help with testing...and you really should test anything that
gets recompiled.  9 times out of 10 things will be fine.  But do you really
want to explain to management that the reason something failed in
production was because you recompiled it and didn't think you needed to
bother to test it?

A better solution is not to have to recompile in the first place.

I've been using Aldon for 16+ years...I still prefer not to recompile
unless the code is actually changing.

Charles


On Thu, Nov 1, 2012 at 1:53 PM, WAJE0822 <waje0822@xxxxxxxxx> 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.
>
> --
> 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.