Re: Unix System Services migration
Carmen/ Shmuel, Thank you. I will review these reference manuals. Thank you, Brian Chapman On Thu, Sep 29, 2022 at 9:19 AM Carmen Vitullo wrote: > that's a better reference - I have a PDF saved on my work PC somewhere, > but this looks about the same > > Carmen > > On 9/29/2022 8:05 AM, Seymour J Metz wrote: > > See "Chapter 7. Sharing file systems in a sysplex" in z/OS 2.5 UNIX > System Services Planning, GA32-0884-50. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on > behalf of Brian Chapman [bchapma...@gmail.com] > > Sent: Thursday, September 29, 2022 8:54 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Unix System Services migration > > > > How are most shops handling USS management and migration? > > > > For many years, there has been a strong sentiment in my shop against > > utilizing USS (security and scalability were always cited as the primary > > reasons) and we were only allowed to utilize USS with IBM and ISV > software > > installs. Things are changing and now there is a strong push to change > our > > culture around USS. However, we are greatly behind with the times and > > inexperienced with best management practices regarding USS migrations. > > > > I'm sure our shop isn't the only site with a similar configuration, but > we > > have multiple systems for development lifecycles (alpha testing on SYSA > and > > SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate > > dataset mounts for each system, this makes sharing common resources > across > > the same lifecycle environment impossible; unless it is read-only (but > how > > do you update the file system without an outage?). Is there some sort of > > management practice that we're missing to achieve the ability to leverage > > common resources in USS? > > > > Also, how do you handle migration? Our shop uses CA Endevor. Do you > employ > > your change management software with USS migrations? If so, how do you > copy > > directories/folders without outages? For directories/files that can > easily > > be built with jobs, do you re-run these jobs on each system, or copy > these > > elements? > > > > > > > > > > Thank you, > > > > Brian Chapman > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL: Unix System Services migration [Internal]
I can't speak to the application development approach much, but I can speak to the infrastructure since we have been using USS for many components for many years. It lends itself to a sysplex quite well in terms of integrity and sharing provided you have the filesystems set-up appropriately. Please see IBM USS planning guides for details. Darrold Classification: Internal Disclaimer: This email and any attachments are the property of USAA and may contain confidential and/or privileged material. If you are not the intended recipient, any use, disclosure or copying of this email or any attachments is unauthorized. If you received this email in error, please immediately notify the sender and delete the email and any attachments from your computer. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Chapman Sent: Thursday, September 29, 2022 7:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL: Unix System Services migration How are most shops handling USS management and migration? For many years, there has been a strong sentiment in my shop against utilizing USS (security and scalability were always cited as the primary reasons) and we were only allowed to utilize USS with IBM and ISV software installs. Things are changing and now there is a strong push to change our culture around USS. However, we are greatly behind with the times and inexperienced with best management practices regarding USS migrations. I'm sure our shop isn't the only site with a similar configuration, but we have multiple systems for development lifecycles (alpha testing on SYSA and SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate dataset mounts for each system, this makes sharing common resources across the same lifecycle environment impossible; unless it is read-only (but how do you update the file system without an outage?). Is there some sort of management practice that we're missing to achieve the ability to leverage common resources in USS? Also, how do you handle migration? Our shop uses CA Endevor. Do you employ your change management software with USS migrations? If so, how do you copy directories/folders without outages? For directories/files that can easily be built with jobs, do you re-run these jobs on each system, or copy these elements? Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unix System Services migration
that's a better reference - I have a PDF saved on my work PC somewhere, but this looks about the same Carmen On 9/29/2022 8:05 AM, Seymour J Metz wrote: See "Chapter 7. Sharing file systems in a sysplex" in z/OS 2.5 UNIX System Services Planning, GA32-0884-50. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Brian Chapman [bchapma...@gmail.com] Sent: Thursday, September 29, 2022 8:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Unix System Services migration How are most shops handling USS management and migration? For many years, there has been a strong sentiment in my shop against utilizing USS (security and scalability were always cited as the primary reasons) and we were only allowed to utilize USS with IBM and ISV software installs. Things are changing and now there is a strong push to change our culture around USS. However, we are greatly behind with the times and inexperienced with best management practices regarding USS migrations. I'm sure our shop isn't the only site with a similar configuration, but we have multiple systems for development lifecycles (alpha testing on SYSA and SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate dataset mounts for each system, this makes sharing common resources across the same lifecycle environment impossible; unless it is read-only (but how do you update the file system without an outage?). Is there some sort of management practice that we're missing to achieve the ability to leverage common resources in USS? Also, how do you handle migration? Our shop uses CA Endevor. Do you employ your change management software with USS migrations? If so, how do you copy directories/folders without outages? For directories/files that can easily be built with jobs, do you re-run these jobs on each system, or copy these elements? Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unix System Services migration
For my site, I eventually setup a shared Unix filesystem, we wanted the ability to move workloads from system to system, or allow access to shared fileystems from any task, batch or ftp process. my Serverpac filesystems that came with my order are copied to a shared sysplex filesystem. it took me some time to get this setup and managed the way we needed but it works well. the IBM doc Unix system services planning is where I found all the sample processes I needed to setup the shared filesystem and the best practice for parmlib and system setup https://www.ibm.com/docs/en/zos/2.1.0?topic=sysplex-establishing-shared-file-system-in the process will setup a sysplex root, $version root and a $system root, fileystems that are specific to each system are mounted at /SYSA/local/ all version or ZOS filesystems are mounted off the sysplex root, and for us, filesystems that are not part of the OS $VERSION are mounted at /PLEX1/usr/local/ I'm sure others have some great options that work for them this enviorment works great for me Carmen On 9/29/2022 7:54 AM, Brian Chapman wrote: How are most shops handling USS management and migration? For many years, there has been a strong sentiment in my shop against utilizing USS (security and scalability were always cited as the primary reasons) and we were only allowed to utilize USS with IBM and ISV software installs. Things are changing and now there is a strong push to change our culture around USS. However, we are greatly behind with the times and inexperienced with best management practices regarding USS migrations. I'm sure our shop isn't the only site with a similar configuration, but we have multiple systems for development lifecycles (alpha testing on SYSA and SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate dataset mounts for each system, this makes sharing common resources across the same lifecycle environment impossible; unless it is read-only (but how do you update the file system without an outage?). Is there some sort of management practice that we're missing to achieve the ability to leverage common resources in USS? Also, how do you handle migration? Our shop uses CA Endevor. Do you employ your change management software with USS migrations? If so, how do you copy directories/folders without outages? For directories/files that can easily be built with jobs, do you re-run these jobs on each system, or copy these elements? Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Unix System Services migration
See "Chapter 7. Sharing file systems in a sysplex" in z/OS 2.5 UNIX System Services Planning, GA32-0884-50. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Brian Chapman [bchapma...@gmail.com] Sent: Thursday, September 29, 2022 8:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Unix System Services migration How are most shops handling USS management and migration? For many years, there has been a strong sentiment in my shop against utilizing USS (security and scalability were always cited as the primary reasons) and we were only allowed to utilize USS with IBM and ISV software installs. Things are changing and now there is a strong push to change our culture around USS. However, we are greatly behind with the times and inexperienced with best management practices regarding USS migrations. I'm sure our shop isn't the only site with a similar configuration, but we have multiple systems for development lifecycles (alpha testing on SYSA and SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate dataset mounts for each system, this makes sharing common resources across the same lifecycle environment impossible; unless it is read-only (but how do you update the file system without an outage?). Is there some sort of management practice that we're missing to achieve the ability to leverage common resources in USS? Also, how do you handle migration? Our shop uses CA Endevor. Do you employ your change management software with USS migrations? If so, how do you copy directories/folders without outages? For directories/files that can easily be built with jobs, do you re-run these jobs on each system, or copy these elements? Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Unix System Services migration
How are most shops handling USS management and migration? For many years, there has been a strong sentiment in my shop against utilizing USS (security and scalability were always cited as the primary reasons) and we were only allowed to utilize USS with IBM and ISV software installs. Things are changing and now there is a strong push to change our culture around USS. However, we are greatly behind with the times and inexperienced with best management practices regarding USS migrations. I'm sure our shop isn't the only site with a similar configuration, but we have multiple systems for development lifecycles (alpha testing on SYSA and SYSB, beta testing on SYSC and SYSD, etc). Since USS requires separate dataset mounts for each system, this makes sharing common resources across the same lifecycle environment impossible; unless it is read-only (but how do you update the file system without an outage?). Is there some sort of management practice that we're missing to achieve the ability to leverage common resources in USS? Also, how do you handle migration? Our shop uses CA Endevor. Do you employ your change management software with USS migrations? If so, how do you copy directories/folders without outages? For directories/files that can easily be built with jobs, do you re-run these jobs on each system, or copy these elements? Thank you, Brian Chapman -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
