Are You Qualified to Use My Service Program?

Q: I created a service program (Program A) in one library and bound it with another program (Program B) in a different library. When I use the CALLP op code in a program to call Program A and the library in which Program B resides is not in my library list, CALLP fails. Is there any way to get around this problem without adding a library to my library list?

— Vadim Rozen

This email address is being protected from spambots. You need JavaScript enabled to view it.

A: The CALLP op code should work if you qualify the name on the Create Program (CRTPGM) command. You can see what service program is used by displaying the program. If the names are qualified there, they will be qualified when the program is called.

— David Morris

This email address is being protected from spambots. You need JavaScript enabled to view it.

Why Must We Always Argue?

Q: When I display a service program, the exported procedures have a column for Argument Optimization (ARGOPT). All of ours are listed as *NO.

I looked through the manuals and found ARGOPT mentioned in the ILE C manual. It states that if you pass space pointer parameters, you can specify ARGOPT rather than ARGUMENT to tell the compiler to pass the PARM in the register. Are we missing out on anything, or is this just some obscure feature? Back in the CISC days when we were using MI programs, register-based variables were many times faster to process. Is this the case here? When would you use the ARGOPT parameter?

— David Morris

This email address is being protected from spambots. You need JavaScript enabled to view it.

A: ARGOPT improves the performance of call-intensive ILE applications by providing the following capabilities:

• It allows space pointer procedure parameters to be passed in a machine register.

• It allows a space pointer function result to be returned in a machine register.
• It allows the translator to determine if a parameter list is needed to pass parameters to a procedure. If it’s not needed, the storage is not allocated and a parameter list is not passed.

Both bound *PGMs and *SRVPGMs can take advantage of these capabilities. ARGOPT improves the performance of bound calls only, including the following:

• Calls to and from procedures within the bound program
• Calls to and from procedures in a service program
• Calls made through procedure pointers Note that both the caller and the recipient of the call must agree in terms of their optimization setting.

— Bruce Vining

IBM Rochester

Perform a Random Act of Blocking Today

You probably know that blocking sequentially accessed files speeds up processing greatly because each disk access reads or writes a group of records. By blocking randomly accessed files, you can also improve performance in some circumstances.

Let us say a program reads a 250,000-record file sequentially. For each record it reads, it does a random read (i.e., an RPG CHAIN operation) to another file of 300 records. That is an awful lot of random accesses.

You can reduce runtime by reading all 300 records into memory on the first random read. Because there are no further disk reads, further random accesses take place at the speed of memory. For small files that are repeatedly accessed randomly, this approach makes the program fly!

To specify blocking, use the Number of retrieved records (NBRRCDS) parameter of the Override with Database File (OVRDBF) command.

— David Abramowitz

This email address is being protected from spambots. You need JavaScript enabled to view it.

Let’s C If RPG Programs Can Calculate Logarithms

Q: Is there some way of calculating the natural logarithm of a number using RPG IV functions? If there is such a method, I would like to use it in developing a European

pricing routine.

— Lucas Heilbronn

This email address is being protected from spambots. You need JavaScript enabled to view it.

A: Yes, you can easily get a natural logarithm in an RPG IV program. The C language functions library (included with OS/400 even if you don’t have a C compiler) has a log function. This function is available to RPG ILE programs through procedure prototyping. Look at the code in Figure 1 for an example of how to do this.

When this little program runs, x gets the value 6.907755. For your own real-world situation, you want to pass your own variable to log. I just used a literal of 1000 as an example.

The log function is prototyped in the D-specs. To properly create the program, you must use the QC2LE binding directory when compiling.

— Ted Holt Senior Technical Editor

Midrange Computing

CEELOCT + CEEDATM = QDATE + Pizzazz!

The easy way to retrieve the current date and time in a CL program is with the Retrieve System Value (RTVSYSVAL) command, specifying the QDATE and QTIME system values as arguments. Time and date are returned as 6-byte values. If you need something with more pizzazz, use the Get Current Local Time (CEELOCT) and Convert Seconds to Character Timestamp (CEEDATM) APIs, as in Figure 2. When you run this example, you’ll get a message sent to the program message queue saying something like “Today is Sunday, November 29, 1998, 5:57 p.m. Have a nice day.”

— Alex Nubla

