I am sure many of you know how I feel about user groups. I believe they are a valuable resource to help IBM i folks to come together, learn from one another, and help spread the joy of IBM i.
I was pleased to receive an email today from Lynne Benedict to introduce me to the Large User Group.
Today was the official announcement date for IBM i Technical Refresh 7, or TR7.
I covered a lot of it in yesterday's post IBM i Technical Refresh 7, and here are some more IBM links I have found today:
IBM has announced the anticipated Technology Refresh 7, commonly called IBM i TR 7.
It includes what IBM describes as a "major enhancement to RPG IV" with the introduction of free format F- and D-Specs. Having worked with the current RPG/free the new /free operations for the F- & D-Specs does look a bit strange:
I received a message after publishing the No More Number Indicators story about an alternate method of conditioning fields in a Display file without using indicators. As the person who sent me this did so as Anonymous I cannot thank them by name, but you know who you are.
I did use this method once, many years ago. I had create a program and display file for the editing of UB82 and UB92, universal billing forms used by hospital and doctors to submit to Medicare and other insurance companies. To put all of the fields on screens made it look too confusing and complicated. Therefore, I tried to make it easier to understand by only displaying the field relevant to the type of claim, highlighted the fields in error, etc. Before long I found I was using just about all of the indicators, *IN01 - 99, on the first couple of record formats. What was I going to do for the rest?
A look in the IBM manual for programming with displays introduced me to Program to Systems fields. By passing a hexadecimal value to a field in the display file I could eliminate most of the indicators I had been using.
The RPG operation code SELECT as been with us for many years. It is also found in many other languages, including CL (see the post SELECT in CL).
An alternative was introduced in one of the IBM i V5 releases, the IF-ELSEIF operation codes. If the first IF is not true then the first of the ELSEIF is executed, just like the WHEN in the SELECT group.
I received an email asking me the following question:
What about date validation?
Dates on a screen are usually displayed as MMDDYY. I don't need to add days or months to it, I need to ensure that the date itself is valid.
I can think of two approaches of displaying and validating dates on a display file.
This post is a continuation of a previous posting More SQL and dates part I, and is based on an email I received from Scott Damery.
"We can all become SQL black belts with knowledge and practice," he reassured me.
In this post I am going to compare SQL to RPGLE/RPG IV.
After my post on calculating the last day of the month using SQL, Calculating end of month part II, I received an email from Scott Damery.
"Take advantage of the many date functions in SQL instead of programming code to provide the information needed," he said in his email.
I am a great believer in: if there is a function to do a process use it, rather than code your own.
Below are the SQL functions he mentioned with a couple of others I found:
I was asked to quickly modify a program. The program currently uses a file, I'll call it FILE1, and the modification was to add a second file, FILE2 to it. If the user selects to search for a certain type of information the the program would uses FILE1, if they want to search for a different type of information the program would need to use FILE2.
All of the fields in FILE1 and FILE2 have the same names and attributes, except for the Part number field. The Part number field, PART, in FILE1 is 20 long, in FILE2 it is 15.
I cannot change FILE2 to make PART be the same length as it is in the other file. I must make the minimum amount of changes to the program to negate the need for it to be audited by the SOX auditors. What can I do?
The changes I would need to make would be:
But that still leaves the problem of what to do with the two PART fields.
But how do I cope with the difference between the two PART fields with the minimum of code changes?
Using the PREFIX keyword in the F-spec would not do, as that would rename all the fields in FILE2.
Then it struck me, I could use a way I had used before in RPG III.
I have been racking my brain to try to remember when I first came across Externally Described Data Structures in RPG. I think it must have been when I transitioned from being a RPG II programmer on the IBM System/36 to a RPG III programmer on an AS400 (yes, I am that old). The others I was working with at the time were all former IBM System/38 programmers and were "fluent" in RPG III. They did not use Externally Described Data Structures. and I was the "newbie" learning RPG III from them, so neither did I.
It was while I was working on a project programming in Synon/2E, and later modifing Synon generated RPG code, did I find them used everywhere. Synon uses Externally Described DS for passing parameters, saving the values of fields in files, and for the Program Status DS (PSDS).
What do I use Externally described Data Structures for?
I received several messages and comments in response to my post Validation: CHAIN versus SETLL informing me that I can do the same in SQL.
Alas, no-one sent me any examples of how they would do it. Therefore, after some Googling I found a way.
Having started the debate on which is faster in my post Validation: CHAIN versus SETLL I decided to put the theory to the test.
I created a DDS file with a single key:
A UNIQUE A R TESTFILER A KEY 7P 0 A F1 3 A F2 5P 0 A F3 30 A F4 3P 2 A F5 50 A K KEY |
And filled the file with a million records, the field KEY contained the values of 1 to 1 million.
I created two almost identical programs. Each one would perform their operation 1 million times, and write a record to an output file with the Start time, End time, and the number of milliseconds it took to perform the 1 million operations. Those programs are listed below: