Re: S/36 Environment and Security -- MIDRANGE-L

I was going to try to set up a test this morning to check on adopted authority, Chuck, as that and the procedure thing were the only things I could think of that would explain Jeff's problem.
I surmised that the reason Jeff was trying to set the user's special environment to *none was part of a move off of the 36 environment (buy, don't I wish we had time for such a project). I set one of our users to *None special environment. When I signed on as that user, the session dropped here. Not because of an authority problem, but because of an initial menu. The 36 environment "knows" that menus can be display files + messages or a native menu; the native environment, however, only looks for a *Menu object. I never knew about the QEXSIGN program, but figured the environment had to be handling a lot of things under the covers.
Another example of this is that, while in the 36 environment, is the search for commands and 36 procedures. The environment will try to find the 36 procedure first and only look for a command (native or user-defined) if it cannot find the procedure; in native mode it only looks for commands. For example, I created a 36 procedure named DSPOBJD but put in totally unrelated tasks; it ran the procedure, not the command.

Long and short is that moving off of the 36 environment is going to take more than just changing RPG II programs to III or IV and procedures to CL.

* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>

CRPence wrote:

The error can be forced, and thus the user prevented from signon, by either of the following requests:
- CRTSRCPF FFMSYSPROD/QS36PRC AUT(*EXCLUDE) MBR(FFMINLPGM)
- GRTOBJAUT FFMSYSPROD/FFMINLPGM *PGM TheUser *EXCLUDE
In either case, AUT(*EXCLUDE), or an authority specification that precludes the specific user from that *FILE or *PGM object. This is just moving the authority down to the object in the library versus just on the library.

The results for S36E appear to be consistent across release(s). Since the System/36 environment is /special/, in the ways it attempts to mimic the OCL environment of the S/36, it may be considered valid. I do not recall where procedures resided nor rules for authority to use them, on an actual System/36.

However, to the best of my knowledge, the results should be as I suggested. That is, it seems to me that the SYS7293 message should be issued [best identifying the library name, program name, or the file name QS36PRC]. The lack of that error for the SPCENV(*S36) user, with the given scenario, could be reported as an apparent defect. In my view, an apparent defect for the program QEXSIGN adopting authority to access the *LIB object, when either the *PGM or *MEM is found with the object names specified on INLPGM().

Regards, Chuck