Re: ending selective sessions in batch

>  From:    dbooth@injectronics.com (Dean Booth)
>  
>  Lucky me, when my overnight batch jobs don't run.
>  
>  My EDI software has a job that must run every night.  It won't if
>  certain users are on and tying up particular files.  This became a
>  problem when we hired a 3rd shift shipper last week.  I can't end my
>  interactive subsystem because I have other users doing other things (I'm
>  using QBASE instead of QINTER, but I'd switch if it would solve the
>  problem).
>  
>  All I have is the user name.  This is a TCP/IP user, so I won't know the
>  device name.  If I could direct the output of WRKUSRJOB to a file maybe
>  I could turn the data into ENDJOB commands.
>  
>  How can I kill sessions in batch when all I know is their user name?
>  
>  thanks, Dean

I do not know the precise commands to do this, just the general strategy.

The EDI job needs to be structured so that it gets to a MONMSG cannot 
allocate exclusive access to particular file for update for whatever reason & 
relevant LCK command to identify user in conflict.  Then you want a loop to 
bombard that user or users with error messages to get the *** censored *** 
out of conflict because of blocking this job that needs to run every nite at 
this time & is estimated how long to run before you may get back into the 
files in conflict, then the EDI job waits 5 minutes & tries the loop again & 
after 15 minutes of looping, it starts sending messages to managers & other 
users identifying the user who is holding up the parade & how many warnings 
have been sent that person or persons so that if there is any co-worker in 
range of their work area to tell them that continued malfeasance can get 
someone fired (hint hint), because for all you know, the conflicting user 
left some job in middle of some program & is off to lunch break.

The message text needs to be sufficiently clear so that the user cannot claim 
they do not understand what going on & just ignore what they do not 
understand.

If there are a limited number of jobs which must be run at a specific time 
each nite & the end users KNOW this, and cannot cooperate, then do as I do 
... I shut down the entire system ... yes I am inconveniencing 100 people 
because of a problem with 2 people & management knows this & when management 
people are doing my job when I am on vacation, they doing the exact same 
thing, because teaching our staff to be network literate means that everyone 
has to be network literate & it is less trouble to just shut down the system 
so that no one can use it when we need semi-dedicated tasks to run.

During end-of-month we often vary off clusters of remote facilities because 
it is simpler to just prevent everyone in an office from being able to use 
the system than trust them to know what programs are safe to be in during EOM.

I have this all the time ... I make long distance phone calls every night to 
fill up voice mail with words to the effect that if I do not hear from that 
person in the next 15 minutes I will assume they went home leaving their 
session active & I will kill their job, corrupting their data, so I can run 
backup, but if I hear from them within 15 minutes then I can adjust my start 
time so as to minimize inconvenience to them.

If you want to shut some person down & you have their identity & you are 
signed onto the system & have the security to shut them down, I do not see 
the problem.  If the person & you are equals in the eyes of management, then 
you are in the position of telling the users of the EDI output that they 
cannot get the data today because of this other department's unwillingness to 
stand aside & let it run ... it is a management people problem to solve, as 
opposed to a technical isssue.

I would be wary of attacking one particular user ... have you talked to that 
person to verify they know precisely what the EDI job is & why they need to 
stand aside to let it run ... it could be a break down of training in that 
person's department, that is solved by the EDI job sending message-all when 
it gets to some check point, then the affected users signing off & the EDI 
job in a loop to see if the relevant files are tied up continuing when they 
signed off but if no success then 10 minutes later send message all active 
again & have it page help desk only after 30 minutes of no cooperation.

Before we abandoned EDI, we were sending our stuff to intermediate files, so 
that individual runs of the most nuisance parts were using files that only 
the EDI was in, and various stages were looped to retry to infinity & send 
messages to selected people that this is retry # 123 & the reason it is 
looping this time is that we cannot update file ABC because users X Y and Z 
are in the way & oh yes they have been asked to get out of the way.

If you are technically more knowlegeable than the person you are butting 
heads with, then you need to stop all JOBQ that they have security access to, 
so that their next jobs cannot run by batch, until yours done & you restart 
their JOBQ.

Al Macintyre  ©¿©
http://www.cen-elec.com MIS Manager Programmer & Computer Janitor
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---