Re: CHGPF Question

In a message dated 97-09-20 04:31:56 EDT, you write:

> DAsmussen@aol.com wrote:
>  
>  > Art,
>  >
>  > >  Got to go with LVLCHK(*NO).  Remember to compile all programs that
add
>  > >  or update that file.  It'll work smooth.
>  > >
>  > >  Art (seat of my pants) Tostaine, Jr.
>  >
>  > Those pants must be awfully tight!  ARE YOU NUTS????!!!!  How does CHGPF
>  > alter this over just adding the field and compiling the file (other than
>  > making sure you save the data)?  How does the speed difference between
>  > compiling the file and using CHGPF make or break taking the customer's
>  > business?  How much MONEY is the customer going to lose because YOU
>  > missed a program that added to or updated the file?  THAT's what LVLCHK
is
>  > FOR!!!
>  >
>  They won't lose any money.  They'll make more.  We got the users off for
>  30 minutes at lunch time.  There was no time to recompile all of the
>  programs.  They did get recompiled over the weekend, though.

As most of us do.  So again, what's the big deal?

>  > If you already know what programs add/update the file, why DON'T you
know
>  > which ones access it at all (HINT:  DSPPGMREF to an outfile)   If you
know
>  > both, what the heck is the big deal with re-compiling them ALL?  Yes
database
>  > changes require careful consideration, but simply adding a field is NOT
>  > rocket science!

>  It is for me.   I use STRSEU (or PDM option 2) on the DDS, add the field
>  at the end, then recompile using LVLCHK(*NO).

Adding a field is rocket science to you, but LVLCHK(*NO) isn't a problem?
 I'd say that LVLCHK(*YES) would be more of a requirement in this case than
in any other...

>  > I disagree VEHEMENTLY
>  
>  VEHEMENTLY? Are you shouting?  Agree or disagree vehemently that the
>  Clinton is a lousy president (he is), or that Key West has the best
>  sunsets, but not on LVLCHK(*NO).   Go outside or something.

The aforementioned examples do not require a shout.  Clinton is an agreed
example by most, and sunsets are irrelevant (any of the latter that I get to
see without being locked inside of the computer room is a good one!).
 Obviously, LVLCHK requires a little more attention ;-).

>  > with using LVLCHK(*NO) under ANY circumstances.  I'll
>  > make the same challenge that I did with GOTO
>  
>  Oh yeah, the GOTO challenge.  Almost as exciting as the If/Then/Else
>  challenge.

I don't recall an If/Then/Else Challenge.  Art, this response isn't typical
of you!

>  > -- show me a SINGLE example
>  > under which it would be valid, and I'll admit my mistake (haven't
>  > gotten one
>  > in almost a year on GOTO yet, but you're welcome to try with LVLCHK).
>  
>  How 'bout GOTO     ENDOFTHISTHREAD?

You know that I could join in, but I'll refrain...

>  >  Otherwise, I've still got a couple of customers with S/34's in their
>  > warehouse that they're trying to get rid of -- ITS database should
>  > suit you
>  > just fine...IF you can afford the electricity to run it :-).
>  >
>  
>  Many AS/400 owners are small to medium size companies.  They have little
>  to no MIS staff.  Certainly no DBA's.  Their computers are wedged in
>  tight somewhere in their phone closet.  It's hot in their offices in the
>  summer, and cold in the winter.  Not everything is perfect.  I agree
>  that a perfect world doesn't use LVLCHK(*NO).  I agree that there can be
>  problems.  But in the case that I stated, it was the only way to go.
>  Guess what? The programs worked, nothing bombed, they landed a new
>  customer, and I got the job done.  Do you think that if I told the
>  customer that I really can't get the programming changes done today
>  because it is bad form to use LVLCHK(*NO) they would understand?  No,
>  they would say, "make it happen."

I still fail to see how LVLCHK(*NO) aided you.  All I want to know is how
LVLCHK(*NO) could possibly be of help.  I, personally, can see NO benefit.  I
never used it at small accounts, and I won't allow it at large ones.

>  Maybe I can use those Sys/34's to heat some of my customers offices in
>  the winter.
>  
>  The largest MIS shop that I've ever worked for (largest MIS shop, not
>  largest customer) had 8 programmers on staff, and 8 consultants full
>  time (I was one of the consultants).  They had 8 programmers with their
>  feet up, and 8 consultants working 16 hour days getting the projects
>  done.  I made a fortune.  The company as a whole didn't get much done.
>  They talked about projects in man-years.  My customers want
>  man-minutes.  What's the smallest company you've ever worked for?  Ever
>  work without a DBA?  Or a system operator?  Ever change a ribbon in a
>  printer because the only other person in the company who knew how to
>  quit?

Until the last two engagements, I've ALWAYS worked without a DBA -- and the
DBA's were incompetent at both locations (although the situation has recently
improved at my present primary client).  I still believe that all but the
largest shops have no need of a DBA.  In fact, those large shops could do
without one as well if they would implement decent standards.

At the smallest account that I worked for, myself, the President, and two
clerks sat in the same room with the 5362 (with ANCIENT Okidata printer as P1
and a PC/XT as the console).  I have several that weren't much larger, but
that was the smallest.  All of these accounts measure in man-minutes, but I
fail to see where LVLCHK(*NO) gains you any -- it can, in fact, COST you
quite a few!

At my smallest AS/400 account, I used the bookkeepers' terminal (the console)
and sat next to their 9404 "C10" model.  This is where I learned the AS/400.
 Amazing that I quit "screwing up" when I wrote a utility to change all of
their files BACK to LVLCHK(*YES).  The point is, LVLCHK prevents new people
coming into an account from "screwing up" programs that are already in place.

>  Some people are just too passionate about the wrong things.  I'm done
>  with this thread.  On to the Gui/Green screen thread.  5250 rules!

Have I, perhaps, hit a "sore spot" here?  Could it be that you've known using
LVLCHK(*NO) to be wrong all this time, and are afraid to admit it?  Bringing
up my old nemesis, the 5250 data stream, recalls the Southern expression
"Guilty dog barks first".  Art, I didn't mean to impugn your abilities in any
way.  I just disagree with LVLCHK(*NO), and was looking for a situation under
which it would be valid.

Regards,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@AOL.COM

"We are what we repeatedly do.  Excellence, then, is not an act, but a
habit." -- Aristotle
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MAJORDOMO@midrange.com
|    and specify 'unsubscribe MIDRANGE-L' in the body of your message.
| Questions should be directed to the list owner/operator: david@midrange.com
+---