Consolidating some of my Git repositories is ongoing and I have now found some time to take a look at the utilites written for the IBM i on Power. These can now all be found on Github at utils-on-power.
This means that the seperate repositories for DSPOSRLS, DSPPGMLCK and RGZLIB are no more.
Here’s a utility that I wasn’t expecting to need again, but I have just encountered another program that sets a flag to indicate that it’s active and then (occasionally) fails to unset it. So, today, I dug out DSPPGMLCK again (it’s handy having the code on GitHub).
Since I was compiling it all anyway, I also too a moment to add some help text to the command. All of the usual updates can be found at the usual place.
Just a quick note to mention that I have updated the project pages for DSPOSRLS and DSPPGMLCK so that they now include some halfway useful compile and usage instructions. I have also committed some slightly improved README files for both of these utilities.
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.
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.