RE: Stored procedures and library independence

Hi Evan

IBM's .net and jdbc data providers both have options on either the
connection string or the connection object for setting the connections
library list.

However this library list will only be searched if you specify *SYS naming
convention. The major difference is that a '/' is required to separated
schema and object names instead of a '.' however if your using library list
to resolve objects you don't need the separator anyway !!

Others will be able to give you more info on the exact impact of *SYS.

As for returning the library list. We have a file in USRQSYS that stores env
codes and the corresponding librarys that are in that environments library
list.

You could write a proc that given an environment name i.e. Devlopemnt1,
Test5 , Integration9 (what ever) returns the libraries in order that should
be used when accessing that environment.

Those libraries are returned to the caller. The caller then specifies those
libraries in a connection on all subsequent calls to any other stored proc.

Neill

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Evan Harris
Sent: 25 May 2009 12:59
To: 'Midrange Systems Technical Discussion'
Subject: RE: Stored procedures and library independence

Hi Neil

Thanks for the response.

What's the impact/effect of using the *SYS naming convention - do they need
to be more iSeries literate ? i.e. will the SQL be less "portable" or
standard ?

Also, "when you say returns the library list to the caller" - can you
provide a bit more detail on how this would work ?

Regards
Evan Harris


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Neill Harper
Sent: Monday, 25 May 2009 11:32 p.m.
To: 'Midrange Systems Technical Discussion'
Subject: RE: Stored procedures and library independence

Hi Evan

One very important factor in all of this, is are you clients prepared to use
*SYS naming convention, because if they are with a little bit of work you
can get them resolving their stored procs using a library list.

You have one stored proc that is all ways in the same place called
"GetLibraryList" which accepts whatever info you need to decide what
environment a client should execute in (i.e. an environment code DEV, USR
etc)

That proc returns the library list to the caller.

On all subsequent calls the user sets the library list property on their
connection as well as *SYS naming convention and then it should be plain
sailing from there!!!!

Or you could take the approach that the client already knows its library
list, i.e. stored in config files etc, and connect straight away with that
library list.

Neill

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Evan Harris
Sent: 25 May 2009 12:07
To: 'Midrange Systems Technical Discussion'
Subject: Stored procedures and library independence

Hi All

I had a question today about what the best approach was for designing and
building stored procedures in different scenarios. For example, in a Test
and Dev environment (multiple different versions), or a production
environment that uses different data libraries for company or division data
but a common code base (one version, different data libraries.

Would it be better to create a Stored procedure for each environment ?

Should/can the Stored procedure be designed so it resolves the library based
library list ?

Should the library be passed in as a parameter ?

Should I even use a stored procedure in this scenario ?

What kind of versioning strategy if any could I used with stored procedures
?

This is a somewhat hypothetical question for me but I'm interested in any
and all viewpoints about how best to manage stored procedures so any
feedback is welcome.

If you want me to phrase my question better or elaborate on something go
right ahead and ask,

Regards
Evan Harris