|
From "Yvan Janssens" <friedkiwi@xxxxxxxx>To "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxxxxxxxx>
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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx <mailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx>
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l <https://lists.midrange.com/mailman/listinfo/midrange-l>
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx <mailto:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx>
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l <https://archive.midrange.com/midrange-l>.
Please contact support@xxxxxxxxxxxxxxxxxxxx <mailto:support@xxxxxxxxxxxxxxxxxxxx> for any subscription related questions.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
