Speaking to some of my colleagues on Microsoft products (and using sufficient holy water to cleanse afterwards.) I was told that Active Directory has a tickbox to disable a profile on a given date. After a lot of searching I concluded that we don’t have that on IBMi until V7R1 and the USREXPITV/USREXPDATE keywords, cue everyone in the comments telling me the one I missed.
Given I sometimes get given leaver notifications weeks/months in advance, one of the few times you’ll appreciate people leaving without notice, I don’t really fancy setting a calendar reminder for each one. Despite my best intentions some customers still like their V5R4 so let’s create our own version of the keywords now.
In bulk
The first time I had to consider this was a customer who gave me a list of profiles “Can you disable all of these at this date & time?” Being a programmer, I ended up writing a CL with a long list of CHGUSRPRF commands in it and setup a job schedule as a one-off. It does the job, but the downside of this is it relies on a programmer doing it when I’d rather make it a sysadmin task. This approach also isn’t terribly practical if you want to use it on a rolling basis as you’ll end up with various versions of the program/job schedule, or have to start adding a lot of conditions for date/time into the program.
Table approach
Much easier is having a table somewhere, with some basic information on what user and when. You then point the program at the table and have a simple “if date >= today then get rid of it” with a single CHGUSRPRF that you feed the profile into. The job schedule can then run as often as you want since it’s always looking at the same spot and just checking for current records.
You can then either use your preferred editor (UPDDTA until the end!) Or I chose to put a screen in front of it to do various bits of validation and record who added the user.
Auditing
Something else that became relevant for me in the last couple of years, the auditors want evidence that the profiles were disabled on the date they should’ve been. Now if you’re friendly with your system audit journal you can pull out the relevant information (CP entries work well for me) but perhaps that’s not how you’d like to approach and/or you’d like some confirmation of what the program thinks it did as well?
If you’ve read my previous article on inactive users then you’ll know my woes there, the program I use for disabling/deleting inactive profiles also writes to its own audit table for later review. My new program for disabling on date can also write here with two benefits:
- If for whatever reason my customer isn’t a fan of the audit journal and/or their retention period isn’t long enough then the table can give me the information.
- If there’s a difference of opinion with the audit journal I can see what the program “thinks” it did and trace where/when we had the problem to help work towards “why”.
So, there you have it, a cleaner calendar for me and an “I can do that too” aimed at the Microsoft team. If you’ve got a better way of doing it, or a good way to twist my customers arm into an upgrade to V7, I’d love to hear about it in the comments below.