This email address is being protected from spambots. You need JavaScript enabled to view it.

And When the PTF Was Bad, It Was Very, Very Bad

We discovered that when we applied PTF SF50736, which was included in cumulative tape TL98342, we were no longer able to overlay fields in a data structure with an array using RPG IV. When we tried, we received the RPG IV error message RNF7303, “Subfield defined with keyword OVERLAY is too big; specification ignored.” This PTF was apparently intended to handle a problem with arrays larger than their actual overlaid data, which would then cause machine checks. The only solution we found to get around this error was to remove that particular PTF.

— Drew Dekreon

This email address is being protected from spambots. You need JavaScript enabled to view it.

Editor’s Note: You may have already discovered and fixed this problem. However, there are a lot of AS/400 shops out there that, for whatever reason, are unable to keep current on PTFs and may run into this down the road. That’s why we here at Midrange Computing felt this was important information to share.

My Message File is Literally Full of Literals

A message file is a useful place to store short, descriptive information that can be used in an application. One of the handiest things about a message file is that a message can be changed to reflect some new function or instruction, but the program does not have to be recompiled. Most of us use messages to a greater or lesser extent by sending them to an interactive program message queue and then displaying them in a message subfile.

Another use for messages that you may not have considered is that you can use them on reports. You can list the text of an error that has occurred in the job, or you can retrieve literals, such as report headings and column headings, from a message file.

The bad thing about using message files, though, is that the messages and their associated text are not easily retrieved. However, that’s all changed now by using the example I’ve provided (see Figure 3). In my example, I use the Retrieve Message (QMHRTVM) API to print message text on a report. I also use the message ID CPF4131 (Level Check on File) from message file QCPFMSG. This particular message has four substitute variables, which must be removed from the message text and replaced with real data. I accomplish this via the RtvMsgTxt procedure on the Eval statement.

The second message, CPFXXXX, is invalid. That is, it does not exist in the QCPFMSG message file. When this message is passed to the service program CCRTVM, the RtvMsgTxt procedure receives error CPF2499. This message ID is loaded in the error parameter data structure. In this case, the RtvMsgTxt procedure calls itself and returns the error text, which will also be printed on the report.

The code shown in Figure 3 is an example of how to use the service program CCRTVM, which appears on the MC Web site at www.midrangecomputing.com/mc/99/04. You can use this as the skeleton for implementing this technique in your own applications.

— Vadim Rozen

This email address is being protected from spambots. You need JavaScript enabled to view it.

I’ve BIN FTPing Save Files

Here’s an easy method of saving data to an AS/400 save file and then emailing it to others at a remote site to load and restore on their AS/400. Just follow these steps:

1. Save the object(s) or library (libraries) in an AS/400 save file (*SAVF) using the standard AS/400 Save Object (SAVOBJ) or Save Library (SAVLIB) command. Don’t forget to account for possible differences in OS/400 release levels between systems.

2. Start an FTP session on your PC (or on your AS/400, depending on which one you are most comfortable using).

3. Here’s the key to making this process work correctly. Enter the FTP command binary in lowercase letters. This causes the data to be transferred as a binary image.

4. Now use the FTP PUT or GET command (the command you use depends on whether you are sending data to the PC from your AS/400 or getting data from your AS/400 and loading it onto the PC) to load the save file onto your PC.

5. Email the file to wherever you want it to go.
6. At the remote site, use the same steps as outlined above to put the save file on the remote AS/400. Make sure the remote site also uses the FTP binary command to ensure the file is transferred as a binary image.

7. Use the AS/400 Restore Object (RSTOBJ) or Restore Library (RSTLIB) command to restore the save file.

That’s all there is to it! — Shannon O’Donnell Associate Technical Editor Midrange Computing

— Brad Stone Associate Technical Editor Midrange Computing

Cat Loses String Manipulation Race by a Furlong

The expanded use of electronic date interchange (EDI) using ANSI X12 and other standards has created a greater demand for building delimited messages, but before you start putting messages together with your favorite operation, consider the performance implications.

Let’s say you are building a message with a maximum size of about 2 KB. The message consists of 40 data elements with a maximum size of 50 bytes each. Assume that each of the 40 data elements contains an average of 25 bytes of data and that the delimiter is already included in the individual data element.

Using CAT

The CAT operation is the simplest way to construct delimited messages. It requires only repeated use of the following operation: The CAT operation concatenates a source string to the end of a target string, meaning it must scan from the end of the target string back to the last nonblank character in the target string. Given the parameters described above, each CAT operation would scan through an average of 1.5 KB (longest scan =

2 KB; shortest scan = 1 KB). Building the message requires 40 CAT operations, meaning that the job would have to scan through 60 KB of data (40 * 1.5 KB) to build a single message. This may not sound like much overhead, but the processor must test each byte as it scans. When building a delimited message using the CAT operation, it is important to keep the size of the target string to a minimum.

Using %TRIMR

%TRIMR works the same way as CAT and is almost as simple, as seen in the following code: The %TRIMR function scans the target string from the end to the last nonblank character and then adds the source string. This results in the same number of bytes being scanned as with the CAT operation.

Using CHECKR and %SUBST

This method requires a bit more effort on the part of the programmer but drastically improves performance. In this scenario, you must manually keep track of the end of the target string, but you need to calculate only the length of the source string, as shown in Figure 4.

Working with the original scenario of 40 data elements of length 50 containing 25 bytes of data each, the CHECKR operations used to build one message would require scanning a total of only 1Kb (25 * 40) as compared to the 60 Kb required by the CAT operation. The Position and Length variables could be defined as length-5 integer fields for maximum performance.

Another option would be to use the SCAN operation in combination with the %SUBST function, assuming there is a specific character to scan for at the end of each data element. Try setting up some tests with multiple- or different-sized messages, and compare the different methods yourself. You’ll notice a difference, especially if you are still developing on a CISC box.

— Lloyd Deviney Lead Analyst, Shared Medical Systems

This email address is being protected from spambots. You need JavaScript enabled to view it.

*===============================================================

* To compile:

*

* CRTBNDRPG PGM(XXX/YYY) SRCFILE(ZZZ/QRPGLESRC) +

* DFTACTGRP(*NO) BNDDIR(QC2LE)

C CAT Source:0 Target

C EVAL Target = %TRIMR(Target) + Source

*

*===============================================================

D Log pr 8f extproc('log')

D Arg 8f value

D

D X s 8f

C eval x = log(1000.0)

C eval *inlr = *on /*********************************************************************/

/* */

/* To compile: */
/* */

/* CRTBNDCL PGM(xxx/AN0C1) SRCFILE(xxx/QCLSRC) + */
/* SRCMBR(AN01C1) */
/* */

/*********************************************************************/

PGM

/*--------------------------------------------------------*/

/* declaration */

/*--------------------------------------------------------*/

dcl &Lilian *dec (9 0)

dcl &Second *char 8

dcl &GregDt *char 17

dcl &Picture *char 50

dcl &Message *char 78 'Today is '

dcl &CurrTs *char 50

dcl &error *lgl /* std err */

dcl &msgkey *char 4 /* std err */

dcl &msgtyp *char 10 '*DIAG' /* std err */

dcl &msgtypctr *char 4 X'00000001' /* std err */

dcl &pgmmsgq *char 10 '*' /* std err */

dcl &stkctr *char 4 X'00000001' /* std err */

dcl &errbytes *char 4 X'00000000' /* std err */

monmsg msgid(cpf0000) exec(goto error)

/*--------------------------------------------------------*/

/* Get the current timestamp & convert to output format */

/*--------------------------------------------------------*/

callprc CEELOCT (&Lilian +

&Second +

&GregDt )

chgvar &Picture 'Wwwwwwwwwz, Mmmmmmmmmz ZD, YYYY ZH:MI AP'

chgvar &CurrTs ' '

callprc CEEDATM (&Second +

&Picture +

&CurrTs +

*OMIT )

chgvar %sst(&Message 10 50) &CurrTs

chgvar &Message (&Message |< '. Have a nice day')

sndpgmmsg msgid(cpf9898) +

msgf(qcpfmsg) +

msgdta(&Message)

Goto End

/*--------------------------------------------------------*/

/* error routine: */

/*--------------------------------------------------------*/

error:

if &error (goto errordone)

else chgvar &error '1'

/*----------------------------------------------*/

/* move all *DIAG message to *PRV program queue*/

/*----------------------------------------------*/

