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

Hi All,

We have just recently started using service programs and procedures for a
lot of our new development. While a couple of us have some experience, in
many ways we are still winging it.

In a meeting with one of the other programmers, a few interesting
questions came up. Mostly along the lines of 'why does this even
work?'... 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.

Here are a few of the things we are doing -- If any of them are major
no-nos I would appreciate a heads up:
1 - Because we cannot use F-specs in a procedure (yet) we use SQL for all
data access. One of our programmers mentioned that we were the first shop
he has seen using SQL in service program procedures.
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.
3 - We are grouping related procedures in single members - for example,
there are about 10 or so EDI related procedures in a single source for the
EDI Service Program.
4 - We have a Test and Live environment, with unique library lists. In
normal RPG we would test the LDA to determine the environment, but in
procedures we cannot. We have experimented with adding the LDA to the
'global' D-specs and it seems to work...

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?

Sorry for the long post, but sometimes I get scared when things work and I
am not sure I understand why. When I first started coding I was advised
that if your program compiles without error on the first try then scrap
the code and start over...

Let me know your thoughts,
Thanks!
JD