Wednesday, October 30, 2013

Generating random numbers part II

In Generating random numbers part I I discussed what a pseudorandom numbers are and how to generate them using the CEERAN0 API. In this post I will discuss how to generate pseudorandom numbers using SQL.

I will be using the same scenario I did in part I. I need to generate 1 million random numbers, and write them to a DDS file, RANDOM_F.

Thursday, October 24, 2013

Addition to user group list: MMSA

I received an email from Mark Watts to introduce the Metro Midrange Systems Association (MMSA) from Texas.

"The Metro Midrange Systems Association is a community of IBM midrange users serving Dallas/Ft. Worth and the surrounding North Central Texas Area," Mark explained.

You can check their website at www.metromidrange.org

I have also added this link to the IBM i user groups page. You will find a link to the user groups page at the top of every page of this website, or you can click here.

Feel free to check out which user group is closest to you.

If you know of a group which is not on the user groups page use the Contact form, on right, to send me its details.

Tuesday, October 22, 2013

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)?

Wednesday, October 16, 2013

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?

Thursday, October 10, 2013

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.

Wednesday, October 9, 2013

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.

Tuesday, October 8, 2013

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:

Monday, October 7, 2013

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:

Wednesday, October 2, 2013

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.