Tweet
The article by Real Beard on page 75 is essentially correct, but it does not address a little known quirk in SO/400 spool file security. A user cannot reliably be secured from spool files that they own. Mr. Beard comes close to recognizing that in the first paragraph where he states that spool file security is odd because spool entries are stored as members in a file, but the sad truth is that you need some other method of securing a spool file from it's owner. Perhaps if you described the business problem, a solution could be derived. jet
-
-
Secure Spool Files
In this case the user does not own the spool file/s. The objective is simple. We have separate outqs and printers for different departments. One department should not be able to access anothers spool files in any way. Thanks for your response... -
Secure Spool Files
I am trying to secure an outq. Public authority for the outq and the associated print device is set to *exclude. Outq parameters are DSPDTA(*NO), AUTCHK(*DTAAUT) AND OPRCTL(*NO). A user with class of user and no special authorities, does a WRKSPLF to see his own spool files, does an F22 to printers and then enters the secured outq with an option 8. I have tried all combinations of the above parameters without success. An article in NEWS/400, Oct 96 indicates that this should work, I think? Help Please...Comment
-
Secure Spool Files
If each department has a group profile make the outq owner that group profile and set puplic to *EXCLUDE. Or if the group profile should not be the owner then set the group profile into the the object's authorization as *CHANGE and public *EXCLUDE.Comment
Comment