RE: Making command parameters off-limits

["Carl Galgano" <cgalgano2@xxxxxxxxxxxxxxxxx>]

Alan:
This may not be helpful, since you are asking a specific questions and I am
going to change the subject a bit.  About 2 years ago we had a client that
ran nightly batch reports, printed a zillion (OK maybe not quite a zillion)
pages of reports and distributed them.  Same old story, some did not get
delivered, some got lost, some needed reprinting.  So we worked with them to
devise an intranet site, they call it their "workbench".  They defined many
critical pieces of data that were important on a daily basis (including many
of the daily reports).  We wrote some code to convert the spool files to
HTML and store them on the IFS.  Now is someone needs a report, they go to
the Workbench, click and find the report, then find the date they need and
get the report in their browser.  If they need to print all or part of it,
they can do that too.  Sure saved lots of trees, as well as paper costs.
cjg


Carl J. Galgano
EDI Consulting Services, Inc.
550 Kennesaw Avenue, Suite 800
Marietta, GA  30060
(770) 422-2995 - voice
(419) 730-8212 - fax
mailto:cgalgano@ediconsulting.com
http://www.ediconsulting.com
AS400 EDI, Networking, E-Commerce and Communications Consulting and
Implementation
http://www.icecreamovernight.com
Premium Ice Cream Brands shipped Overnight

"You ain't gonna learn what you don't want to know" - rw

-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of alan shore
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
+---

+---
| 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
+---