Display screens of results without having to press Enter

I received a message asking me if there was an easy way in RPG to have a screen constantly update without the user needing to press a key. The idea is that as the program progresses it would write a message to the screen to inform the user of what is happening. Fortunately there is, otherwise I would not have be written this post.

First we need to understand what RPG's operation code Execute Format, EXFMT, does. Simply put it is a combination of a Write operation of the record format to the workstation, followed by a Read operation to retrieve the input from the record format. I can easily replace the EXFMT in any program with a WRITE followed by a READ. If I want to just write a display file's record format to the screen I could just perform a write, but how can I stop the user for using the keyboard while the record format is displayed?

Speeding up CPYF, with selection criteria

Charlie Despres posed a good question in a comment to my original post Speeding up CPYF, "Does this still work if I add conditions to the CPYF?" I assumed he would see the same benefit, but there is only one way to really know, test it!

I used the same file, BIGFILE, and only copy records into the output file, QTEMP/@BIGFILE, where the value of the field FLD1 is in the range of 1,000 to 2,000. There are 12 records in the 1 million records in BIGFILE that fit the criteria.

The only difference from the original programs shown in my last post was the Copy File command, CPYF, statements. This statement, with the default of FROMRCD(*START), was placed in one program:

Speeding up CPYF

Every developer type person who has worked on the IBM i, or its predecessors, has had to use the Copy File command, CPYF, to copy data from one file to another. Most have rarely used more that the first screen's parameters, thereby missing a way to make the command execute faster. For small files the difference is negligible, but in a file of several 100,000 records or more the method I describe below will make a noticeable difference.

I have to thank Stu Haddock for reminding me of this. It is all down to the value of the FROMRCD parameter of the CPYF command.

Investigating about the future of IBM i

Last month the Swedish publication Data3 published an interesting article about the future of our beloved plaform. Two students working at the Handelsbanken AB were asked to investigate the IBM i and its future. They interviewed developers, technicians, and managers from the bank and other companies, asking them about the platform and how RPG compared to other servers and programming languages.

Their conclusions were very positive for both the IBM i and RPG:

Using CL procedures

All of the examples I can find of using procedures on the IBM i are mainly in RPG, with a few in C. This made me want to demonstrate that it is possible to create procedures in CL, and to call procedures using CL programs and procedures.

This is also a time to move from using "CLP" source members to "CLLE", as there are commands that will be used in this post that are not supported by old "CLP" source or "CLP" programs.

Free your thinking, free your code

I have been surprised, and a bit disappointed, to find many examples of RPG code in various social media groups still written in columns. This seems to perpetuate the stereotype of the "AS400" and "RPG programmers" held by many others who do not work with the IBM i, that we are working with an out of date language on an out of date platform.

The reality is different. IBM has spent many hundreds of millions of dollars on the IBM i operating system and PowerSystem servers to make this a modern platform and market leader, which can do so much more than the AS400 could. Part of these enhancements has been the introduction of free format RPG.

Using the Error Subfile for messages in display files

I recently received a communication asking me if there was an easier way to display messages on a display file than using a message subfile. In my opinion there is a much simpler way using the Error Subfile, ERRSFL, keyword in the display file.

I have been using the Error Subfile for many years, so long that I cannot remember when I first encountered it. By using it I do not have to add all the code for the message subfile to my programs. I can just enter ERRSFL into my display and let the operating system do the hard work.