EXPORT & IMPORT

[Guest.Visitor]

I have an application that I have converted to RPG IV.My main line procedure calls a service program.In my CALLB to the service program, (or would I be moreaccurate to say a procedure), I am passing several parametersto the service program (procedure?). The parameters arefields from 1 of the files defined in my main line. To getthis to work, I had to define each of the parameters in the modules that they are being passed to using a D-spec.Since the parms are a part of the main line, is it possible tomake them global so that I do not have to specificallydefine them in each module that uses them?

[Guest.Visitor]

On Sunday, January 18, 1998, 09:40 AM, prowak wrote: I have an application that I have converted to RPG IV. My main line procedure calls a service program. In my CALLB to the service program, (or would I be more accurate to say a procedure), I am passing several parameters to the service program (procedure?). The parameters are fields from 1 of the files defined in my main line. To get this to work, I had to define each of the parameters in the modules that they are being passed to using a D-spec. Since the parms are a part of the main line, is it possible to make them global so that I do not have to specifically define them in each module that uses them? I would suggest that the best solution here depends on why you want to do this:

• If it is so you dont have to hardcode field definitions in your called procedures, then you can use externally described data structures to base the definitions in your procedures. See Joe's "No Topic" thread in this forum for an example. Or if these common fields are not from your database, you can create a member that only contains the D-specs for these fields and use /COPY to copy them into each module (or procedure) that requires them.[*]If it is because you want to share the data values, you could use EXPORT/IMPORT, but you stilll need to specify the field in the D-spec of your called procedure (with the IMPORT keyword). I personally prefer using parameters where possible as it documents clearly what is being passed where.[/list]btw. when you use CALLB you are calling a procedure. Derek

[Guest.Visitor]

Derek, I'd like to pursue the 2nd of your suggestions. You said that I could use EXPORT/IMPORT. As the application is now, I 'm passing the procedure data from my main line via parameters. And I'm using D-specs to define each of the parms. I am currently not using either EXPORT or IMPORT in my main line or any of the procedures. Am I doing this correctly?

[Guest.Visitor]

I understand your position on global variables. I just want to see if I should be using EXPORT/IMPORTso that I wouldn't have to define all the parms that I am passing,within each procedure. Thanks for any direction you can offer with this.

[Guest.Visitor]

On Monday, January 19, 1998, 05:31 AM, prowak wrote: Derek, I'd like to pursue the 2nd of your suggestions. You said that I could use EXPORT/IMPORT. As the application is now, I 'm passing the procedure data from my main line via parameters. And I'm using D-specs to define each of the parms. I am currently not using either EXPORT or IMPORT in my main line or any of the procedures. Am I doing this correctly? I'm still not sure what the problem you are trying to solve is, so I'm not sure if using import/export is an appropriate solution or not, but here's an example that should illustrate the mechanics: DDS for physical file yourFile:

 *--------------------------------------------------------------------- A R RCD A FIELD1 30A A FIELD2 7P 0 *--------------------------------------------------------------------- 

Your mainline program:

 *--------------------------------------------------------------------- FyourFile IF E DISK D DoSomething PR EXTPROC('MBR2') D SharedStruc1 E DS EXTNAME(yourFile) IMPORT D SharedField1 S LIKE(Field1) IMPORT C READ yourFile 99 C EVAL SharedField1 = 'Hello' C C CALLP DoSomething C C EVAL *INLR = *ON C RETURN *--------------------------------------------------------------------- 

This is the procedure in your service program (called MBR2):

 *--------------------------------------------------------------------- D SharedStruc1 E DS EXTNAME(yourFile) EXPORT D SharedField1 S LIKE(Field1) EXPORT C SharedField1 DSPLY C Field2 DSPLY Reply 1 C C RETURN *--------------------------------------------------------------------- 

When you run this it duly displays "hello" and the value from Field2 found in the record read by your mainline pgm. Things to note:

[*]It doesnt appear that you can do this the other way round (ie. import into your *srvpgm from a *pgm object).[*]The srvpgm procedure with the export keyword must have the entry point code ie. you cant export from within a subprocedure.[*]If you have multiple pgms importing, say SharedField1, they are using the same piece of storage. This means a change by pgm1 will be seen by pgm2, so be careful how you use this.[/list]I am very much of the same view as Joe regarding using global variables. One of the best techniques I know for producing reliable, maintainable code, is to limit the scope of data (variables) to the minimum necessary for the task. Global data is to software is what *allobj is to security. Sure its easier to just give everyone *allobj, but it's rarely a good idea.... Derek

[Guest.Visitor]

On Monday, January 19, 1998, 03:49 PM, prowak wrote: I understand your position on global variables. I just want to see if I should be using EXPORT/IMPORT so that I wouldn't have to define all the parms that I am passing, within each procedure. Thanks for any direction you can offer with this.

---

1. Have you considered defining your fields in a data dictionary? You can put them in a DDS and create a (dummy) physical file from that source. Then you can reference those field definitions in your programs with the LIKE keyword. The dummy file is only needed at compile time. 2. I wholeheartedly agree upon restricting the use of global variables. There are times when they are useful, or the only way to accomplish something, too. Eg. i had no other way of letting MYPGM communicate with a triggerprogram, as the parms taken by a trigger - allthough i supply the code - are defined by the OS. In any case those usages have to be extremely well documented. 3. Global variable (storeage) usage apparently was not the question asked, but variable definition in one place. Martin. Regards, Martin.

[Guest.Visitor]

You may find the following article to be of interest: RPG IV Style: Defining Data href="http://www.news400.com/theRPGsource/199801/">http://www.news400.com/theRP Gsource/199801/ Regards, Martin.