Generating random numbers part I

There are times for statistical or testing reasons you need a random number. Computers have always struggled to generate truly random numbers, therefore, they use a process called psuedorandomness. Which is defined by Wikipedia as:

A pseudorandom process is a process that appears to be random but it is not. Pseudorandom sequences typically exhibit statistical randomness while being generated by an entirely deterministic causal process.

But how generate one on an IBM i (AS400)?

Capturing QCMDEXC error codes

QCMDEXC is a useful API, that has been around since the launch of the AS400 (IBM i), that is called to execute a single command. It is one of the simpler APIs to call with just two parameters:

• Command string
• Command string length

I have seen many examples of RPGLE/RPG IV source code that looks something like this:

01 D CmdString S 132 02 D CmdLen S 15 5 03 /free 04 CmdString = 'CLRPFM TESTFILE' ; 05 CmdLength = 15 ; 06 /end-free 07 C call(e) 'QCMDEXC' 08 C parm CmdString 09 C parm CmdLength 10 /free 11 if (%error) ;

The programmer has gone "out" of RPG/free, line 6, to be able to CALL QCMDEXC, as the CALL operation is not supported in RPG/free.

On line 7 the programmer has used the 'E' operation extender to stop the program erroring if an error was encountered by QCMDEXC, such as TESTFILE not being in the library list or the file is in use by another job. Then they have gone back "into" RPG/free, line 10, before performing a test to see if there is an error, line 11. But what was the error?

MONITOR for errors in RPG

I am sure all IBM i (AS400) programmers are familiar with the MONMSG command in CL to capture exceptions (errors) and stop an error message from interrupting the program. You can do the same in your RPG code using what IBM calls the "monitor group".

The "monitor group" consists of the MONITOR, ON-ERROR, and ENDMON operation codes. When an error occurs within the "monitor group" it can be handled by using specific status codes, or by the use of one of the following special values *PROGRAM, *FILE, *ALL. *PROGRAM handles all of the program related status codes, 100 - 999. *FILE handles all of the file related errors, 1000 - 9999. *ALL, as it suggests, handles all errors, and is the default for the the ON-ERROR operation.

Added to the user group list: LUG

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.

IBM Technical Refresh 7 continued

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 i Technical Refresh 7

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:

Condition display fields without indicators

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.

Alternative to SELECT is IF-ELSEIF

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.

Validating dates in RPGLE

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.

• Use a date field.
• Use a 6,0 numberic field.

More SQL and dates part II

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.

More SQL and dates part I

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:

Renaming one field in a file in RPG

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:

• Create a 'which file' field to be used to determine which file the search is for.
• Add USROPN to the File specifications, F-spec, for FILE1 and FILE2. This means that the file will only be opened if I use the OPEN operation code to open it.
• Use the value in the 'which file' field to condition which file is opened.
• Decide which file to read by using the 'which file' field.
• Close the file opened.

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.