× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.