|
QTEMP can be removed and added as the *FIRST library within the library list, I have tried this no problem. Again what I have written is mainly theory, and what I have read from the IBM manual re the CHGCMDDFT command with respect to IBM commands. Writing my own WRKSPLF command has been considered and is NOT totally out of the picture. Thanks for your input. >>> "Njal Fisketjon" <n.f@figu.no> 06/18/01 04:47PM >>> > 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 DLTSPLF and other commands are in QSYS (and QSYSxxxx) libraries which are normally part of your system library list. QTEMP are normally part of your user library list. The system library list precedes the user library list and you will never get to the QTEMP command if you don't qualify it's name, e.g. QTEMP/DLTDSPLF. WRKSPLF doesn't do this, of course. > 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. Why not just write your own wrksplf command, where you decide all the options? It's quite easy using the API's available. If not, you could place your modified system commands in a "permanent" library and add that to the system library list using CHGSYSLIBL, and remove that library from the system library list when exiting. +--- | 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 +--- +--- | 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.