Re: Restrict CLROUTQ--A good use for an exit program?

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.