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

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.