|Editors:||Ted Holt||Managing Editor:||Mari Barrett|
|Howard Arner||Technical Editor:||David Morris|
When you compile RPG with Create Bound RPG (CRTBNDRPG) or Create RPG Module (CRTRPGMOD), there is a Fix Number (FIXNBR) parameter you can set for numeric data errors. However, I can't find a way to see how that is set in a compiled object. DSPMOD doesn't show me. I haven't looked for an API yet. Do you know of a way?
There isn't a way to determine the setting for this from a compiled object, because FIXNBR isn't used to generate an attribute of the program. It's just used to generate code one way or the other. I suggest that you put the FIXNBR parameter in the H spec of the source member. (Not even in a /COPY H spec, and for sure not in a data-area H spec.) This would let you determine the FIXNBR setting by looking at the source code.
If you need to determine whether an existing program was compiled to fix bad numeric data, there is a kludgey way to find out. Set up a test environment, with blank copies of the files the program reads. Create a dummy program described file in QTEMP and initialize it with one blank record.
CRTPF FILE(QTEMP/XX) RCDLEN(80)
Copy the blank record to the copies of the production files.
CPYF FROMFILE(QTEMP/XX) TOFILE(CUSTOMER) MBROPT(*ADD) FMTOPT(*NOCHK)
Now the copies of the production files have invalid data in the numeric fields. Run the program and see if it cancels or not. If you get an error message that says it found invalid decimal data, you know that the program was not compiled to fix bad numeric data.
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.
Please contact Timothy Prickett Morgan at
Phone: 212 942 5818
I work in a shop where programming is still done with RPG/400. Some people call it RPG III. You know, the kind with E specs for defining arrays. I need to edit numbers before concatenating them in character variables. Since we're not using RPG IV (also sometimes called ILE RPG), I can't use the %editc and %editw built-in functions. How can we edit these numbers?
They won't let you use RPG IV, huh? Bummer.
I recommend you use the Convert Edit Code (QECCVTEC), Convert Edit Word (QECCVTEW), and Edit Code (QECEDT) APIs. These APIs are primarily used in applications that format data for output at runtime and are even more flexible than the %editc and %editw built-in functions. They are also messy because they have about nine parameters each and some of them are binary numbers, which are not exactly user friendly, but they work and IBM supports them.
Here's some sample code you can start from. INAMT is the number to be editing. OUTAMT is the edited number. This code uses QECCVTEC and QECEDT. I'll leave it to you to work up the code for QECCVTEW if you want to use an edit word instead of an edit code.
Here's something else I ordinarily don't recommend, but it's quick to implement, especially if you ever worked with RPG II and are used to I and O specs. It's an old technique, so I present it as a historical curiosity. After the advertisement below, I'll show you another way.
Let's continue with the editing in RPG III problem.
You can use a SPECIAL file to edit numbers. A special file is a disguised call to another program.
Here's a program that needs to edit a nine-digit number with two decimal positions using the J edit code.
FSPECIAL CF F 13 SPECIAL EDIT1
A number of that size takes 13 positions when edited, so it is output to the special file with edit code J specified, then read back in from the special file in positions 1 through 13.
Here's the EDIT1 program, which is called when I/O is done to the special file.
C *ENTRY PLIST
Notice that this program doesn't do anything. The editing is done in the calling program, not in the called program. The called program is merely a way of passing data from the output to the input specs in the calling program.
But, as I say, I present this only as a curiosity. If at all possible, use RPG IV to do that editing for you.
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 email@example.com
* Email Howard Arner at firstname.lastname@example.org
Copyright © 1996-2008 Guild Companies, Inc. All Rights Reserved. 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.