Returning Data Structure from sub procedure.

[jj_dahlheimer]

Looking at returning a data structure from a sub procedure in a service program and I read a few articles and it seems to be working properly but wanted a second opinion on a couple of things.

First is it the best way? I am returning a data structure with address info in it. I don't like that I have to have the data structure definition in my copy book as it will get copied into every program regardless if it needs it or not. If I move it to my service program then my program won't compile as it sees the procedure definition referencing it.

// in copy book
Dcl-Ds addressDs qualified;
         prefixName char(3);
         firstName char(15);
         middleIntial char(1);
         lastName char(25);
         suffix char(3);
         streetAddress char(32);
         apartment char(10);
         address2 char(32);
         address3 char(32);
         address4 char(32);
         city char(25);
         zip char(10);
         deliveryCode char(1);
         poBox char(1);
         companyName char(30);
         scanZip char(10);
       End-Ds;

dcl-pr OrderP_GetSoldToAddress likeDs(addressDs);
        company packed(3) const;
        order packed(8) const;
       end-pr;

Secondly, should I be using a different technique for returning a lot of like information. I don't really want to write a procedure for each piece. I read quite a few articles on this also but most were older.

Lastly if I need to add something to this data structure I am kind of SOL correct. I would either have to add it an optional parameter and populate it there or change the data structure and recompile every program that uses it.

[TedHolt]

Re: Returning Data Structure from sub procedure.

First is it the best way?

I don't know what best means. It's a good way.

Lastly if I need to add something to this data structure I am kind of SOL correct. I would either have to add it an optional parameter and populate it there or change the data structure and recompile every program that uses it.

IBM has a lot of API's that can return the data in different formats. There is an input parameter, eight bytes long, with a format ID in it. The data comes back in whichever format you specify. For example, QMHRTVM can return data in four formats: RTVM0100, RTVM0200, RTVM0300, RTVM0400. See this link for more info. You could define new formats when you add more subfields to the data structure. I think most people just recompile everything.

[Scott Klement]

Re: Returning Data Structure from sub procedure.

In addition to Ted's comments, I would also suggest using the TEMPLATE keyword so that your DS in the copybook doesn't use up memory.

Have the programs that need to use it define their own DS using LIKEDS() against your template, and then use that as the return value of the call. That way, you know they are using the right format but the actual memory-using definition is not in the copy book. It also lets each caller make their own DS with it's own name (as opposed to using the one defined in he copy book) which can be very useful, especially if a caller might need multiple copies of a structure.

[jj_dahlheimer]

Re: Returning Data Structure from sub procedure.

I always try and ask is it the best way, maybe it's implied when posting on a forum but just in case someone can see what I am doing and thinks why wouldn't you do it this way. Rather than just focusing on the question itself. With some of the updates that have been made available the articles I come across don't always use the most up to date techniques so maybe what I am doing is outdated. Etc...

I changed my DS to template in my copy book and use that for return values while using the likeds in all the other places. Works well.

Noticed something though is that I can add or remove values from my data structure and it seems like the programs that use it continue to function without being touched. That seems odd to me. Thought that would cause an issue but the programs seems to work and keep their copy of the DS until they get recompiled. Which is ideal but unexpected.

Thanks.

[Scott Klement]

Re: Returning Data Structure from sub procedure.

Yeah, RPG just treats DSes as strings, so it just copies the data as a string over the DS. If the DS formats match, this results in the right values in the right subfields. If they don't, though, you'd have a mess. That's why using TEMPLATE and LikeDS() is important, it makes sure the DSes have the same format.

One nice thing about it is you can add new fields onto the end of your return value, and callers that don't need these extra values don't necessarily need to be recompiled.

The down side, of course is if you make a change to the fields (aside from adding new ones on the end) such as changing the length of a field, or adding a field in the middle, or changing the data type of a field, etc, then you have to be careful to make sure all callers get recompiled with the new definitions. Personally, though, I haven't found this to be a problem.

[Rocky]

Re: Returning Data Structure from sub procedure.

1.) Put templates in your copybooks. When you need to use a DS just create a LIKEDS in your program referring that template. You do this by simply adding TEMPLATE on the DCL-DS statement.
2.) Always has the caveat of "It depends" on what you're trying to accomplish. If you'll ALWAYS want all of the information returned then have it all returned. If not, have a routine that essentially performs an "open" that returns # of records that fit the criteria, a routine that "fetches", a routine that returns each subset of the data last fetched data set.
3.) Using #2 would offset this problem somewhat as you're just creating routines that return subsets of the data. But yes - if you change what a routine returns, you'll have to change the programs that use that routine.

[jj_dahlheimer]

Re: Returning Data Structure from sub procedure.

1. That is what I did.

2. I think in most situations in our shop if a programmer wants any kind of address info they are probably going to want all or at least most of it and instead of making the calls complicated or making them make multiple calls this seems like a good way to do it. But I will have to reevaluate after a while if I get more people to use it. Right now I need it all and suites my needs well. Or if I come across another situation where that might not be the case I will have to look at writing it a different way.

3. I was surprised also but you can add to the end of a data structure with no issues. See Scotts last post. Very nice to me as I am sure I will have missed something along the way.

Thanks.