call QMHMOVPM (&msgkey +

&msgtyp +

&msgtypctr +

&pgmmsgq +

&stkctr +

&errbytes)

/*----------------------------------------------*/

/* resend the last *ESCAPE message */

/*----------------------------------------------*/

errordone:

call QMHRSNEM (&msgkey +

&errbytes)

monmsg cpf0000 exec(do)

sndpgmmsg msgid(cpf3cf2) msgf(QCFPMSG) +

msgdta('QMHRSNEM') msgtype(*escape)

monmsg cpf0000

enddo

end: endpgm

Figure 1: Here’s a handy little routine to calculate logarithms in RPG IV.

Figure 2: Use the CEELOCT API to retrieve the System Date in a CL program.

**************************************************************** *****

*Program Information Summary

**************************************************************** *****

*

* Program ID - EXAMP01

* Program Name - How to retrieve messages from message file.

* Programmer - Vadim Rozen

*

* Description

**************************************************************** *****

* This program allows printing messages from message file

**************************************************************** *****

* Program creation:

* 1. CRTRPGMOD MODULE(xxx/EXAMP01) SRCFILE(xxx/SrcFile) +

* SRCMBR(EXAMP01)

* 2. CRTBNDDIR BNDDIR(xxx/EXAMP01)

* 3. ADDBNDDIRE BNDDIR(xxx/EXAMP01) OBJ((EXAMP01 *MODULE))

* 4. ADDBNDDIRE BNDDIR(xxx/EXAMP01) OBJ((CCRTVM *SRVPGM))

* 5. CRTPGM PGM(xxx/EXAMP01) BNDDIR(xxx/EXAMP01) +

* ACTGRP(*CALLER)

**************************************************************** *****

H Debug

**************************************************************** *****

* Files

**************************************************************** *****

* Print file

FQSysPrt o f 132 Printer

F infds(@FP1)

**************************************************************** *****

* Printer information data structure

D @FP1 DS

* Overflow line number

D p1@OL 188 189b 0

* Current Line Number

D p1@CL 367 368b 0

**************************************************************** *****

* Work variable definitions

D #MsgFile s 10 inz('QCPFMSG')

D #MsgLib s 10 inz('QSYS')

D #MsgId s 7

D #RtnMsg s 80

D #RplData s 128

D #RError s 1

**************************************************************** *****

* Procedure prototypes

**************************************************************** *****

* Retrieve Message

D RtvMsgTxt pr 256

D MsgId 7 Value

D RplData 128 Value

D MsgF 10 Value

D MsgL 10 Value

D Error 1

****************************************************************

* Main Line *

****************************************************************

C ExSr Sb1000

*

C Eval *InLR = *On

****************************************************************

* Print message *

****************************************************************

C Sb1000 BegSr

*

* Print Report Header

c Except Header

*

* Retrieve existing message

C Eval #MsgId = 'CPF4131'

C Eval #RplData = 'FILE01 ' +

C 'FILE01 ' +

C 'MYLIBRARY ' +

C 'MEMBR01 '

c Eval #RtnMsg = RtvMsgTxt(#MsgId:#RplData:

C #MsgFile:#MsgLib:#RError)

*

* Print result on report

C Except Detail

*

* Attempt to retrieve invalid message

C Eval #MsgId = 'CPFXXXX'

C Eval #RtnMsg = RtvMsgTxt(#MsgId:#RplData:

c #MsgFile:#MsgLib:#RError)

*

* Print result on report

c Except Detail

*

c EndSr

****************************************************************

* Report *

****************************************************************

OQSysPrt e Header 2 1

O UDate Y 8

O 80 'Demonstrate RetrieveO Message Service Program'

O 126 'Page:'

O Page z 132

O e Header 2

O 10 'Message Id'

O 24 'Message Text'

O e Detail 2

O #MsgId 7

O #RtnMsg + 5

Figure 3: Use this program as a skeleton for using the recursive message text retrieval technique of the service program CCRTVM, which is available on the Web at www.midrangecomputing.com/mc/99/04
.

C ‘ ‘ CHECKR Source Length
C EVAL %SUBST(Target:Position:Length) =
C Source
C EVAL Position = Position + Length

Figure 4: Here are the FTP commands that connect you to the AS/400 and then download data.