RE: RPG IV pgm dump -- RPG400-L

Gary,
Our shop has experienced this same problem with dumps and we run all
programs with adopted authority and the owner of the  programs has *all
rights and public has *change.  Based on your research below, it would seem
we should be getting normal dumps.  What else could cause this "dump" of a
dump listing?

> -----Original Message-----
> From: Gary Guthrie [SMTP:garyguthrie@home.com]
> Sent: Saturday, September 08, 2001 10:11 AM
> To:   rpg400-l@midrange.com
> Subject:      Re: RPG IV pgm dump
>
> 3. FOLLOW-UP: AUTHORITY REQUIREMENTS FOR PRODUCING AN RPG IV DUMP
>
> In the last issue of the Club Tech iSeries Programming Tips Newsletter,
> we showed you how to force an RPG IV dump. You should also be aware of
> the role that object authority plays in producing an RPG IV dump.
>       Unlike RPG III which requires only *Use authority to successfully
> complete a Dump operation, RPG IV requires the user to have either
> *Change authority to the program or special authority *Service. If the
> user has less authority (e.g., *Use without *Service), the system
> produces only the indicator portion of the dump, failing with error
> message "Error occurred while retrieving variable data. Dump
> terminated". Obviously, the dump isn't very useful without the program
> variable listing.
>       One of our readers, Mike Pearson, wrote to tell us how this has an
> impact in his shop. In order to prevent users from changing anything
> about the programs, their security policy prohibits granting users
> *Change authority to programs. Instead, users have *Use authority to
> programs. Unfortunately, because their RPG error management routines
> have historically included the use of the RPG Dump operation, they have
> problems now that their applications are written in RPG IV. Dump
> operations now fail to complete and without the program variable
> information, their dumps are worthless in diagnosing problems in an
> error situation.
>       I did some checking and found other shops that, in order to prevent
> users from manipulating programs, do not grant *Change authority to
> program objects and instead grant *Use authority. Though it certainly
> sounds like it would, *Change authority to a program object doesn't give
> users any authority to actually change or control that program object,
> however! Let me explain.
>       A comparison of the different levels of authority provided by
> *Change
> and *Use reveals that *Change authority adds additional data authorities
> (add, update, and delete rights), but no additional object authorities
> (both provide operational only). Data authorities define the operations
> users can perform on the contents of the object (e.g., records in a
> file). Program objects don't contain entries you can add, update, and
> delete so these authorities are effectively meaningless with respect to
> program objects.
>       It is the object authorities (e.g., operational, management,
> existence,
> and alter) that define the operations (e.g., change attributes, rename,
> and delete the object) users can perform on the object itself. Since
> they provide the same level of object authorities (operational), both
> *Change and *Use authorities grant the same level of control over an
> object!
>       In other words, users will only be able to change or exercise
> control
> over a program object if you grant some additional object authorities
> (e.g., management, existence, alter). The bottom line is that you don't
> need to avoid *Change authority to prevent users from changing and
> controlling programs.
>       Now, the gotcha! There is a situation, potentially significant, in
> which you would want to specify *Use rather than *Change authority to a
> program object. To debug a program object, a user must have *Change
> authority to that object. In an environment in which users need to debug
> some, but not all, program objects, you would specify *Use authority to
> those program objects you wish to allow users to execute without the
> ability to debug. Of course, doing so means that the Dump operation in
> these objects no longer successfully completes. If, like Mike's shop,
> you've made the Dump operation part of your error management policy,
> this is critical.
>       Mike tells us that he has contacted IBM in an effort to convince
> those
> in charge that the RPG IV Dump operation should function as it did in
> RPG III (i.e., without the need additional authority). He also tells us
> that IBM's stance is things are working as designed. He forwarded the
> following quote from information he says IBM Rochester sent him.
>
> "OPM RPG and ILE RPG program use two different ways to gather dump
> information. OPM RPG programs use an internal RPG runtime routine. ILE
> RPG runtime use the system debug API's to gather this information. Since
> the API called by the ILE RPG runtime to dump an ILE program is owned by
> the system debugger, the API uses the same security checking as the
> system debugger, so the same rules apply: *CHANGE object authority or
> *USE object authority with *SERVICE special authority. This system
> debugger security requirement is documented in the AS/400 ILE Concepts
> manual the Chapter titled 'Debugging Considerations'."
>
> I didn't find specific documentation in the ILE Concepts manual
> indicating the requirements for the RPG IV Dump operation (nor would I
> expect to). I did find documentation indicating the user must have
> *Change authority to a program object in order to add it to a debugging
> session. I suppose that with a lot of reading between the lines (and a
> telephone call to Rochester) one might come to the appropriate
> conclusion!
>       Mike reports that he is in the early phases of negotiation and that
> he
> plans to pursue this further with IBM in an effort to obtain a fix.
> Those who find this significant in their shop may also wish to contact
> IBM.
>
>
> Here's an item I put in a recent issue of the NEWS/400 Club Tech
> Programming Tips newsletter. Hope this helps.
>
> (Sign up for the free newsletter at www.as400network.com)
>
> Gary Guthrie
> Editor, NEWS/400 Club Tech Programming Tips newsletter
>
>
>
> saustad@deltadentalwi.com wrote:
> >
> > We had an RPG IV pgm blow up yesterday afternoon with the following msg:
> >
> > The target for a numeric operation is too small to hold the result (C G
> D
> > F).
> >
> > We know why the pgm abended - we had an invalid value in one of our
> > database fields.
> >
> > But we also had the following msg at the end of the dump:
> >
> > Error occurred while retrieving variable data.  Dump terminated.
> >
> > Although we were able to locate the invalid field, in the past (RPG
> III),
> > when we had the full dump, we would have been able to locate the problem
> > much faster.  Does anyone know what causes the terminated dump?  We
> talked
> > it over here, but know one really knows.  Compiler options?  Debug
> options?
> > Change management system?  Any ideas would be very much appreciated.
> > Thanks.
> >
> > _______________________________________________
> > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
> list
> > To post a message email: RPG400-L@midrange.com
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> > or email: RPG400-L-request@midrange.com
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.


************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which maybe confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message.
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer.
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************