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