I am finding that I am encountering variables containing null more often as I interface data to the IBM i that originated from other software and databases. How to handle nulls is becoming one of the more popular questions I am asked.
What is null? Dictionary.com defines it as:
- without value, effect, consequence, or significance.
- being or amounting to nothing; nil; lacking; nonexistent.
Last week I received a request from my manager to merge three reports into one so that he can read it easily on his mobile phone. It has been a long time since I last did it, and when I asked my colleagues if they knew how to do it I received a lot of blank looks.
Let me start by saying I do not want to change the report programs, the printer files they produce are the right width to display on a mobile phone. Fortunately merging spool files is very simple, I can do it all with a few CL commands.
I am not sure how I missed this, two new compiler directives were added to RPG in IBM i 7.2, and I presume the equivalent 7.1 TRs: /SET and its opposite /RESTORE. I would have thought /RESET would have been a better choice than /RESTORE, but I am not IBM.
/SET will temporarily change, what I can only describe as, the definition of definitions. For example, if I want part of my program to use a different CCSID than the rest. Or perhaps I have a piece of code in a "copybook" (a source file member that is only ever /COPY-ed into another) that uses a different date and time format.
What can I change using the /SET:
Before using what is described below consider using SQL to read IFS files.
After publishing a post about reading an IFS file using RPG I received an interesting communication from Jeff Davis:
I would also say explore the fopen, fget and fclose. With these apis you don't have to scan for the crlf characters as they parse the data on those.
So I did what he suggested and investigated the C APIs he mentioned: fopen, fgets, and fclose. What I found convinced me that this is the better way to read an IFS file using RPG.
In my last post, which you can see here, I wrote about defining files within subprocedures and I mentioned that you have to use a File data structure to read the record into. These are defined using the LIKEREC keyword when defining the data structure in the DCL-S (or Data Definition specification in fixed definitions). The LIKEREC defines which kinds of fields of the record are to be included in the data structure:
This is a subject I have mentioned in passing in other posts, but I have not addressed this subject in its own post. I had a discussion with some folks on Facebook who wanted to know how to define and use a file in a subprocedure. It got difficult referring to one part of one post, and another part of another post, etc. I thought it would be a good idea to write a post just about this subject.
Prior to IBM i 6.1 it was not possible to include a file in a subprocedure. You had to define it in the main part of the program to be able to use it in any subprocedure, see the example below. The problem is what when you do this when you use the file in one subprocedure the file pointer is left in the position where it was last used, when you exit the subprocedure and enter another the file pointer remains in that position and can cause unexpected results. This can cause problems as I will show later in this post.