Allow users to view & release spool file but not delete from OUTQ

25 pts.
Spool files
Is there a way to allow a user to be able to view spool files and be able to release those spool files in an OUTQ, without giving that user the ability to delete spool files in that OUTQ

Answer Wiki

Thanks. We'll let you know when a new response is added.

The short answer would be no

but as the previous entry says – there are ways to accomplish this.
A simple means is to print to an outq which has no user access (using system security) 
reports are then copied to a users outq, and they have full control over them – which can include deletion – but of course, you still hold a ‘master copy’ so can provide reports they shouldn’t have deleted and so on.
or you can write your own version of an outq viewer which allows only certain actions – plenty of example code was around when the API’s first appeared.  
Or – you could use the capability to regenerate spool files as PDF’s – still preserving the originals
or if we are looking at a monitored outq, then the world’s your lobster in terms of preserving reports (or not) 
and, aren’t there some exit points nowadays on OUtQ actions you could use to prevent unwanted actions?

Discuss This Question: 6  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • TheRealRaven
    What other actions need to be controlled? Can a user start/end a writer? If a user starts a writer for an *OUTQ, a spooled file can be "printed" to an inappropriate printer, and the system will delete the spooled file as soon as the printer reports that the last page is 'safely' buffered in its memory. The effect is no different from the user doing the deletion.

    IOW, what are the things you need to accomplish? Does the above fit with 'no delete'?
    36,370 pointsBadges:
    Actually there is a way to prevent most spool file deletions and clearing of the outqs.  It has been in use at my client site for a number of years. If all you are looking for is the ability to prevent users from Interactively deleting spool files or clearing outqs then this is easy.

    The only caveat is this -- in the S36 environment users can still delete individual spool files, depending on their assistance level.

    Abundant caution is the byword. 
    1. Copy DLTSPLF and CLROUTQ to a savf file.
    2. Create Duplicate objects of DLTSPLF and CLROUTQ naming them appropriately -- DLTSPFLORG and CLROUTQORG.
    3. Change the ability of DLTSPLF and CLROUTQ so they cannot run interactively via the CHGCMD.  That is, remove *INTERACT and *IPGM from their attributes. 

    This will prevent the use of these two commands interactively. Attempting to delete spoolfiles or clear outqs will result in a message at the bottom of the screen "Command DLTSPLF not allowed in this setting"

    Because the commands are allowed in batch mode this will not affect that. Also, because you have created duplicate commands you can still use CLROUTQORG to interactively clear outqs. Interactively deleting individual spools, though, is more difficult.

    Because some of our users need to be able to delete spools a program was created to check a custom security package for authorization to use the delete. This, however, requires a method to authorize those persons and so is beyond the scope of my answer here.

    We went from V6R1 to V7R2 and this works.

    These instructions would need to be executed again when new versions are installed.
    Always be cautious when modifying any object in QSYS. And always, always, always have a backup
    30 pointsBadges:
    A couple of follow ups to my previous post to clarify. 

    First of all, instructions will work to prevent deletion.

    I did misspeak about the S36 environment.  The loophole is actually in *BASIC mode of WRKSPLF where the user can change a spool to a different printer and change the attributes to not SAVE -- thus the spool would print and not be saved; i.e. effectively deleted.

    The client has changed all PRTFs so that SAVE(*YES) is the normal mode which is why I missed this.

    This is the only loophole that I have found. 
    30 pointsBadges:
  • TheRealRaven
    It should be noted that the above wouldn't stop various users from deleting spooled files with DLTSPLF, even as a simple *USER with LMTCPB(*YES) and no command-line access. I suspect that other members here could do it. Numerous additional features of the system would need to be disabled or otherwise controlled, for most systems that would be disruptive.

    Also, because spooled files are not 'objects', they're not directly subject to object authority. You can place some authority on *OUTQ objects, but not the spooled files. WRKSPLF, for example, goes directly to a user's spooled files without touching any *OUTQ, and users can delete spooled files they own no matter what *OUTQ has a related entry.

    Only an entry that points to a spooled file is on any queue. The authority to any *OUTQ or 'entry' on a queue is unrelated to the spooled file itself.

    If a user shouldn't delete a spooled file, then don't let the user be the owner of the spooled file nor let the user have *SPLCTL special authority.
    36,370 pointsBadges:
  • chalenger


    User has the required object authority for the output queue. The required object authority is specified by the AUTCHK parameter on the CRTOUTQ command.

    • A value of *OWNER indicates that only the owner of the output queue is authorized to control all the spooled files on the output queue.
    • A value of *DTAAUT indicates that users with *CHANGE authority to the output queue are authorized to control all the spooled files on the output queue.

    620 pointsBadges:
  • TheRealRaven
    The above describes how different users might (or might not) control every spooled file on the *OUTQ. In neither case is the authority altered for spooled files that are owned by the user (nor for *SPLCTL users). Both cases only alter how users might or might not manipulate spooled files owned by other users.

    A user who owns a spooled file (or a user with *SPLCTL special authority) can't be stopped from deleting it (without many more changes). As mentioned before, WRKSPLF and other methods provide access to spooled files without regard to *OUTQ attributes. If spooled files are referenced through WRKSPLF, the *OUTQ attributes are irrelevant.

    It's trivially easy to demonstrate simply by creating a test user profile with no authority other than SPCAUT(*SPLCTL). Then create an *OUTQ with *PUBLIC *EXCLUDE object authority and no private authority for the test profile. Set the *OUTQ attributes any way you choose. Move any spooled files owned by any other user to the restricted *OUTQ.

    Then sign on with the test profile and run WRKSPLF SELECT(XXX) where "XXX" is the actual owner of the spooled file on the restricted *OUTQ. See if option 4=Delete will delete the spooled files or not. (It will.)

    And if DLTSPLF has been altered so that it won't run *INTERACT, well, there are other ways to do it. But there's no good reason to publish methods, even though users can often figure them out or might have learned from the internet or in previous jobs or from friends.
    36,370 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: