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]

Externally Described Data Structures

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]

Externally Described Data Structures

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]

Externally Described Data Structures

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]

Externally Described Data Structures

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]

Externally Described Data Structures

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

[J.Pluta]

Externally Described Data Structures

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]

Externally Described Data Structures

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]

Externally Described Data Structures

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]

Externally Described Data Structures

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

[Guest.Visitor]

Externally Described Data Structures

We use EDS to simplify and standardize our programs. We prefix our data base field names with letters related to the system they are part of. We use the same names replacing the prefix with zz for display names. In the Data Structures we define two External Data Structures, the first we use the data file for our definitions. The second we Add a key word of PREFIX('ZZ':2) to strip the prefix and define the same fields with the zz. (3 lines of code most of the time) In the calcs after reading the file, you move the Data EDS to the display EDS with an Eval and you have populated the whole screen with 1 line of code. In update/Output programs, you Eval back from the screen DS to the Data DS and you have populated the whole file with 1 line of code.

[roryhewitt]

Externally Described Data Structures

Joe, Is MOVE CORRESPONDING in COBOL like the BY NAME suffix in PL/I?

[tdaly@sddsystems.com]

Externally Described Data Structures

> In addition if somebody comes along and prefixes one of the files then nothing gets moved. Personaly I think a MOVEC or EVALC opcode could come in pretty handy. As far as somebody prefixing a file and destroying the MOVEC/EVALC, there has to be a solution. Maybe some sort of keyword on the DS that designates a named relationship, only datastructures with the same named relationship can have a MOVEC/EVALC performed on them. The compiler could then give a warning or error message if a file prefix could cause a problem.

[michaelsoucy@netzero.net]

Externally Described Data Structures

What would be an example of where you would want to use an externally described data structure? I've never use one and want to learn more about them. I have an application where I have two files that contain many fields in them. I want to move the contents of all of the fields in file A to file B. File B contains all of the fields in file A plus 3 or 4 extra fields at the end of the record? Is there any easier way to do this rather than doing a series of EVAL statements in my RPG code? Would this be a place where I could use an externally described data structure to move the fields out to the second file?

[J.Pluta]

Externally Described Data Structures

I think it is.