**URGENT**Global variable & Service Programs

[deep]

Hello

Need an urgent Help..!!!!

Consider Program A which is bound to two service programs, say B & C. There is a global variable Z which is exported(defined as EXPORT) from service program B & C and imported(Defined as IMPORT) in program A. The global variable Z is defined in export symbol in both service program's binder language.

The problem is if I change the value of this global variable Z in Program A, the value is available/reflected in service program B, however the same is not avilable/reflected in service program C.


I tried defining the global variable Z as IMPORT in service program C. Still it does not work.

HOW can I make the value of this global variable available in both service programs(the value of Z is changed in program A only) ?? Urgent help PLssssssssssssss.

Regards, Deep

[JonBoy]

Personally I would change it to use a User Space and have all routines map to it.

Export/Import is an ugly capability that many of us involved in the development of ILE wish had never been "born"!

Beyond that - off the top of my head - I can't think of an easy solution and having lost the whole day due to a waterlogged computer I'm afraid I haven't time to "play".

[Barbara Morris]

I think it will work if you export it from srvpgm B and import it from srvpgm C. But you also need to create srvpgm B with BNDSRVPGM(srvpgm C).

[Rocky]

I tend to agree with Jonboy - global variables are just not a good idea. I'd create a routine to pass the information back and forth or put it into LDA or USRSPC.

[Barbara Morris]

I think LDA is even worse than global variables. LDA is global for the whole job. It makes my brain hurt to imagine keeping track of everything that's using the LDA, and making sure that only one set of programs is using any given section of the LDA.

A *DTAARA object would be better, since it would be easier to control what's using it. A USRSPC would be ok for the same reason.

But passing parameters seems the most straightforward to me.

[Whitecat27]

I think LDA is even worse than global variables. LDA is global for the whole job. It makes my brain hurt to imagine keeping track of everything that's using the LDA, and making sure that only one set of programs is using any given section of the LDA.

A *DTAARA object would be better, since it would be easier to control what's using it. A USRSPC would be ok for the same reason.

But passing parameters seems the most straightforward to me.

I totally agree with Barbara's concepts here for my interpretation of Deep's original post. Adding a parameter can be much easier to deal within Pgm B and Pgm C than using the LDA or IMPORT/EXPORT processing.. Then again, if Pgm B or Pgm C service programs are used by other programs... then adding the new field to those two service programs could cause conflicts within anything else that uses Pgm B or Pgm C.


Best Regards and Good Luck!
Fred Williams

[Rocky]

I totally agree with Barbara's concepts here for my interpretation of Deep's original post. Adding a parameter can be much easier to deal within Pgm B and Pgm C than using the LDA or IMPORT/EXPORT processing.. Then again, if Pgm B or Pgm C service programs are used by other programs... then adding the new field to those two service programs could cause conflicts within anything else that uses Pgm B or Pgm C.


Best Regards and Good Luck!
Fred Williams

Which is why the more object oriented approach could be beneficial - give access to the data via a routine. Put the data in one or the other module - use a procedure to update it and to retrieve it. Since this is done "behind the scenes" if you will, it doesn't change ANY existing interface to applications unless they need access to that value - at which point they'd have to use the same calls to update/retrieve the value.

One should avoid using global variables between service programs at all costs at all times. It defeats the purpose. It also reduces the modularity of the routines - the service programs should always always always always be self contained.

[Barbara Morris]

I like that idea of using procedures to access the data, Rocky. I have used that mechanism myself in the past, but I forgot about it during this discussion. (Tunnel vision. I got caught up in thinking about the mechanics of doing the import/export.)

Sometimes, where there wasn't an obvious "owner" for the shared data, I have even put the shared data and get/set procedures into a separate module, and even occasionally a separate service program.

The great thing about having procedures to access the data is that even if the data is actually in stored a data area, or a file, or even (shudder) the LDA, nobody needs to know about that except the one module that controls the data and has the get/set procedures.

[Rocky]

The great thing about having procedures to access thDiscarde data is that even if the data is actually in stored a data area, or a file, or even (shudder) the LDA, nobody needs to know about that except the one module that controls the data and has the get/set procedures.

