|
Rob, Thanks and welcome back from COMMON. Sure, go ahead and send it to me. I'd like to give it a shot and it sounds like it could be a good example to base it on. I considered changing the command authorization with the WRKOBJ command but that would lock the henhouse without telling me who's been steeling the eggs. As for journaling, that might tell me who is doing it now but in two months someone else might start to do it and by then I'm not watching it any more. I had looked at the parameters for doing a CHGCMD on CLROUTQ and wondered if something could be done with the VLDCKR option. Still, if I wanted to go that route I thought that an exit program might be a better tool for the job. Dave Dave Parnin Nishikawa Standard Company Topeka, IN 46571 daparnin@xxxxxxxxxxxxxxxxxx rob@xxxxxxxxx To: Midrange Systems Technical Discussion 05/10/2004 11:56 <midrange-l@xxxxxxxxxxxx>@SMTP@CTB AM cc: Please respond to Subject: Re: Restrict CLROUTQ--A good use for an exit Midrange Systems program? Technical Discussion <midrange-l@midra nge.com> Hey davey, Just wrote my first command exit point program two weeks before COMMON. It takes SNDDST and converts it into SNDEMAIL. Be happy to send you a copy off list. I too, looked at the library list solution. The command exit point does not involve any IPL's or any other method of restarting every single job to make sure it uses the new system library list. (At least for the initial creation of that library and the changing of system value QSYSLIBL.) Back when Autojectors had their own 400 we renamed the command CLROUTQ because PM taught the users to run it on a frequent basis for QEZJOBLOG. Never really had any problems with any IBM programs. I suspect none of them use CLROUTQ. Well, I suppose if you wondered why option 14 failed to work from WRKOUTQ... You can restrict the command if you wanted to with WRKOBJ. Or, you can just do a CHGCMD and remove *INTERACT from "Where allowed to run". This will still allow anyone to use it in case you have it buried in an application program or some such animal. Just for you, I did that on GDISYS to test. Then I tried option 14 from WRKOUTQ. Locked it down tight. CPD0031-Command CLROUTQ not allowed in this setting. Then I did a CHGCMD and set it back. *IPGM will still allow it to run interactively if it is buried in an application program. Now, these last two options require that you make these changes whenever you upgrade OS, etc. This is a selling point for the modification of system library list. However the command exit point will definitely catch it. Just requires some programming on your part. Versus a simple CHGCMD or EDTOBJAUT. Then there is turning on spool file journalling. Yes, it is after the fact, but it does give you a nice excuse for RIF. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "David A Parnin" <daparnin@xxxxxxxxxxxxxxxxxx> Sent by: midrange-l-bounces@xxxxxxxxxxxx 05/10/2004 11:27 AM Please respond to Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> To midrange-l@xxxxxxxxxxxx cc Subject Restrict CLROUTQ--A good use for an exit program? Good morning all, We have a situation where someone appears to be clearing an outq for a printer used by many people. There's no real need for any user to be using the CLROUTQ command or choosing option 14 from WRKOUTQ. What we would like to do is to log the user-id of people trying to do this and give an error message to any non-MIS people. My boss initially suggested creating a modified CLROUTQ command that was higher in the library list than the system command. Over the weekend I started wondering if an exit program could do the job. I've never attempted an exit program before but wouldn't mind learning. I've seen examples for FTP and Telnet in the archives but can they be added for any command? I would appreciate any advice. Thanks. Dave Parnin Nishikawa Standard Company Topeka, IN 46571 daparnin@xxxxxxxxxxxxxxxxxx _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l. _______________________________________________ This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.