Referencing arrays in a programs data area with pointers

[Guest.Visitor]

Don't bother with pointers when passing the arrays as normal reference parameters will work just fine.

[petzold@benteler.com]

Thanks for the answer. I had begun to do this out of desperation. But, here's the thing, I have many arrays. I would rather not pass them all. I keep having to go back and modify my main program to pass more and more arrays as the specialized needs of my exit programs require. Here's my remaining questions if you'd like to take a whack at one or all of them: 1. Is there a limit to what you can pass? I have a generic routine so I must pass all the parameters that ANY of the custom exit routines I've written will use. 2. Under what circumstances is it desirable to maintain a single copy of data in a "repository" or "main" program and use pointers or some other method to reference that data?

[Guest.Visitor]

The limit on the number of parameters is a couple of hundred. It's documented in the manual. OK, before you ask, the manual says 255 on a program call, 399 on a procedure call. What are the choices here? Well, you could continually add parameters, but that of course becomes a maintenance headache. Or, you could define your arrays in a data structure, and pass the data structure. (Provided of course that the DS is smaller than 64K.) Or, you could define procedures in your main module for accessing the array data. Another alternative is to use keywords IMPORT and EXPORT, if you're using bound modules. I hesitate to mention those, since they allow to you code a "hidden interface" between your modules. But if you're just using the arrays to define configuration information that's set once on initialization of the application and only referenced in other modules, that is generally considered an acceptable use of IMPORT/EXPORT. Since you're using programs, I'd investigate passing the arrays in a data structure.

[petzold@benteler.com]

I did fairly well with using parameters until I hit a barrier that made me wish I could just access the data in the main program: I dynamicly call routines that export the data from the bar code application into our main ERP application. This, I think, prevents the use of importing and exporting the data from modules since I must use dynamic calls. Also, a CL program is part of the jobs stream. Facing deadlines, I despaired of passing arrays through the CL program. I did consider holding the data in a string variable. I'm pretty sure there is a way of passing the address of the data without passing the data. My immediate fix (in light of my deadlines) was to simply re-read the data. But I'd like to experiment with passing the data through the cl via a character variable. I think this is what you were recommending by saying to put the arrays in a data structure. Would that be your approach?? I'm still thinking that I should be able to reference the data in the main program via a "basing pointer". That term just got coughed up out of the dark recesses of my grey matter.

[petzold@benteler.com]

I got some code that showed me how to initialize and pass pointers. Then all you must do is put "based(pointername)" by the variable in the subprogram. But I get the error message: Variable not available for display when I try "eval" in the debugger. The brainstorm just hit me that the data might be okay but the debugger can't touch it. Could that be it???

[petzold@benteler.com]

I'd like to read configuration data into arrays in the main engine of a bar code application. I'm currently calling programs from the main program with a dynamic call. I think the best way to pass the data from my main program to called programs is by passing a pointer to the arrays. Is this correct? It may be valuable to note that the called programs are done with a single call command in the main program. The program being called is a variable. These are exit routines to validate data. Though this presents several interesting technical questions, the main thing I'd like to focus on is how to reference an array in one program by passing a pointer to another program - if this is the recommended technique to share data.

[petzold@benteler.com]

Passing pointers works marvelously. I was just stupid enough to not realize that the debugger will only display the variables in the program in which they reside. So when I'm at a breakpoint in the subprogram, I can't hit F11 on the variable name. But I can go back to the main program and display the data. This is fandiddlytastic!! Activation groups are the coolest, too. My next adventure will be to have files open across the application using activation groups.

[B.Morris]

petzoldk, that could indeed be it. The debugger can only display based variables in a few circumstances. If you can EVAL the pointer itself, you can EVAL what it's pointing to by using :x or :c ===> EVAL ptr:x 10 This shows the first 10 bytes that "ptr" is pointing to, in hex. ===> EVAL ptr:c 10 This shows the first 10 bytes that "ptr" is pointing to, as character data. You could also change your code to copy the parameter into a local pointer and base your variable on that local pointer instead. Change this: D basedVar s 100a based(parmPtr) C *entry plist C parm parmPtr To this: | D localPtr s * | D basedVar s 100a based(localPtr) C *entry plist C parm parmPtr | C eval localPtr = parmPtr (The problem the debugger is having is that a *ENTRY PLIST parameter is actually "based" itself, since only the address of the parameter is passed. The debugger can't EVAL a variable that is based on a pointer that is also based.)

[B.Morris]

petzoldk wrote: > ... > I was just stupid enough to not realize that the debugger will only display the variables in the program in which they reside. > ... petzoldk, you weren't stupid at all. Your assumption about being able to debug parameters was right in general. It's just a specific problem related to pointer parameters.