What's wrong with the LDA? You state that the problem with the LDA earlier that it's "worse" than global variables because it's available throughout the job - but you then promote *DTAARA or USRSPC as an alternative - which is not only available for the entire job but for the entire system regardless of job.... and can be run over by other jobs - so you have to put them in QTEMP to simulate what the LDA already does - and you're really accomplished nothing except add extra logic to allow more than one job to run.

The service programs should have, functionally, constructors and destructor procedures - the program runs the constructor that sets up the initial values to be used - hence initializing the LDA. Then who cares about the LDA is available outside of that program in that job? If you do - you run the destructor routine before exiting that clears it out... The LDA keeps the data local to the job with no locking conflicts with other jobs. It keeps the temporary.... temporary.

I don't use LDA's much as I tend to prefer passing the data via parameters or through get/set routines but the LDA has it's benefits.

[Barbara Morris]

The trouble I see with the LDA is that any program can use any part of the LDA. It's true that any program could use a named data area or a file, but it seems easier to control what programs are using a data area or a file than trying to control what programs are using which bits of the LDA.

[Rocky]

The trouble I see with the LDA is that any program can use any part of the LDA. It's true that any program could use a named data area or a file, but it seems easier to control what programs are using a data area or a file than trying to control what programs are using which bits of the LDA.

I do't see how a data area is any different than the LDA in this respect except maybe even make it worse. The LDA is only good for the job, the data area is persistent - any program ran by any user can cause problems - the LDA is restricted to a specific job. When the user runs a job, the first thing you do is clear the LDA so you know the state of the LDA. No other job can effect it or corrupt it. Can't be said for other data areas.

To me the LDA can be handy for communication between programs. FOr example, a CL calls PGMA, PGMB and sometimes PGMC - might even be in a loop. The LDA keeps data passed from PGMA <=> PGMB <=> PGMC. Do they all need to know how the data sits in the LDA? Yes - but that's true of any data area. You could create a file/table with the layout and use that as a template for the LDA in the programs to ensure that it's always consistent. If you have to change a field (make it larger) or add one the LDA will automatically adjust when you recompile the programs. Since the first thing you do is clear the LDA there isn't any outside corruption. You could use a file/table to accomplish this but to me that just adds complexity when it's not necessarily needed or helpful.

Or you could simply pass the data via paramaters.... but that can be problematic if PGMC is called within multiple CL programs - then you have to make sure that it's called with the correct parameters in all of those CL programs....

[Barbara Morris]

If you wanted to use a named data area, presumably PGMA, PGMB and PGMC would have their own data area. If there was another group of programs PGMD, PGME, and PGMF that needed to share data, they would have a different named data area. The data areas could be in QTEMP, or you could use locking to ensure that only one job could access them.

I'm thinking of a type of interactive job where a user might use application A, and leave it in an active state, and then they might use application B, and then come back to use application A again. If application A is using the LDA, and at some point application B starts using the LDA too for some reason, then there could be strange bugs in A that only show up when a user uses application B while they still have application A active.

For batch jobs, where everything is self-contained, using the LDA wouldn't have that issue.

But I'm not at all advocating using named data areas to share data. I think shared data should be shared either by passing parameters, or by using get/set procedures.

[Rocky]

But I'm not at all advocating using named data areas to share data. I think shared data should be shared either by passing parameters, or by using get/set procedures.

Herein I'm in total agreement.... these are the most favorable approaches.

[EmmanuelW1]

Rocky wrote:

"The LDA is only good for the job..."

I don't think that's true - an interactive job can populate the LDA, then submit a batch job which will have access to the same LDA.

Cheers,

Emmanuel

[Rocky]

Rocky wrote:

"The LDA is only good for the job..."

I don't think that's true - an interactive job can populate the LDA, then submit a batch job which will have access to the same LDA.

Cheers,

Emmanuel

It might pass on a copy of the LDA (it's been awhile) - but it's a separate LDA - the batch job updates the LDA the interactive job won't see it