Wow! It was nine years ago I wrote the first post of this blog. Here I am almost 800 posts later and I am still writing. Fortunately, IBM has "cooperated" and has released a lot of really interesting and exciting things in this time, giving me lots of material to write about.
This where I pick my favorite five posts of the past 12 months, which is always a struggle as there is always so many things to consider:
Another addition to the RPG programming language with IBM i 7.5 and 7.4 TR6 is an operation code that allows me to write to the current job's job log.
I have been using the SQL procedure LPRINTF to write to the job log since 2019. Now I have the ability to do so with native RPG.
The new operation code is called Send Message, SND-MSG, and is accompanied by two new optional Built in Functions, BiF: %MSG and %TARGET.
Just how simple it is to write to job log I will demonstrate below. Let me start with my first example program's source code:
01 **free
02 dcl-s Text varchar(50) inz('Second message') ;
03 snd-msg 'First message' ;
04 snd-msg Text ;
05 snd-msg *INFO 'Third message' ;
|
I am sure many of us have found that when we try and cast, in SQL, from one data type to another the “casting" will fail. This is especially true when moving character representations of numbers or dates to a decimal or date type. With the new release IBM i 7.5 and 7.4 TR6 there is a new SQL built in function that allows for the testing of a cast before it is performed.
Before I start explaining this new built in function let me define the table I will be using, TESTTABLE:
CREATE TABLE MYLIB.TESTTABLE (COLUMN1 CHAR(10), COLUMN2 CHAR(10)) ; |
It has two columns I will be using in this post. For now, I am only interested in the contents of the column COLUMN1, which I can see using the following SQL statement:
With IBM i 7.5 being released IBM has updated its IBM i Roadmap image:
 Click on image to see larger version |
I find interesting:
Since the beginning of time on OS/400, the beloved ancestor of IBM i, six long dates have always used the "1940 rule" to determine the century.
If Year >= 40 then Century = 19
If Year < 40 then Century = 20
2039 is not that far in the future, only 17 years away, IBM has developed a replacement rule, "1970 rule".
If Year >= 70 then Century = 19
If Year < 70 then Century = 20
As part of the IBM i 7.5 announcement IBM has said that the new rule will be implemented in a future release or Technology Refresh.
IBM is giving a foretaste of the new rule in 7.5. I used the word "foretaste" as the "1940 rule" has not been replaced, but the new rule can be implemented on top of it, if you so desire. The rule can either be applied to your entire system, which I do NOT recommend, or it can be implemented just to the current job.
The PTFS for the two new Technology Refreshes:
Are now able for download as PTFs from IBM Support website.
Start planning to download these into a test partition, and get ready for the testing process to validate your applications with these TRs. Don't forget the database (SQL) and RPG PTFs come separately.
<whispers> It might be time to get the latest CUM PTFs to ensure you get all the available PTFs for your release </whispers>
In RPG we have been able to monitor for errors, using a Monitor group, for years. Until IBM i 7.5 and 7.4 TR6 we could only monitor for program and file status codes. I have always preferred CL’s MONMSG that allowed me to monitor by message id instead.
As part of the new release, or new TR for 7.4, there is a new RPG operation code, ON-EXCP, that can be used within a Monitor group to monitor for a specific error message or messages. The syntax is very similar to that of the ON-ERROR operation code:
monitor ; Something on-excp 'CPF1234' : 'RNX1234' : 'RNQ1234' ; Do something else to mitigate the error endmon ; |
I am going to give some examples below so you can understand how ON-EXCP works. Here is my RPG program’s source code:
I am certain in all the videos of the announcements for IBM i 7.5 and 7.4 TR6 we were told there would be no more Technology Refreshes, TR, for 7.3.
Well, it appears that there is to be another Technology Refresh for 7.3, TR12. I found it on the Technology Refresh information page for 7.3 here.
|
It is available on the same day, May 24, that 7.4 TR6 is.
What is available in this TR for 7.3?
A SQL View was added to IBM i 7.5 that makes it easier to retireve information about Journal Receiver. Before using what is described below check my post about getting Journal Receiver information with SQL.
I wanted to write a program that would delete old journal receivers, ones detached from the journal and more than a certain number of days old (to be determined later). I can see the detach date when I use the Display Journal Receiver Attributes command, DSPJRNRCVA, but I can only do this for one receiver at a time, and the command only allows for display or print. Looking at my chart of SQL Views and Table functions I found that is not one for Journal Receivers. Alas, this leaves me having to use an API to get to this information.
The information I desire is:
There is an API that will return to me the information. It comes with the long name: QjoRtvJrnReceiverInformation. Before I go into the example of using this API let me get started with how I made a list of all the receivers in a library. Here I can use a SQL Table function, OBJECT_STATISTICS. I use the following statement to display a list of all the receivers in a library.
SELECT OBJNAME,OBJLIB FROM TABLE(QSYS2.OBJECT_STATISTICS(<library name>,'*JRNRCV','*ALLSIMPLE')) |
Demonstration of IBM i Merlin that was announced yesterday as part of IBM i 7.5 and the latest Technology Refresh for 7.4, TR6.
Most of us knew it was coming, so there is no surprise that a new release for IBM i has been announced. The new release, 7.5, accompanies a Technology Refresh update for version 7.4
IBM i 7.5 will only run on Power 9 and 10 servers.
Many of the new features of 7.5 will not be supported by 7.4 TR6. I will make note here of which are additions or changes that apply to 7.5 only.
To write the posts for this website I need to have examples DDL tables. I often use a Table whose first column contains the row number and a second contains some kind of random number.
While I was illustrating how to fill one of these tables it struck me that there was an easier way to do this, having all the logic in the Insert statement itself.
This is the source code for the Table I commonly use:
01 CREATE TABLE MYLIB.FIRST_TABLE 02 FOR SYSTEM NAME "TABLE1" 03 (FIRST_COLUMN FOR COLUMN "FIRST" VARCHAR(10), 04 SECOND_COLUMN FOR COLUMN "SECOND" SMALLINT, 05 UNIQUE (FIRST_COLUMN)) ; |