On Wed, 27 Oct 2010 10:48:31 +0200, R.S. <[email protected]> wrote:
I don't have a problem with any of your reasons on why a development or sandbox LPAR might be preferred, but I had a problem with the use of the word "never" (or should never) since SeverPac is designed to be run from a driving system without changing that system in any way that would be harmful. I will also address some things below: >Mark Zelden pisze: >> On Tue, 26 Oct 2010 22:08:22 +0200, R.S. <[email protected]> wrote: >> >>> 2. Since serverpac installation is (should) never been done on >>> productions system as a driver then auditors requirements are plain STUPID. >> >> Why not? Your driving system isn't affected. Performance may be much >> better also. Other reasons could include having enough dasd for SMPNTS, >> ICSF or other software you want / need on the driving system. > >1. Wide authorities needed for the installation. I.e. person who >performs the installation need to create many RACF definitions which >implies SPECIAL. It is usually against security policy. No more authorities are needed for installation of serverpac on any production systems that I work with for any client than the system programmers who do serverpac installations already have. Also, z/OS is not the only serverpac that exists. You can get ServerPac for CICS, DB2, etc. also. Those sysprogs always install their new versions of software on the production sysplexes (while the "MVS" sysprogs do occasionally install software from a testplex). Since I like to get my job done quicker, when I can, I still prefer to run installation jobs on an LPAR with capacity instead of a 1 engine 20 MIP capped sandbox LPAR. :-) >2. Operations on ICF catalogs. Stupid human error could affect driving >system. Not a big problem for sandbox/technology/test LPAR, big issue >for production. If someone can't define an alias to a new catalog (SSA) on the production system without screwing it up, they shouldn't be attempting something as involved as upgrading an OS. The newbies should get their feet wet doing other tasks. Hundreds operations on ICF catalogs in production are done every week (mostly new aliases for users, removing users). These are all standard operational activities and of course human error could affect it. Human error could also lead to deletion of SYS1.LINKLIB, but we don't worry about that. >3. Similar problems with HFS filesystems - a mistake could result in >change content of production filesystems. >4 Whole process is against rule of thumb: production system is for >production, not for development, app. tests, system tests, etc. > Same general comments as above as far as whom you let install maintenance or install operating systems. But since root file systems are mounted read only, that also protects from mistakes. >So, UNLESS the installation is really performed on production (which I >still strongly doobt), I sustain my opinion. Otherwise I would have very >critical opinion about installation process. > On several sysplexes I support, there is no "development" environment. There are critical and less critical LPARs including "mostly TSO" LPARs (but even those have production CICS/DB2/MQ), but production / development subsystems exist on all those LPARs together. I'm not saying it's ideal, but it is what it is (I also support environments that do have strictly production workload in a production plex and development in a development plex). Again, my problem was with the word "never" and blanket statements. Not every shop has a robust sandbox / development environment they use for installation of software. Testing, is another issue. Of course you test your installation in a sandbox / development environment first if you can. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:[email protected] Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
