RE: Making command parameters off-limits

Thanks for the reply, but in answer to what you have written----
The reason why I chose to use QTEMP, was to temporarily place these here and 
only for that person taking that option for that time period. Once that person 
was "out" of that option, these changed commands would no longer be available 
and the "real" ones would be back in play. If the user lost communication, 
whilst "in" this option, QTEMP would be purged/removed/no longer available. 
Signing back on, the changed commands would NOT be available, therefore in 
using the WRKSPLF command/screen for the users OWN reports, these reports could 
be deleted etc.
There IS method in my madness, and obviously if anyone can supply a different 
method/procedure for what I am ultimately attepting to do, I am as always 
grateful.

>>> "Bale, Dan" <D.Bale@handleman.com> 06/18/01 04:29PM >>>
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. 
+---
| 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
+---