subprocedures and the LIKE keyword

[Guest.Visitor]

You could code an external DS in the D-Spec that references the file to pull in the field definitions. Then use BASED(NoMemoryBlahBlah) so the DS defintion doesn't actually take up any memory. Then your LIKE should work. Opening and closing files is definitely a performance bottleneck. Don't open and close files unless you really need to. If Not(%Open(MYFILE)); Open MYFILE; EndIf; If your activation group keeps getting destroyed after each call, then the file may very well get closed for you between calls - not desireable. Use an AG of *CALLER if possible, but not *NEW. Chris

[Guest.Visitor]

You could code a D spec like this: D dsPolMst E DS ExtName(PolMst) D Prefix(P_) This will go get the record definition for this file POLMST and load it with the P_ prefix. As far as opening and closing the file in the subprocedure, could you put this sub-proc in a service program, open it (say, every morning, and leave it open until sometime later?). I would try that. Hope this helps.

[K.Forsythe]

The other suggestions are great, I would add that a Named activation group might be a good choice for this sort of service program, so that it would be loaded once and remain loaded until the user signed off or reclaimed it.

[B.Morris]

Chris Ringer wrote: > > You could code an external DS in the D-Spec that references the file to pull in the field definitions. Then use BASED(NoMemoryBlahBlah) so the DS defintion doesn't actually take up any memory. Then your LIKE should work. > It would be a good idea to put this E-DS definition in the same /copy file as the prototype. And use PREFIX or QUALIFIED, to avoid name conflicts.

[K.Forsythe]

Rather than making the Copy book file specific as discussed earlier. If you have a reference file that contains all the field definitions for your application, simply code one externally described data structure that pulls in all the definitions for your app, and then use the prefix as Barbara suggested to avoid conflicts. Also use the BASED keyword to avoid allocating memory for this large data structure. This simple statement can be included in every module you write, making LIKE statements universally available throughout your app.

[Absolutely_Nobody]

What is the recommended method of passing these data structures back to the called program ? As the return value like the code below ? Or, by using BASED and using a pointer ? <hr width=50 align=left>Code ('http://www.mcpressonline.com/mc/showcode@@.6afc7ec0/5')

[Absolutely_Nobody]

What is the recommended method of passing these data structures back to the called program ? As the return value like the code below ? Or, by using BASED and using a pointer ? <hr width=50 align=left>Code ('http://www.mcpressonline.com/mc/showcode@@.6afc7ec0/6')

[K.Forsythe]

In general it will not make much difference. Parameters are usually passed by reference (meaning that its the pointer to the data structure that gets passed - not the data), which means that either way you code it the basic result is the same. The address of the data structure is passed. As long as both procedures involved have the same definition for the data structure it will make little difference. Using the pointer method does allow for a couple enhancements: 1) By using the BASED keyword, one of the procedures does not allocate memory for the variable, saving some amount of memory. 2) If both procedures do not know the exact length of the data being passed, then a null terminated string could be used with the pointer to handle that situation. In my opinion those are fairly minor reasons to use that technique, so if you prefer the more traditional non-pointer logic, that should be fine, and may be less intimidating to your pointer challenged colleagues. Have fun with it, Kevin

[Absolutely_Nobody]

I am using an external data structure to get all of the fields from the field reference files ( which is rather large ) to make the fields universally available. I have a /COPY member for this so I can use independently of my procedure prototype and application specific fields. Are all of the fields from the field reference external DS getting memory allocated in every module if I don't use the BASED keyword ?

[Guest.Visitor]

We have a file containing a code field, its description plus a couple of other associated fields that is used in just about every program we write (for anybody in the know, it's the JBA file INP15). It seemed like an ideal candidate for a subprocedure that would return the description to any report or enquiry program that used the subprocedure in an Eval statement. Unfortunately, removing the file from any of these programs now causes certain instances of the Like keyword to fail becase the field referenced is no longer available for the Like to get its details from. I could hard code the lengths of those fields, but that removes all of the advantages gained by using Like. How has anybody else coded themselves out of a situation like this? A second point is that in the subprocedure I have to open and close the file manually which is reasonably easy to do, but what effect does this have on performance as the file is continually opened and closed?

[K.Forsythe]

You are correct. That DS being copied into every module causes memory allocation in every module unless you use BASED to prevent that. Kevin

[B.Morris]

Absolutely_Nobody wrote: > > What is the recommended method of passing these data structures back to the called program ? As the return value like the code below ? Or, by using BASED and using a pointer ? > > Code <'http://www.mcpressonline.com/mc/showcode@@.6afc7ec0/6'> Neither. Pass the data structure by reference, and define the parameter using LIKEDS instead of LIKE. Then you can refer to the parameter subfields directly. For sure you should not use %STR with data structure pointers. If the data structure contains packed or integer data or varying length fields, %STR will usually give incorrect results. d myfileDS e ds extname(myfile) d based(dummy) d GetMyData PI d dsParm likeds(myfileDS) c to use the subfields, use dsParm.subfieldname