Since I am putting utilities onto GitHub I thought I’d go back and add an older application that I still find surprisingly useful. So DSPPGMLCK now has a (very) brief project page and the source is available on GitHub.
Browsing Posts tagged API
One of the surprisingly non-inuitive parts of the IBM i is that there is no easy way to identify what OS release your machine is on. Well, not if you don’t have enough authority to use DSPPTF.
A common approach is to use DSPDTAARA QSS1MRI which works, but isn’t officially supported. So this approach could stop working at any point and without notice.
The officially supported method is to use the QSZRTVPR (Retrieve Product Information) API. So I did.
DSPOSRLS is a simple command that retrieves and displays the current OS release level. I have posted the source on GitHub so feel free to browse or download it from there.
Another week, another utility. I’m supporting an application which, among other things, includes the concept of Conflicting Programs. This works by attaching an Activity Level to each program – essentially a count of how many instances of that program are active. When someone launches a program, its Activity Level is incremented and when they exit the program its activity level is decremented.
Each program within the application also has a list of Conflicting Programs attached to it. When you try to launch a program, the activity level of each of its conflicting programs is checked and if any of these activity levels is not zero, the program will not start. Instead, you will see a message telling you which Conflicting Program is active.
It’s a simple and (usually) effective method of ensuring that end users can’t cause data discrepancies by executing tasks when they shouldn’t – you can’t start entering transactions when a month end close is in progress, for example. The problem is that the application can only tell you that a program is active – not who is using it. When someone is preventing you from starting the month close and going home by leaving a transaction entry screen open, identifying who is holding things up is something you want to be able to do as quickly as possible. This is where the Display Program Locks utility comes in.
What this utility does is scans the active jobs on the system and, for each one found, checks its call stack. If the offending program is found, the job is added to a list which is displayed on the screen. The screen handling is pretty basic, but sufficient for the environment in which I am using this utility.
Three source files are attached, for the Display File (DSPPGMLCKD.DSPF), the RPG (DSPPGMLCKR.RPGLE) and the Command Source (DSPPGMLCK.CMD). Feel free to take a look and, if you decide to download and compile it, you will be able to use the DSPPGMLCK command to find exactly who is using any given program.
As ever, comments, observations and improvements are always welcome.
So the application I mentioned on Monday was finally approved late yesterday and, today, it’s written and working. There were, inevitably enough, some changes to the spec. The application that has been approved can be executed once an outage has been started and will send a break message to any session still signed on that shouldn’t be, and generate a simple report so the operations folks can visit the offending users with a baseball bat.
This, in itself, wouldn’t be enough for me to bother reposting the code but since I also took the opportunity to develop the application in RPG (or Free Format ILE RPG if you want to be search engine friendly). Doing this gave me a great deal more flexibility over the earlier CL code and also allowed me to prototype the API names into something a lot more readable. You’ll see what I mean if you take a look at the code.
Again, I have filed off the serial numbers and you can take a look at the code here: Lockout.RPGLE
Feel free to copy it, compile it and modify it if it is of any use to you. And if you have any comments or observations, I’d love to hear them.
I do mean it about the baseball bat, though.
There are times (month end, for example) when you need to know which users of an application are signed on so you can respond accordingly. Reliably enough, the iSeries provides all the APIs you need to achieve this.
There are two APIs you need to know about:
QUSLJOB – List Job, generates a list of some or all jobs on the system. This information can be pushed into a user space.
QUSRTVUS – Retrieve User Space, pulls the information out of the user space.
The CL program, below the fold, shows these APIs in action. It does work, although it won’t make any changes – I’m still waiting for final approval to go ahead and write this – and I have filed off a few serial numbers to avoid copyright problems. Feel free to copy it, compile it and modify it according to your own needs. If you have any comments, feedback is always appreciated.
What the program does is read through a table of application users (USERTABLE) and, for each USERID, lists all active jobs for that user in a user space. A nested loop (at Label STEP01A) loops through each job found to retrieve the essential data.
What you do with this retrieved job information is up to you, but I’m thinking in terms of disabling the profile and ending the job.
Update: I’ve just noticed that copying and pasting the code into WordPress causes more than a few oddities in the rendering. So I’ve moved the code into a text file which you can download here: RtvActJob.CLLE
© 2005 - 2012 Paul Pritchard Original content licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Design by SRS Solutions
Talkback