| Editors: | Ted Holt | Managing Editor: | Mari Barrett | |
| Howard Arner | Technical Editor: | David Morris |
|
Volume 1, Number 7 sponsored by:Tiger Tools COMMON
|
|
|
|
|
|
Automatically Reply To Inquiry Messages Hey, Ted: Sometimes a certain CL program issues an error message and asks the operator to answer with G or C. I want the program to automatically respond with a G every time and continue processing. I have a Monitor Message (MONMSG) for the message but it still comes back requesting the operator to enter a G or C. I know this is possible, but I don't know how to do it. Can you help? You've asked a good question. One of the things that make OS/400 such a robust and industrial-strength operating system is its message-handling architecture. Certainly, the operating system can automatically answer messages for you, as you surmised. This basic technique is one that every CL programmer needs to know. First, though, you need to understand why the MONMSG did not solve your problem. The program is issuing an inquiry message. MONMSG can only be used to trap escape, status, and notify messages. Most programmers never monitor anything but escape messages. To solve your problem, you must do two things. First, you must add the message ID and the desired response to the system reply list. Second, you must tell the job to refer to the system reply list for responses to inquiry messages. The system reply list is a list of pre-selected responses to inquiry messages. Use the Work with System Reply List Entries (WRKRPYLE) command to edit the system reply list. Read the reply list; it's possible someone else has already included a reply to the message in question. You can use the Add Reply List Entry (ADDRPYLE), Change Reply List Entry (CHGRPYLE), and Remove Reply List Entry (RMVRPYLE) commands from the command line to modify the reply list entries. I much prefer to use the WRKRPYLE screen. WRKRPYLE runs those commands anyway. Each reply list entry needs a sequence number, which is the entry's order on the list. The system searches the list from top to bottom, according to the sequence numbers. Unless you have two or more entries for the same message identifier, the order doesn't matter. The answer can be a string of up to 32 characters, or you can use one of the special values. *DFT tells the system to answer the message with the default reply. *RQD forces the user to answer the message, as if the reply list weren't being used. In addition, a DUMP parameter tells the system whether to dump the job when it answers the message. The comparison data parameter allows you to apply a response to a message only when the message data matches a certain value. I'll illustrate this parameter in a moment. The second step is to force the job that issues the message to use the system reply list. To do that, specify INQMSGRPY(*SYSRPYL) in the Submit Job (SBMJOB), Change Job (CHGJOB), Create Job Description (CRTJOBD), Change Job Description (CHGJOBD), or Batch Job (BCHJOB) commands. If you've never used the last of these commands, don't sweat it. When you specify INQMSGRPY(*SYSRPYL), the job will check the system reply list whenever it encounters an inquiry message. If a reply list entry matches the message, the system answers automatically. If there is no matching reply list entry, the operator has to answer the message. In order to help you understand the automatic reply technique, here's an example. Let's say that you have a Save Object (SAVOBJ) command in a CL program that saves some objects to a save file. This gives you an easy backup from which to restore something goes wrong. Here's your SAVOBJ command: <pre> SAVOBJ OBJ(MYOBJ1 MYOBJ2) + LIB(MYLIB) DEV(*SAVF) + SAVF(MYSAVELIB/MYSAVF) </pre> Every time this program runs, the system halts with message CPA4067, which reads, "Save file MYSAVF in MYSAVELIB already contains data. (C G)". If you want the system to automatically answer this message, add an entry to the system reply list: <pre> ADDRPYLE SEQNBR(800) + MSGID(CPA4067) + RPY(G) </pre> Use one of the methods mentioned to make the job that runs the SAVOBJ command use the system reply list. I use CHGJOB here as an example: <pre> CHGJOB INQMSGRPY(*SYSRPYL) </pre> Maybe you only want the automatic reply for save file MYSAVF, but not any others. In that case, you must use the CMPDTA parameter. First, display the message description for CPA4067: <pre> DSPMSGD CPA4067 </pre> You'll see that the message text is "Save file &2 in &3 already contains data. (C G)". The save file name is represented by &2, which means it's the second parameter in the message data. Choose option 2, Display field data, to see how the parameters are defined. Notice that &1 takes up 10 characters, so the second parameter must start in position 11: <pre> ADDRPYLE SEQNBR(800) + MSGID(CPA4067) + CMPDTA(MYSAVF 11) + RPY(G) </pre> One last point, and then I'm done. Don't use the system reply list if you can find a way to avoid receiving the inquiry message. In this example, you can avoid the inquiry message by running the Clear Save File (CLRSAVF) command to clear the save file before the SAVOBJ runs. -- Ted
Subscription And Advertising Information
Subscription Information To unsubscribe, change your email address, or sign up for any of Guild Companies, Inc's free email newsletters, visit http://www.itjungle.com. Hit the SUBSCRIBE button on the homepage and it will lead you to our online subscription system. When you sign up for one of our e-newsletters, you can be assured that your e-mail address will NEVER be sold to an outside company.
Advertising Information Please see our advertising opportunities and pricing at http://www.itjungle.com/advertising.html
Or contact Timothy Prickett Morgan at
Phone: 212 942 5818
Email: tpm@itjungle.com
|  |
|
Hey, Ted: If the result of an RPG IV EVAL operation is too large to fit in the assigned variable, I get error RNQ0103, which says, "The target for a numeric operation is too small to hold the result (C G D F)." Is there a way to make my program trap such an error and keep running? There sure is. First, let me show you a couple of ways that you can trap these errors if you're at V4R5 or before. Then I will show you an easier method that you can use with V5R1. Here's some code that will produce the error you describe. The product of x and y is 98999.01, which doesn’t fit into a variable with only three digits to the left of the decimal point:
<pre> One way to trap an eval error is to check in advance that the result will fit in the receiving variable. In the following code, the absolute value of the product of x and y is compared to the maximum value that z will hold. If the test fails, the value of z is not changed and the error indicator (err) is turned on. If the test succeeds, the program carries out the multiplication and the error indicator is turned off:
<pre> Another way to trap an eval error is to place the eval operation in a sub-procedure. The sub-procedure should include a *PSSR subroutine to handle the error. In the following example, the doMult sub-procedure carries out the multiplication. Notice that I have included an error parameter in the parameter list to indicate whether the eval completed successfully or not:
<pre>
P doMult b
C eval error = '0' If you are using V5R1, you can use the new monitor operation. The monitor operation code in the following example governs the eval operation. (If error 103 (RNQ0103) occurs, the error indicator is turned on):
<pre> Here is the same code using free-format calculations. Notice that eval may be omitted in free-format code.
<pre> Thanks very much to Barbara Morris of IBM for her help in answering this question. -- Ted
One of the great things about the OS/400 community is that it is indeed a community. We may be all working from our cubicles, but we are all connected and trying to figure out how to best employ the computer technology at our disposal. There are more than a few ways to skin any cat, and if you have a clever and unique answer to a problem that one of our Midrange Gurus has solved, we'd love to hear from you. This newsletter is an open dialog, and we value your input as well as your readership. It goes without saying--but we'll say it anyway--that your hard technical questions pertaining to real world problems are equally valuable as a foundation for this newsletter as are your programming insights. We hope you find all the editions of Midrange Guru valuable, and we are going to work hard to make sure that they are.
If you have a tough problem, our gurus can probably help. Their mailboxes are always open. * Email Ted Holt at tholt@itjungle.com * Email Howard Arner at harner@itjungle.com |
This document may be redistributed freely and enthusiastically by email, but only in its unedited form. Thanks for your cooperation.
Midrange Guru is a registered trademark of Guild Companies, Inc. IBM, AS/400, iSeries, OS/400, and eServer registered trademarks of International Business Machines Corp. All other product names are trademarked or copyrighted by their respective holders.
