Identifying the requestor of an RDL within the RDL 1

[samj]

I need to be able to identify who has requested an RDL so that certain info is/is not shown in the output depending on their position. Any ideas?

 

[Calator]

Note: As security may be fairy complex it would be preferable that you try to solve the issue using standard MIMS security features rather than coding this yourself in the RDL.

However if you still need to write the code, here are some ideas(following applies to MIMS4.1):

At login (MSO000), the user’s profile string is returned to the common area in a variable called WX-EIBSEC and is used throughout MIMS by every program, checking wether to grant access to itself(current program) or not, by placing a call to MSSSEC option P-authorise program access, and what level of access is granted.

The user’s profile string is determined by:
sign-on userid, district-code, position-id
and this information is available as "wx-" variables within your RDL.
Just examine the Cobol code generated from your RDL and search for wx-security-area. Below is a partial copy

03 WX-SECURITY-AREA.
05 WX-EIBSEC PIC X(250).
05 WX-USER-ID PIC X(10).
05 WX-EMPLOYEE-ID PIC X(10).
05 WX-SECURITY-ACCESS PIC 9.
88 SYSTEM-ADMINISTRATOR VALUE 9.
05 WX-POSITION-ID PIC X(10).
05 WX-USERID-EMP PIC X(1).
88 USERID-IS-EMP-CODE VALUE 'Y'.

You can see you have instant access to user's logon id, employee id and position id. All other security features are present.

Note that:
- a user may log on in one of several districts; upon change of district the profile may change based on msf020 ‘S’ profile information which is coded against the district
- a user may log in one of several positions; upon change of position the profile may change based on position information
- district and position-id are un-related (as establishment is global)

There is more low-level coding you may undertake in an RDL, such as:

(a) access all details of the current request record on msf080 (includes logon id of the user too):
DNOW = DATE () CONSTANT
TNOW = TIME () CONSTANT
RQ-USER = USER-ID OF MSF080 WHERE -
(PROG-NAME = enter report name eg 'MSR010', -
DEFER-DATE >= DNOW, -
DEFER-DATE <= DNOW) -
REJECTIF (REQUEST-DSTRCT <> %DISTRICT-CODE%) -
REJECTIF (DEFER-TIME<> SPACES, DEFER-TIME >TNOW) -
MAX (1) CONSTANT
(b) if you only have a sign-on user id, you can get the employee-id from msf020

(c)lookup in msf020 security , note both &quot;global&quot; and &quot;sign-on&quot; profiles may exist

(d)lookup of establishment, position incumbent(msf878) and position(msf870) global profiles

Note that security profiles are available on several levels and: position incumbent global profile (from msf878) takes precedence over position global profile (from msf870) that takes precedence over user sign-on global profile (msf020 'G') which takes precedence over user sign-on Profile (msf020 'S')!

Gets pretty scary, isn't it?

 

[Calator]

Here is a Design Suggestion for you requirement by using standard Mincom security concepts:

- code in your RDL stepped security behaviour, similar with some Mincom programs eg MSO080. Such programs change their behaviour depending on the level on which a user's profile matches that of the program. The security level will be a number eg 0 to 9.

By doing this you no longer need to identify the user based on hard-coding in the RDL of employee ids or sign on ids

- secure your RDL by creating a P security profile with MSO020 for your RDL, eg using a flag of '1'

- assign using MSO020 various levels of access to various users eg spaces for users that have NO access, '1' for those users that have minimal access through to '9' for those users that can access full functionality.

- within the RDL's code you can determine the comparison level of the user's profile string to that of the program
itself and therefore determine in which category this particular users is. This will then be used to tailor the output