|
Okay boys and girls, hopefully someone can give me an answer, or point me in the right direction. Here's the story, --- Are you sitting comfortably? Them I'll begin. Operations runs our nightly job flow. The reports are printed and then given to the user. Occasionally not all the reports end up in the users hands, or conversely, only portions of the reports are delivered. The user department becomes exasperated, due to the procedure involved in locating the right person (usually me - if I'm available) with the correct authority to hunt down the reports in question for re-printing. The user has requested an option/authority to be able do this themselves. Auditing and Information Security have no problem with the principle, but because operations of the AS/400 is outsourced, they do NOT want the user having the capability of deleting any of operations spool files. I have devised a method for a menu option of viewing the operators individual spools through WRKSPLF command. However this will give the user the option of deleting spools. In order to rectify this I have come up with the following solution. When this menu option is taken (user has NO command line capabilities) and the correct operator is chosen (using the ability to adopt owner authority) 1/. Delete the library QTEMP 2/. Add the library QTEMP as the *FIRST library within the library list 3/. Copy the command DLTSPLF from QSYS to QTEMP 4/ Revoke the *EXECUTE authority for *PUBLIC to DLTSPLF within QTEMP. This needs testing obviously, and I am hoping that this will result in an exception message saying that the user has insufficient authority yada yada, and that the spool file cannot be deleted. 5/. When the user chooses F3 or F12 to return to the menu, the object DLTSPLF within QTEMP, type *CMD will be deleted, QTEMP removed, then added at the *LAST position within the library list. The other "problem" command will be CHGSPLFA. 3a/. Copy the command CHGSPLFA from QSYS to QTEMP 3b/. Change command defaults (CHGCMDDFT) to the command CHGSPLFA within QTEMP for the parameter SAVE to *YES. This is where my problem comes in. Is there anyway of ensuring that this parameter can then be made OFFLIMITS to the user, so that if option 2 (change) on the WRKSPLF screen is taken, the SAVE parameter will remain untouchable at *YES. +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.