I'm trying to understand what the difference (in actual effect) is between
the use of job descriptions to define library list environments and the
mentioned lib within a lib? I don't want to assign a label to what a library
"is", but in effect it is a place to put stuff, and the library list (from
the jobd) let's me define the order a job will use to process.
jobd = dev
user library list = qtemp, qgpl , file_dev, pgm_dev, pgm_prod
or qtemp, qgpl, file_dev, file_test, pgm_dev,
pgm_prod
jobd = qa
user library list = qtemp, qgpl , file_qa, pgm_qa, pgm_prod
or qtemp, qgpl, file_qa, file_test, pgm_qa, pgm_prod
jobd = prod
user library list = qtemp, qgpl , file_prod, pgm_prod
Now if you have hardcoded library names in programs - thats like hardcoding
the rdbms parm, or not using environment variables, and that would be bad.
Jim Franz
----- Original Message -----
From: "Nathan Andelin" <nandelin@xxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, September 04, 2013 7:49 PM
Subject: Re: separate DEV, TEST, & PROD environments survey
From: Charles Wilt
For that matter, every single RDBMS I'm familiar with only allows a single
level
of schemas.
I gather that you mean the "catalog" or "database" parameter referenced on
RDBMS "connection" strings. At any rate, I like the analogy. They don't
offer an option to define or connect to a database within a database within
a database. Likewise, IBM i doesn't offer an option to define or connect to
a library within a library within a library (with the exception of QSYS).
Referencing files and other objects within IBM i libraries is essentially
similar to referencing RDBMS objects within a "catalog" or "database".
-Nathan
midrange.com
