if you dont want to use option 4, from the WRKACTJOB, you write a program to perform the WRKACTJOB to a printer-file, read the printer-file for the user(s) and then execute the command to end their job.

of course, this does not take into account their signing back in. for that you would have to put a WAIT statement in the CL or call the SLEEP command to allow the program to wait the amount of seconds you want it to be dormant, then loop through the process again.

doing this each 300 seconds (5 minutes) for a specified time range, might discourange your rogue user.

i do question as to why you would target a specific user, and not just end the sub system to prevent everyone from signing in during a specified time.

-sarge

Sounds like you want QINACTITV and QINACTMSGQ but for a single user.

Sorry, sarge, but I would not WRKACTJOB to *PRINT. That makes your code dependent on the report format, which is subject to change via OS upgrade or even PTF.

You should use the List Job (QUSLJOB) API. The qualified job name parameter would be along the lines of '*ALL      JOHNDOE   *ALL  ', and status *ACTIVE.

You also want only interactive jobs. You could mess with optional parameter 2 to get only interactive jobs, but it might be easier to use format JOBL0100 and just search the returned list for interactive jobs only. Job type is one of the fields on JOBL0100, so no extra call is needed for this.

The tricky part, whether you use the API or some other means to find the jobs, is going to be knowing if the job is idle or not. Or did you want to kill them after a certain time of day, even if they're actively working? If you want to know if they're active, I'd probably go after number of interactive transactions, and you'll have to recheck after some interval. You can get it from QUSLJOB with the optional parameters, but Retrieve Job Information (QUSRJOBI) API might be easiser, in JOBI0200, or there's an elapsed version in JOBI1000.

If you mean you want to end the job of any (all?) signed on user(s) at while you run something else, (a common request) you have two options:

1) TFRJOB to QCTL and then ENDSBS QINTER

2) Write a little program as sarge suggested, using the "List all Active/Signed On Users" API and then cycle through them issuing an ENDJOB *IMMED to their job.

One of my clients has this issue too. Their operating hours are from 8:00 AM to 8:00 PM, although user may sign on as early as 4:00 AM.

If they are going to run their nightly routines or backup, they want everyone off the system. To prevent them from signing on, the previous IT support "firm" told them to type in ENDSBS QINTER from the console. Then run their nightly routines.

This was a huge problem for me and mine when we started working on their systems and what we were doing (SEU/PDM, i.e., programming) would not impact what they were doing. But then suddenly we kicked off in the middle of a session.

So we wend back and forth and ended up writing a program that checks for active/signed on users and then issues the ENDJOB *IMMED command, but skips over certain user profiles if they're active.

Oh, and if you want to prevent them signing on during certain hours, check out CHGACTSCDE. You can set hours when they're allowed to sign or or not. I've not used this, but I believe what it does is switch the profile between *ENABLED and *DISABLED at your specified times. But this will not end a job that's already active during the "not allowed" times. Active jobs will continue to be active, so you still need another method to end those jobs.

One thing we did at the first place I worked was have 3 interactive subsystems active and a simple job router for signon purposes.  All jobs identified as OPS would log into QCTL, all jobs identified as programmers would log into DEVINTER, and everyone else would log into PRDINTER.  At 6pm PRDINTER would be ended, all general users would be ended, and the overnight jobs could then proceed through normal schedule.  DEVINTER would remain active so that programmers could log in to respond to on-call situations, without the risk of general users being able to log in.  DEVINTER would be ended for system saves, and other system management tasks.

In actual operation, the operators didn't just kill a subsystem, they would send out general alert messages that a subsystem was going to be bought down and to finish what you were doing or call ops for a short extension.  Some would even call round the users who were still logged in to remind them before their jobs were killed.

dale, i considered that before i wrote it. i agree that the report format can change at any OS upgrade or PTF, but it appeared that clbirk was not familiar with the different subsystems.

we set up different subsystems and scheduled when they were available to users. it seemed from the question that only ONE person was being singled out, and since chopping fingers off did not appear to be a valid solution, i tried to keep it simple.

-sarge

Dale, CHGACTSCDE and DSPACTSCD only support Active signon. That is, you tell it when the user profile can sign on, you have no way to say when it can't.

Also, it is restricted to 1 entry per user profile, so effectively you have to tell it that user "BOB" is allowed to sign on from 7:00 AM to 8:00 PM Monday to Friday. Signon attempts outside that schedule are rejected.

CHGACTSCDE USRPRF(BOB) ENBTIME('07:00:00') DSBTIME('20:00:00')
           DAYS(*MON,*TUE,*WED,*THU,*FRI)

The disable time, DSBTIME(), specifies the "can't". At ENBTIME user profile is enabled, and at DSBTIME it's disabled. After which it remains disabled, preventing new sign-ons, until the next ENBTIME.

But, as you say, it is only one entry per user, so,  can't have two windows per day per user, nor can you have different windows on different days.

But, the question is moot. The problem was how to end the job of a certain user.

Actually, I'm just thinking that you could use QINACTITV and QINACTMSGQ. Instead of setting QINACTMSGQ to *ENDJOB or *DSCJOB, set it to the name of a message queue, and write a program to handle the messages. That program could ignore messages for all but the specific problem user.

Or, do what we did during the System/3 era; send Guido to the user's desk to explain how not signing off causes all sorts of, um, problems . . . some of which are very painful.     

Ah good point, we did used to report these sorts of folks to their managers, and it would end up on the performance review, and in some cases their employment record. But then back in those days performance reviews meant something and entailed the reciept of extra green appreciation vouchers for the year following.