There are two number-related bugs in RPGIV, both of which can cause run-time errors, which can be difficult to fix.
1. You can like define a standalone field in the D-specs. If you define a field like a signed numeric (Zoned) field from a file, the compiler defines the new field as ZONED if the file field is used in the program, but as PACKED if it is not.
The only safe way to get around this is to define the new field explicitly, e.g.:
D NewField S 9S 0 2. The following code looks OK : D File_DS E DS ExtName(MYFILE) D Struct_1 E DS ExtName(MYFILE) Prefix(D#:2) D CopyStruct S Like(Struct_1) C Clear File_DS C Eval Struct_1 = File_DS C Eval CopyStruct = Struct_1
However, if there are numeric fields in the record format from MYFILE, then both File_DS and Struct_1 will contain zeros in their corresponding numeric fields after the clear and evaluation. But CopyStruct will NOT contain the zeros after its evaluation; it will contain only blanks. This is contrary to what you would expect, and can cause problems if you compare Struct_1 and CopyStruct elsewhere in the program.
To solve this, either define CopyStruct as an externally-defined data structure just like Struct_1, or use MOVE instead of EVAL.
I've not seen anything about either of these counter-intuitive results from IBM or in the Search400.com forums, but I can't be the only one to have had to get around them. Perhaps this tip will help some who end up defining numeric fields as character just to sort out parameter mismatches on calls.================================== MORE INFORMATION ON THIS TOPIC ==================================
The Best Web Links: tips, tutorials and more.
Ask your programming questions--or help out your peers by answering them--in our live discussion forums.
Ask the Experts yourself: Our application development gurus are waiting to answer your programming questions.
Search400's targeted search engine: Get relevant information on RPG.
This was first published in March 2003