Re: Protection for spool files?

John Earl wrote:

> At 10:35 AM 1/20/98 -0500, you wrote:
> >My operator recently had the following problem:
> >
> >A user deleted our water & sewer bills in an attempt to get rid of one of
> their print jobs. Is there a way to allow user to be "empowered" yet protect
> our important jobs?
> >
>
> I havn't found a way to give users authority to control printers and yet not
> enough authority to delete spool files.  The problem is that once a printer
> prints a file, the file is deleted from the outq.  This implies that anyone
> who can print a file has the ability to delete it.

Whoa big boy...spool file keep will retain the file after printing.  I know you
know that much. :)
Nothing implied about it.


>
>
> Additionally, one of the rules of spool files is that a user that creates a
> spool file will always have authority to delete that spool file.  This is
> true even if the spool file is put into an outq to which the user has
> *EXCLUDE authority (They can use commands like WRKJOB and WRKSPLF to hammer
> it).  Ownership of a spool file confers *ALL authority to that file.

The creator givith and the creator takith away.  You are correct in the
following.  To retain, move it to where they can't takith away.  Flaw in design?
Nah, working as intended.

>
>
> The only ways I've found to prevent inadvertant deletes are
>
> A) Duplicate the spool file into a safe place either through the use of the
> DTAQ support and SNDNETSPLF, or through some utility that copies the spool
> file to a database file such as the TAATOOL DSPSPLCTL.  In order for the
> spool file to be safe you must perfrom the duplication with a "production
> profile" (as opposed to some user's profile) and the 'to' out queue must be
> secured against public access.
>
> OR
>
> B) Write a validity checker program for the DLTSPLF command that specifies
> that only user X can delete spoolfile Y.  Or only user X can delete spool
> files from outq Z.  However, this merely inhibits well intentioned users
> because it does not prevent other deleting acvtivities such as CLROUTQ, etc.
>

We regularly move printed/saved reports to a physical file for archive purposes
(with *PRTCTL attribute to reprint) and it works OK for us.  No big deal.

We got the idea from a QUSRTOOLS about deleting job logs.  You output any spool
file table of contents to an outq, read through it and perform action upon the
entries found.  We look for saved (implied printed) files with a particular file
name and user data and do a copy to physical file and delete spool file (clean
up).  Catalog the entry to an archive file to drive a retrieval program.  It 
even
goes to tape, logs the tape volume, issues mounting instructions, etc. etc. etc.
A very rewarding days effort of tool building. :)

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@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
+---