Re: Encapsulation - Service Programs, Procedures, SQL, LDA, etc.

[Adam Glauser <adamglauser@xxxxxxxxxxxx>]

nike@xxxxxxxxxxxxxx wrote:
> We have adopted some practices that are working but we are not
> 100% confident that there is not something ugly waiting to bite us down
> the road.

> 2 - Because SQL host variable names must be unique in a source member, our
> service programs use a list of 'global' D-specs for things like Customer
> Number (sqlCusn).  Any procedure in the service program that uses Customer
> number as an SQL parm now uses sqlCusn.

I think that this is a bad idea on a couple of levels.  For one, host 
variables (SQL parameters) should not start with 'sql', according to the 
SQL embedded programming documentation.

Another reason I think this is potentially problematic is that by using 
global variables you run the risk of side effects.  Suppose procA and 
procB both change the value of sqlCusn.  Somewhere down the road, procA 
starts calling procB.  Now you can have a problem:
procA sets Cusn = '1'
procA calls procB
procB sets Cusn = '2'
procB returns
procA does an UPDATE statement using :sqlCusn, but sqlCusn is no longer 
the expected value.


> Encapsulation is our main concern.  Are we at risk of two jobs that use
> the same Service Program corrupting each other -- SQLCOD or sqlCusn
> overlaps, crossed LDA values, etc?

No.  Each job has its own copy of the SRVPGM running*, just as the same 
program running in two different jobs won't mess with each other's 
variables.

*: this is probably an oversimplification.  Many operating systems allow 
jobs (or processes) to share the static parts of programs code, so that 
if you run PGMA in 100 jobs, you don't use 100 * (size of pgmA) memory. 
 However, the variables in each job are safe from one another.