RE: Logging jobs/sbs

Rob

I hear you. Wrapping an API with a command is just as useful inside IBM as it 
is for us.

One could find out what happens with a job trace, I suppose. Maybe I'm merely 
looking for trouble by looking for non-command ways that IBM might have done 
these things.   ;-)

Vern

-------------- Original message -------------- 

> Vern, 
> 
> Often IBM uses the commands under the covers - even as much as they push 
> API's. I tried to block people from creating 5250 sessions on one server 
> by renaming the command CRTDEVDSP. Caused a lot of grief when the console 
> died and the boss tried a different model. Automatic reconfiguration uses 
> DLTDEVD followed by CRTDEVDSP. I had to use RUNRMTCMD to rename the 
> command back. 
> 
> The reason that I renamed the command in the first place is that iSeries 
> Access did not use those system values to control new virtual sessions. It 
> just ran CRTDEVDSP via remote commands. What a hoot. 
> 
> Rob Berendt 
> -- 
> Group Dekko Services, LLC 
> Dept 01.073 
> PO Box 2000 
> Dock 108 
> 6928N 400E 
> Kendallville, IN 46755 
> http://www.dekko.com 
> 
> 
> 
> 
> 
> Vernon Hamberg 
> Sent by: midrange-l-bounces+rob=dekko.com@xxxxxxxxxxxx 
> 01/18/2005 09:22 AM 
> Please respond to 
> Midrange Systems Technical Discussion 
> 
> 
> To 
> Midrange Systems Technical Discussion 
> cc 
> 
> Subject 
> RE: Logging jobs/sbs 
> 
> 
> 
> 
> 
> 
> If you look in the earlier posts in this thread, I had mentioned a couple 
> exit points that are called for commands. They are in the first couple 
> entries of WRKREGINF. Rob Berendt had offered some sample code using 
> these, 
> IIRC. These exit points define a program of yours that is called whenever 
> a 
> certain command is run. This is done in the job running the command, so 
> you 
> can retrieve user, etc, all you want in order to log things. This could be 
> 
> done for ENDSBS. 
> 
> Also, you could set up security auditing on certain commands, to see when 
> they have been used. The problem still is, there are non-command ways to 
> end subsystems, such as option 10, I think, in WRKSBS. Or just using 
> option 
> 4 against the SBS job in WRKACTJOB. But maybe you could audit all the 
> entry 
> points for ending a SBS, such as the ones mentioned, log them, get QHST 
> info, and correlate them in some way. 
> 
> HTH 
> Vern 
> 
> At 01:00 AM 1/18/2005, you wrote: 
> 
> >Well, the question wasn't if a user should be able to stop 
> jobs/subsystems 
> >(because in this server they need to be able too) but how to log who did 
> >it. The little buggers don't always start it up again... I've noticed not 
> 
> >all facts are being logged in QHST. Often the entry exist about a 
> >subsystem is being ended but no info regarding who did it. Anybody know 
> of 
> >any good exit programs that could be used? 
> > 
> >/G 
> > 
> > 
> > 
> >--------------------------------- 
> >Do you Yahoo!? 
> > The all-new My Yahoo! ­ What will yours do? 
> >-- 
> >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. 
> 
> 
> -- 
> 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. 
>