Externally Described Data Structures

[J.Pluta]

I use an externally described data structure (EDS) when I want to pass a lot of data between two programs, such as in a client-server design. Rather than pass 50 parameters, I pass a single data structure with all the parameters. And rather than trying to keep those two data structures in sync through double maintenance or a /COPY, I find an externally described data structure to be a simple, easy way to do it. For your particular question, yes, you could use a EDS. You could perform an EVAL of the EDS for file A into the EDS of file B. An EVAL moves from left to right, so as long as file B was EXACTLY the same as file A (not just field lengths, but types as well - packed vs. zoned especially) you could then set the additional fields in file B and you would be fine. The problem is that if either file chnaged, your program would break. At best, you'd get decimal data errors and at worst you'd corrupt your database. More than once I've wished that RPG had an opcode like COBOL's MOVE CORRESPONDING, but since the compiler folks think we're too stupid to handle a simple MOVE opcode, it's unilkely we'll get something as sophisticated as MOVE CORRESPONDING . Joe

[michaelsoucy@netzero.net]

Where can I find more info about EDS'? How would I define the two EDS' for file A and file B? Can you show an example? How does the EDS' get populated with data? Is there a command that will move the data from file A to the EDS for file A?

[J.Pluta]

If you have a field in a data structure (external or otherwise) that has the same name as a file, it will automatically get updated when you read the file. Or, depending on your release, you can read the file directly into the data structure (check out the various options of the CHAIN and READ opcodes). There are a number of complications, such as that fact that you cannot have the same field name in two different files. If the field names are the same in both files, you can just use an EDS for file B. When you read file A, the fields will get populated and then when you write to file B, those same fields will get written out. When I get a chance, I'll try to write some example code, but until then, check out the manual. To specify an EDS, look at the EXTNAME keyword for the D specification. Joe

[michaelsoucy@netzero.net]

Thanks Joe. I figured it out. I ended up defining a DS with the LIKEREC command, and I think that will work fine for me.

[TCC]

You must be kidding about having an RPG opcode like COBOL's MOVE CORRESPONDING. It's a classic bug breeder. I agree with the compiler folks.

[J.Pluta]

"You must be kidding..." No actually, I'm not! "It's a classic bug breeder." In what way? Joe

[J.Pluta]

Glad you got it working, Michael. I've been up to my eyeballs here getting a code generator to properly handle mouse events. It took a little while to get things properly defined, but now I can define any sort of event and cause it to do just about anything I need. A right-click can become an F4. Clicking on a field can cause a select list to pop up. A mouseover can cause a message to display. All very cool, and no HTML coding required! Joe

[TCC]

You've already answered the question in the second paragraph of your original post. In addition if somebody comes along and prefixes one of the files then nothing gets moved. I've seen too many COBOL file conversions torched and not noticed until months later. In COBOL, you have to look at the compile listing to see what is getting moved. How many people look at the compile listing if the program has no compilation errors. It's just assumed that everything will be OK, but you know what the first 3 letters of assumed spell If you were the only person writing and maintaining the program or procedures were in place for code review at your organization (and how many places do that) then it may be something you might consider.

[DaleB63]

Instead of LIKEREC, if the DS has the name of the file, you just put the 'E' in front of the 'DS' (column 22). It will bring in the field definitions from the file, as subfields of the DS. I find it useful to use an E DS for data areas. Similar to parameter passing previously mentioned, if you have a data area that is to be interpreted as multiple fields, you can define a file that specifies the layout, and then read the data area into the DS. When you create the file, it can have MBR(*NONE), since you'll never actually use it as a file, except for the format.

[J.Pluta]

Personally, I rarely have situations where I would use MOVE CORRESPONDING to move from one file to another. That seems to me to be a database design issue. Typically, I would use this to move a subset of fields from one file to a data structure, which is then used to pass those fields to other procedures. In effect, I use the data structure as an RPG "bean", if you will, with only the fields I need. In that case, it would be simply wonderful to have a MOVE CORRESPONDING. But your mileage may vary . Joe