RE: Making command parameters off-limits

Well, first of all, I'd can the idea of using QTEMP for this.  Is QTEMP always at the end of your library lists?  ALWAYS?  You didn't explicitly state it, but it sounded like you were just going to ensure that QTEMP was first in your *User* library list.  All the IBM commands are going to be higher than that, in the system library list.  Why not just create a permanent library, FIRESTOPPR, and put your authority-modified commands in there, one time?  Then, all you have to do is to CHGSYSLIBL FIRESTOPPR as part of the users' startup and be done with it.  Steps 1/, 3/, 4/, & 5/ are done once, when you create the FIRESTOPPR library.  Step 2/ would be done either at the initial program level or by changing the system value QSYSLIBL (but if you did that, you'd probably want to change *your* initial program to remove that library from the system library list for your job).

SAVE(*YES): Are the spooled files always being created with this?  If so, why give users access to the parameter at all?  If not, perhaps the printer files should be changed to specify this and relieve the users from having to do this.

As far as restricting access to parameters, I think you are limited to using ?*SAVE(*YES), but this is possible only if you're rolling your own WRKSPLF-type utility. 

Maybe an exit program?  (Outta my league here, but seems to me I've heard something along these lines before.)

- Dan
Dan Bale says "BAN DALE!"
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952
D.Bale@Handleman.com
  Quiquid latine dictum sit altum viditur.
  (Whatever is said in Latin seems profound.)

-------------------------- Original Message --------------------------

-----Original Message-----
From:   alan shore [SMTP:SHOREA@dime.com]
Sent:   Monday, June 18, 2001 3:32 PM
To:     MIDRANGE-L@midrange.com
Subject:        Making command parameters off-limits

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.