Another useful addition to IBM i with the latest round of Technical Refreshes, 7.4 TR1 and 7.3 TR7, is a SQL function that allows you to write directly to the job's job log.
Why would I want to write to the job's job log?
I would use this to write to the job log when something I would expect to happen did not. Or as a record that some part of the program ran, and completed successfully or failed.
The syntax for this function could not be simpler:
CALL SYSTOOLS.LPRINTF(string or variable) |
The latest Technical Refreshes, IBM i 7.4 TR1 and 7.3 TR7, included four additions to SQL that allow us to do things with Data Queues.
In this post I will be describing how I would do things with data queues pre-the latest TRs and post. These are:
But, before I start describing any of the above I am going to need to have a data queue I can use. Here is a CL program I wrote to create my data queue:
Last month I noticed a banner that appeared on the top of all the developerWorks pages notifying us that it was to be closed on December 31 2019.
This has alarmed many IBM i folks who have taken to social media asking what is to become of the valuable information contained within developerWorks?
Yesterday I noticed the following announcement from Barbara Morris, lead developer for the RPG compilers, in the RPG Cafe:
Last week I started writing about the new table functions introduced in IBM i 7.4 TR1 and 7.3 TR7, describing the first of the four table functions that allow me to retrieve information about IFS directories and files. In this post I will describe the other three:
A new IBM i on Power Performance FAQ was released yesterday, November 21 2019.
While you may not think there will be anything in it for you as you only program in RPG, there is a section for RPG and Cobol native I/O.
This is available as a PDF from IBM's website here.
Thanks to the folks at RZKH who downloaded and applied the PTFs for IBM i 7.4 TR1 on the first day they became available, what great service!, I have been able to explore some of the new features added to the operating system we know and love. Amongst the additions to Db2 for i, or SQL, is a number of table functions to list information about the directories and files in the Integrated File System, IFS. My original thought was to write one post about them all, but the more I played with the IFS_OBJECT_STATISTICS table function I came to the conclusion that it deserved its own post.
The IFS_OBJECT_STATISTICS table function returns similar information to the RTVDSKINF command. All I want is just some basic information about the directories and files I choose, but there are many more columns returned by the table function. I encourage you to check the link at the bottom of this post which will take you to the appropriate page in IBM's documentation.
In my folder, MyFolder, I have created the following files and subdirectories:
Today is the day the new Technology Refresh PTFs become available for download for the two most current releases of IBM i 7.4 TR1 and 7.3 TR7.
I wrote about what is included in these TRs last month:
What are the PTF numbers for the TRs?
Fortunately IBM has pages that have all this information, including links to download the PTFs:
When I wrote about securing DDM files I bemoaned the lack of a WRKSVRAUTE command. While ago I stumbled across a Db2 for i View that will display a list of all the users I with DDM server authority.
This view has one of the longest names I have used to date: DRDA_AUTHENTICATION_ENTRY_INFO, and it contains the following four columns:
| Long column name | Short column name | Description |
| AUTORIZATION_NAME | USER_NAME | User profile |
| SERVER_NAME | SRVR_NAME | Target server for the authentication entry |
| SERVER_AUTHORIZATION_NAME | SRVR_USER | User profile on the target server |
| PASSWORD_STORED | PW_STORED | Is the password stored in the authentication entry? |
Here is another example of using SQL can make your life easier, coping with a change of the key in file without having to change the program.
At work we are gradually moving all of the US based IBM i partitions from a PowerSystems model 720 to a brand new model 900. I always thought PowerSystems model 900s could only run IBM i 7.3 and 7.4, it turns out that it will also run IBM i 7.2 but a whole load of PTFs have to be loaded and applied when moving from an older model (that was probably not up to date with PTFs too). The moves have been pretty uneventful, apart a change that makes a process I wrote many years ago fail.
The file QA1ALG in library QUSRBRM has changed, a new timestamp field has been added and that is used to replace the existing date and time fields in the file's key:
The post I wrote last month about the developerWorks closing at the end of this year. This caused a flurry of messages asking me if this meant that this was the end of the "AS400" too.
This is NOT a signal that the end of IBM i is nigh. I have been at various user group meetings where folks from IBM have told us that they have plans for this operating system going many years into the future. They also share an image showing past and the planned future releases of IBM i. After a good deal of "googling" I found this image that was updated after the launch of IBM i 7.4 .
At work we monitor the percentage of ASP used to make sure we do not cross the threshold into "critical storage". Recently the amount of ASP has be slowly climbing, and I was part of a trio asked to determine what could be done to reduce the percentage. One looked for unapplied PTFs, another for exceedingly large files, and I was told to look at "everything else".
I know that one long neglected aspect, that is often overlooked, are the number, size, and age of the spool files on this IBM i partition. There are some spool files that need to keep, certain financial period end reports, but others, compile listing, job logs, do not.
First thing is to determine the size of the problem. Fortunately there is a SQL View that allows me to do this easily, OUTPUT_QUEUE_ENTRIES. I can just run the following statement and have the total number of spool files and total size returned to me:
I first wrote about using Temporal tables when they were introduced as part of IBM i 7.3, back in 2016. I thought they would become widely used, as they provide a way to look at the same data as it was at different times in the past.
Having had three years to "play" with Temporal tables, I have learned many things I can do with them, that I did not know when I first wrote about them. I thought this would be a good opportunity to revisit them, and to share some of the extra tips and tricks I have learned.
One thing to remember, and I always forget, is that all of the tables used must be journaled. For the easiest way to do this refer to my original post about Temporal tables.
For a Temporal table I need a table that will be the "live" table. I have deliberately kept this example very simple, so the data does not get in the way of the important columns needed for a Temporal table. My example table will only contain two "data" columns, the rest are used by the Temporal table process. This is the example table I will be using: