Have you ever had one of those "Aha!" moments when, as we say in England, the penny drops when someone says something and you are left thinking: "Why didn't I think of that?" I had one of those moments at the OCEAN user group technical conference during a presentation by Paul Tuohy on embedded SQL in RPG.
I have described before what SQL Views are. If you look at the object attribute it is a "LF", but it is not Logical file. Confused?
I was surfing through IBM's developerWorks website looking for information about a Technology Refresh, TR, when I noticed that pages for IBM i 7.1 TR11 and 7.2 TR3 are now on that website.
On Friday I was asked if I could help with a compilation error for a RPGIII program. When the source was compiled it produced a CPF6301 message, see below, and the programmer could not understand what it meant or how to fix it.
Message . . . . : Program PGM1 in library LIB1 is not created as CPF6301 received. Cause . . . . . : Compile terminated in phase QRGRT at MI instruction number '00000'X with message CPF6301. Text for message is: ERROR IN COMPILER. COMPILE TERMINATED. |
The original contents of this page have become obsolete, go to this page for up-to-date information.
For many releases of IBM i we have been able to put keyword in the H-spec/Control options that are the same as the parameters in RPG's compile options, see here. The same is also available in SQL for RPG objects with embedded SQL, SQLRPGLE.
I have given some examples in the past of using the SET OPTION statement in SQL to turn off commitment control. There are a multitude of other options that mirror options in the SQLRPGLE compile commands. I am not going to list all of the options in this post as IBM provides them all on their web site, there is a link at the bottom of this article to the page. I am only going to show what I think are the most useful.
This video was produced by COMMON Europe of a presentation given by Aaron Bartell on how Node.js can interface with DB2 and RPG on the IBM i.
The germ for this post came from a comment made by Glenn Gundermann on last week's Display screens of results without having to press Enter:
How would you do it for the times you don't want to lock the keyboard? You might want to have a screen being displayed to allow the user to do actions but if they don't, perform an action after a timeout.
After a bit of playing I have a solution that will have a screen time out if someone does not press a key in a certain amount of time. This is just simple example to demonstrate the method I found. In the example the user will be presented with a screen they can either press Enter, F3 to exit, or do nothing. If they do nothing after two seconds the program will proceed and display a second screen.
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?
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:
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.
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:
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.