|
Question When and how can I terminate the learning phase for a user ? Answer A. First You should check the stored access informations.
Option 6 can be used to print a compact overview of stored access data.
Use this overview to decide which accesses shall be rejected. 1. Database accesses Database
accesses not desired can be deleted on display 8
= all database data.
Accesses not desired can be marked with option 4 and deleted via command key F11. 2. Netserver accesses to IFS The stored access paths have to be checked. Please specify the sub-path up to which checking shall be performed (generic access). Stored IFS data only exist if IFS is being displayed on the screen. 3. Execution of remote commands. For CL commands, the complete length of the command will always be checked. A command may contain variable data, changing e.g. from call to call. This often is true for self created commands. Shorten the command to the desired length to be checked.
Option C can be used to call command maintenance. Data only exist if value CMD is being displayed on the right.
The CMD radio button can be used to call command maintenance. Data records only exist if the fields on the left before and below the button are being displayed in white.
Command PRTLOG shall be adjusted.
On page 2 the cursor may positioned to that part of the command up to which checking shall be performed. F5 can be used for cursor positioning and F10 to store the record. The specified command has to be valid. If necessary, change *LIBL by using F13 in order to have the syntax checker find the command. If multiple identical command records exist (e.g. CRTPF), the sequence should be adjusted to have the longest CRTPF being checked first. This can be done by changing the sequence number. B. Further checking or activation You have now checked and adjusted the most important data. With option A on the user record controlling can now be activated. Accesses not being stored will then be rejected. If it is a very important user and you do not yet feel confident enough to activate him, he can be switched into a monitoring mode for some weeks. Up to now, all not yet registered accesses have been logged and automatically have been converted via command CVTPCSLOG into access authorities on a daily basis. You now do have two options: 1. Stop conversion and check log entries by yourself. 2. Additionally, you can get immediate information about each access that would have been rejected. Option 1 = stop automatic conversion
On the 4th user page you can stop automatic conversion. Option 2 = additional controlling A message queue in break mode is required. The following 2 commands have to be used if you want to implement a message queue PCSMSG in library QGPL: CRTMSGQ MSGQ(QGPL/PCSMSG) TEXT('PCSACC/400 error messages') CHGMSGQ MSGQ(QGPL/PCSMSG) DLVRY(*BREAK)
On the first user page the test mode can be changed to 2 and you can scroll to the fourth page via F7.
On the fourth page the message queue can be entered.
Now all accesses will be displayed that normally would have been rejected. The logged accesses will be shown on the display of log records (call via option L on the user display or via log button on the 5th page of the user record.)
Option S can be used to convert the desired accesses into access authorities. To delete the remaining records, exit screen by pressing command key F12.
By specifying 1, a job will be submitted to batch for deletion of all entries. C. Final activation If you did not receive any messages for 1 or 2 weeks, the user can be activated via optiona A. Now the accesses will definitely be rejected. If
it is a very important user (Power user or management) you can keep notification
of accesses. You can identify from the displayed messages, whether access
has been performed in test mode or actually have been rejected. |
back to top
