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



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.


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.