Indeed - LPARs are the way to go. This is also very automatable; using ansible and templates you can automatically build your production images with just the right amount of application that you need, similar how you would do this on Windows/Linux.
It's tough to secure a development LPAR, because you just have to have access to privileged tools to be productive. You solve this problem by making the development LPAR low-privileged in your threat model and make it disposable. Source code and related assets should probably exist in an external version control system anyway so you can easily back this up and track changes.
In today's day, DASD space and RAM is cheap enough to not consider solving your problem by throwing RAM and DASD at it; your engineering time to work around this will cost you more.
/y
On 17/09/2024, 18:32, "MIDRANGE-L on behalf of Mark Waterbury" <midrange-l-bounces@xxxxxxxxxxxxxxxxxx <mailto:midrange-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of mark.s.waterbury@xxxxxxxxxxxxx <mailto:mark.s.waterbury@xxxxxxxxxxxxx>> wrote:
If we must fully-qualify all program CALLs by "hard-coding" the library name, how can we "test" changes to those applications?
There are several possible approaches.
#1. create a separate LPAR for development and testing, and then only promote changes to the "live" production LPAR after various Q/A testing and approval processes have been performed.
This way, developers and testers sign-on to the "DEVTEST" LPAR, and use those libraries and versions of the applications programs and data, while "live" production users sign-on to the "LIVE" production LPAR to use the applications.
#2. if your shop does not have a separate LPAR for development and testing vs. production, use "Independent ASPs" (iASPs) or disk pools (available since V5R2). With this approach, you can have the primary "live" production libraries in a "master" iASP, and have an alternate set of libraries with the exact same library names ,but in a "testing" iASP.
That way, library names can be "hard-coded" for each application, and yet, when testing, your developers and testers would issue SETASPGRP to switch to using that iASP (and those libraries), or have their *JOBD specify the correct INLASPGRP, while all of the "live" production users all run with their user profiles and job descriptions INLASPGRP set for the "master" or "live" iASP (disk pool).
These approaches will require additional DASD space to contain all of the LPARs or disk pools, with duplicate sets of all objects, files, etc. for each application.
NOTE: iASPs also will likely require some change to your applications, as their use is not 100% transparent or upward compatible with all possible existing legacy applications. In particular, if you use vendor applications software packages, and make "local" customizations or modifications, you may need to discuss the use of iASPs with each of the software vendor(s) to determine if those applications are compatible with iASP use; ask for any special recommendations or considerations for setting up and running those applications in an iASP environment.
See the following IBM Redbooks for a good overview of the requirements for setting up and using Independent ASPs:
https://www.redbooks.ibm.com/redbooks/pdfs/sg247811.pdf <
https://www.redbooks.ibm.com/redbooks/pdfs/sg247811.pdf>
https://www.redbooks.ibm.com/redbooks/pdfs/sg246802.pdf <
https://www.redbooks.ibm.com/redbooks/pdfs/sg246802.pdf>
Hope that helps.
All the best,
Mark S. Waterbury
midrange.com
