I’m reminded of an essay I wrote at school “I believe I have no beliefs”, as a good coder I’m sticking to a naming convention!
This is a slightly different take on something I’ve seen discussed in various forms, including on the IBM site here:
https://www-01.ibm.com/support/docview.wss?uid=nas8N1013520
It’s suggested that you look at last sign-on date, or last used date. Both of these are good checks to make, but is it possible a user you want to keep could dodge both of these?
To give you a bit of background on how I got to this point, one of my customers use an interactive session to run their end of day processes. We also run an inactive device purge as they use System/36 which gives them the ever present 1128 device limit to run up against and so if it’s not in use we want rid of it. Reviewing the output of the latter I realised it had removed the former based on a 14 day non-usage threshold.
Now I imagine my customer would be shouting down my door if their nightly process hadn’t run for the last fortnight, so I did some digging. Because this device very rarely gets powered off, and the emulator is generally open 24×7 even if not signed on, we’re never refreshing the last used date on the device. When I WRKOBJ / DSPOBJD my last used date is the late date that the machine was rebooted.
When you stop to think about it this perhaps makes sense, we “used” the session when the emulator was started but is the next day part of the same usage, or a new use? If it’s the former then it probably makes sense the date is not being updated.
Interestingly, at least for me, the emulator didn’t mind the session being taken out from under it. The purge happened Sunday morning and the nightly process ran fine Sunday evening recreating the session as it needed it. I imagine if I watch then around January month end it will be gone again.
My curiosity piqued I did some more investigation and found the same holds true for the inactive user purge they run. If a profile has a job running in the background, which isn’t restarted on a regular basis, then the user profile could be flagged incorrectly as inactive.
A niche case to be sure, but one that could potentially cause my customer headaches if not catered for. The question becomes what is the best way to do that?
You could check to see if the user has an active job, although the system wouldn’t be able to remove the profile it might already have changed object owners that I’d rather it didn’t. For a device we could check whether a job is running, but in the above example my job is inactive since the end of day task isn’t running. You could check for instances of the job with spooled files still present and check the date on them? If you’re using the IBM tools then CHGACTPRFL could be your friend to exempt the relevant profiles from a sweep. Personally having done some reading on the subject I’m partial to the idea of triggering the QLICOBJD API for the session device as part of the initial program.
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/apis/qlicobjd.htm
I wonder if anyone else has come at this particular problem from this end of the trail? If so why not comment below with how you came to it / got past it, perhaps you have a better solution than I.