info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Serverpac installs January 2022 and beyond - Requests
308 views
Skip to first unread message
Shaffer, Terri
Jul 19, 2021, 7:08:48 AM7/19/21
to
So, I am going to ease up on IBM a little, except for the resources needed for z/OSMF, But have a few usability requests just as in the serverpac.
I am not 100% convinced yet, but I see no way of editing a job that was generated, BEFORE submit!!
I also see fields on the screen but no context help as to know what they want to fill in, like * Work data set name prefix: what was the equivalent ??
This is critical, in many shops I have every installed SEVERPAC in, due to catalogs naming's mostly and where datasets live.
In serverpac, you could SAVE JCL and recall using BACKUP to re-run something you had to modify for whatever reason. That ability seems gone??
I will test using z/OSMF based on what I saw in the DEMO, but when dealing with 1200+ z/OS datasets across, probably 5 or 6 volumes, in my experience always needed tweaked!
Again, maybe for the sysprog, who doesn’t understand, this make perfect sense, but there are many times, the canned/generated JCL will not work in an environment and the dialogs don’t allow it to be fixed.
Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
Terri....@aciworldwide.com
________________________________
[https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] <http://www.aciworldwide.com>
This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
I am not 100% convinced yet, but I see no way of editing a job that was generated, BEFORE submit!!
I also see fields on the screen but no context help as to know what they want to fill in, like * Work data set name prefix: what was the equivalent ??
This is critical, in many shops I have every installed SEVERPAC in, due to catalogs naming's mostly and where datasets live.
In serverpac, you could SAVE JCL and recall using BACKUP to re-run something you had to modify for whatever reason. That ability seems gone??
I will test using z/OSMF based on what I saw in the DEMO, but when dealing with 1200+ z/OS datasets across, probably 5 or 6 volumes, in my experience always needed tweaked!
Again, maybe for the sysprog, who doesn’t understand, this make perfect sense, but there are many times, the canned/generated JCL will not work in an environment and the dialogs don’t allow it to be fixed.
Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
Terri....@aciworldwide.com
________________________________
[https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] <http://www.aciworldwide.com>
This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Barbara Nitz
Jul 20, 2021, 3:18:20 AM7/20/21
to
>You can't change the size of a dataset and you can't change PDS to PDSE. It's easy in ServerPac to mass change to PDSE. It skips ones that aren't eligible.
You can't? As far as I am concerned that is a definite roadblock. IBM never sizes the data sets in such a way that they won't go x37 at the first apply. I routinely at least double allocations for things like linklib and miglib and essentially all linklist datasets because they don't have extents and are more prone to x37.
It's a good thing we have always planned to order 2.5 as soon as it becomes available, so I get to use serverpac for my last ever z/OS install. The one in four years will have to be done by my successor because I'll be almost retired by then.
Never mind that we haven't set up z/OSMF, either. Once we migrate to the z15, we can take advantage of system 'recovery' boost so z/OSMF can come up on the teeny tiny sysprog lpars.
Regards, Barbara
You can't? As far as I am concerned that is a definite roadblock. IBM never sizes the data sets in such a way that they won't go x37 at the first apply. I routinely at least double allocations for things like linklib and miglib and essentially all linklist datasets because they don't have extents and are more prone to x37.
It's a good thing we have always planned to order 2.5 as soon as it becomes available, so I get to use serverpac for my last ever z/OS install. The one in four years will have to be done by my successor because I'll be almost retired by then.
Never mind that we haven't set up z/OSMF, either. Once we migrate to the z15, we can take advantage of system 'recovery' boost so z/OSMF can come up on the teeny tiny sysprog lpars.
Regards, Barbara
Brian Westerman
Jul 20, 2021, 4:35:52 AM7/20/21
to
You are 100% correct, there are about 50 datasets that I ALWAYS enlarge during the installation for just the reason you specified, IBM sizes them for delivery, not for applying maintenance later. Then there are the ones that ALWAYS need to be updated like HASPSPACE and the checkpoints, as well as the SMF datasets, the SMS datasets, parmlib, and most of the SMPE datasets. Going with IBM's default assignments would make later maintenance application certain to fail and you would need a lot of time to enlarge a lot of datasets that you could have handled during the initial installation in a few minutes.
My problem with the new installation method is that it "should" have been set up such that for all of 2.5 (and maybe 2.6) that you had the choice of Serverpac AND z/OSMF so that you could work out the issues. in this case, IBM is giving everyone a very small number of months to get things corrected, when it's likely that you won't even realize that something was messed up until you apply maintenance at some "later" time.
I am unaware of any time in the past that IBM was so aggressive with something as completely untried. You could use z/OSMF with DB/2 etc, but for sites that don't have those products there is no way to "try it out". This is the first shot at the whole operating system, and there is very little parallel time being provided. That's never a good idea with something as large and complex as a complete z/OS installation.
How can the company that makes sure that you can run code form 1960 in 2021 be some completely oblivious to providing any path "other" than complete installation method replacement?
Brian
My problem with the new installation method is that it "should" have been set up such that for all of 2.5 (and maybe 2.6) that you had the choice of Serverpac AND z/OSMF so that you could work out the issues. in this case, IBM is giving everyone a very small number of months to get things corrected, when it's likely that you won't even realize that something was messed up until you apply maintenance at some "later" time.
I am unaware of any time in the past that IBM was so aggressive with something as completely untried. You could use z/OSMF with DB/2 etc, but for sites that don't have those products there is no way to "try it out". This is the first shot at the whole operating system, and there is very little parallel time being provided. That's never a good idea with something as large and complex as a complete z/OS installation.
How can the company that makes sure that you can run code form 1960 in 2021 be some completely oblivious to providing any path "other" than complete installation method replacement?
Brian
Richards, Robert B. , CTR
Jul 20, 2021, 7:41:40 AM7/20/21
to
Marna,
Can you expand on what you mean below?
"If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really behooves you to define your prior z/OS release right now as a Software Instance."
I do not want to assume that I completely understand your suggestion.
Bob
Can you expand on what you mean below?
"If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really behooves you to define your prior z/OS release right now as a Software Instance."
I do not want to assume that I completely understand your suggestion.
Bob
Bill Johnson
Jul 20, 2021, 7:49:24 AM7/20/21
to
IBM shares rose as much as 4% in extended trading on Monday after the enterprise technology and services provider reported second-quarter earnings that came in stronger than analysts had expected.
Here’s how the company did:
- Earnings: $2.33 per share, adjusted, vs. $2.29 per share as expected by analysts, according to Refinitiv.
- Revenue: $18.75 billion, vs. $18.29 billion as expected by analysts, according to Refinitiv.
-
Revenue grew 3% year over year in the quarter, according to a statement, the fastest growth in three years, as the company laps a quarter that saw meaningful impact from the coronavirus. In the previous quarter revenue had grown 0.9%. The company reiterated its expectation that revenue will grow, rather than decline, in the full year.
The Cloud & Cognitive Software business, which includes Red Hat, contributed $6.10 billion in revenue, up 6% and more than the FactSet consensus of $5.93 billion.
So much for IBM is doomed.
Here’s how the company did:
- Earnings: $2.33 per share, adjusted, vs. $2.29 per share as expected by analysts, according to Refinitiv.
- Revenue: $18.75 billion, vs. $18.29 billion as expected by analysts, according to Refinitiv.
-
Revenue grew 3% year over year in the quarter, according to a statement, the fastest growth in three years, as the company laps a quarter that saw meaningful impact from the coronavirus. In the previous quarter revenue had grown 0.9%. The company reiterated its expectation that revenue will grow, rather than decline, in the full year.
The Cloud & Cognitive Software business, which includes Red Hat, contributed $6.10 billion in revenue, up 6% and more than the FactSet consensus of $5.93 billion.
So much for IBM is doomed.
kekronbekron
Jul 20, 2021, 9:24:24 AM7/20/21
to
Hi Bob,
I believe she means that when you import your prior/current zOS CSI and set some parms (if required) for it, then you can base your target environment (CSI, files, etc.) off of it.
This way, you don't start at zero, i.e., defining all datasets manually, anew.
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, July 20th, 2021 at 5:11 PM, Richards, Robert B. (CTR) <000001c91f408b9...@LISTSERV.UA.EDU> wrote:
> Marna,
>
> Can you expand on what you mean below?
>
> "If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really behooves you to define your prior z/OS release right now as a Software Instance."
>
> I do not want to assume that I completely understand your suggestion.
>
> Bob
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
I believe she means that when you import your prior/current zOS CSI and set some parms (if required) for it, then you can base your target environment (CSI, files, etc.) off of it.
This way, you don't start at zero, i.e., defining all datasets manually, anew.
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, July 20th, 2021 at 5:11 PM, Richards, Robert B. (CTR) <000001c91f408b9...@LISTSERV.UA.EDU> wrote:
> Marna,
>
> Can you expand on what you mean below?
>
> "If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really behooves you to define your prior z/OS release right now as a Software Instance."
>
> I do not want to assume that I completely understand your suggestion.
>
> Bob
>
Richards, Robert B. , CTR
Jul 20, 2021, 9:29:00 AM7/20/21
to
I thought that maybe a new order of 2.4 through Shopz except change the delivery mechanism.
Bob
Bob
kekronbekron
Jul 20, 2021, 9:34:58 AM7/20/21
to
Hmm.. is 2.4 is available as a zOSMF Software Instance via ShopZ?
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, July 20th, 2021 at 6:58 PM, Richards, Robert B. (CTR) <000001c91f408b9...@LISTSERV.UA.EDU> wrote:
> I thought that maybe a new order of 2.4 through Shopz except change the delivery mechanism.
>
> Bob
>
> -----Original Message-----
>
> From: IBM Mainframe Discussion List IBM-...@LISTSERV.UA.EDU On Behalf Of kekronbekron
>
> Sent: Tuesday, July 20, 2021 9:24 AM
>
> To: IBM-...@LISTSERV.UA.EDU
>
> Subject: Re: Serverpac installs January 2022 and beyond - Requests
>
> Hi Bob,
>
> I believe she means that when you import your prior/current zOS CSI and set some parms (if required) for it, then you can base your target environment (CSI, files, etc.) off of it.
>
> This way, you don't start at zero, i.e., defining all datasets manually, anew.
>
> - KB
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Tuesday, July 20th, 2021 at 5:11 PM, Richards, Robert B. (CTR) 000001c91f408b9...@LISTSERV.UA.EDU wrote:
>
> > Marna,
> >
> > Can you expand on what you mean below?
> >
> > "If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really behooves you to define your prior z/OS release right now as a Software Instance."
> >
> > I do not want to assume that I completely understand your suggestion.
> >
> > Bob
> >
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, July 20th, 2021 at 6:58 PM, Richards, Robert B. (CTR) <000001c91f408b9...@LISTSERV.UA.EDU> wrote:
> I thought that maybe a new order of 2.4 through Shopz except change the delivery mechanism.
>
> Bob
>
> -----Original Message-----
>
> From: IBM Mainframe Discussion List IBM-...@LISTSERV.UA.EDU On Behalf Of kekronbekron
>
> Sent: Tuesday, July 20, 2021 9:24 AM
>
> To: IBM-...@LISTSERV.UA.EDU
>
> Subject: Re: Serverpac installs January 2022 and beyond - Requests
>
> Hi Bob,
>
> I believe she means that when you import your prior/current zOS CSI and set some parms (if required) for it, then you can base your target environment (CSI, files, etc.) off of it.
>
> This way, you don't start at zero, i.e., defining all datasets manually, anew.
>
> - KB
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Tuesday, July 20th, 2021 at 5:11 PM, Richards, Robert B. (CTR) 000001c91f408b9...@LISTSERV.UA.EDU wrote:
>
> > Marna,
> >
> > Can you expand on what you mean below?
> >
> > "If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really behooves you to define your prior z/OS release right now as a Software Instance."
> >
> > I do not want to assume that I completely understand your suggestion.
> >
> > Bob
> >
> > --
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ---------------------------------------------------------------------------------------------------------------------------------------
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
Shaffer, Terri
Jul 20, 2021, 9:38:26 AM7/20/21
to
I would not think my SMPE CSI for my current z/OS 2.4 would have enough information to support a serverpac install. Many things have been changed that I would not count on matching what it was for the actual serverpac install. Mountpoints, dataset names, etc. Again if you looking for people to use this, at least with z/OS 2.5, you need to read my saved serverpac configuration file dataset.
Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
Terri....@aciworldwide.com
Hi Bob,
I believe she means that when you import your prior/current zOS CSI and set some parms (if required) for it, then you can base your target environment (CSI, files, etc.) off of it.
This way, you don't start at zero, i.e., defining all datasets manually, anew.
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, July 20th, 2021 at 5:11 PM, Richards, Robert B. (CTR) <000001c91f408b9...@LISTSERV.UA.EDU> wrote:
> Marna,
>
> Can you expand on what you mean below?
>
> "If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really behooves you to define your prior z/OS release right now as a Software Instance."
>
> I do not want to assume that I completely understand your suggestion.
>
> Bob
>
Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
Terri....@aciworldwide.com
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of kekronbekron
Sent: Tuesday, July 20, 2021 9:24 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests
External Email
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of kekronbekron
Sent: Tuesday, July 20, 2021 9:24 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests
Hi Bob,
I believe she means that when you import your prior/current zOS CSI and set some parms (if required) for it, then you can base your target environment (CSI, files, etc.) off of it.
This way, you don't start at zero, i.e., defining all datasets manually, anew.
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, July 20th, 2021 at 5:11 PM, Richards, Robert B. (CTR) <000001c91f408b9...@LISTSERV.UA.EDU> wrote:
> Marna,
>
> Can you expand on what you mean below?
>
> "If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really behooves you to define your prior z/OS release right now as a Software Instance."
>
> I do not want to assume that I completely understand your suggestion.
>
> Bob
>
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> --
>
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
________________________________
[https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] <http://www.aciworldwide.com>
This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
[https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] <http://www.aciworldwide.com>
This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
Ed Jaffe
Jul 20, 2021, 10:04:11 AM7/20/21
to
On 7/20/2021 4:41 AM, Richards, Robert B. (CTR) wrote:
> "If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really behooves you to define your prior z/OS release right now as a Software Instance."
>
> I do not want to assume that I completely understand your suggestion.
She means for you to go into the Software Management application in
> "If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really behooves you to define your prior z/OS release right now as a Software Instance."
>
> I do not want to assume that I completely understand your suggestion.
z/OSMF and add a new Software Instance. Choose your existing global CSI
and target zone as appropriate.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
kekronbekron
Jul 20, 2021, 10:22:56 AM7/20/21
to
"... you need to read my saved serverpac configuration file dataset."
Now that is a killer idea.
Unfortunately for us, I think IBM will rather hear about it through an RFE rather than 'be cool' and iterate quickly.
Dreaming on, I would also expect IBM to move away from XML (ugh) onto one of the newer config file formats (so the millenials may understand it).
Will also aid in programmatically managing workflows, and for their version control.
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Now that is a killer idea.
Unfortunately for us, I think IBM will rather hear about it through an RFE rather than 'be cool' and iterate quickly.
Dreaming on, I would also expect IBM to move away from XML (ugh) onto one of the newer config file formats (so the millenials may understand it).
Will also aid in programmatically managing workflows, and for their version control.
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > --
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] http://www.aciworldwide.com
>
> This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
>
Ed Jaffe
Jul 20, 2021, 10:59:38 AM7/20/21
to
On 7/20/2021 7:27 AM, Shaffer, Terri wrote:
> How would this even work? Or be complete.. SMPE doesn’t know about my SERVERPAC customizations. Or how about the CPAC. ** datasets or other operational names I setup.
When you create a Software Instance, you select a CSI and as many target
zones as you wish (perhaps all?). Then you add any Non-SMP/E Managed
data sets you wish to include and any products and features associated
with them. That's your layout.
When you deploy a Portable Software Instance, it asks you for a model
configuration. I'm assuming that's where Marna was thinking you would
specify your existing Software Instance. That should save *significant*
time when there are many data sets.
Any questions beyond that need to be directed toward her, since she is
the one that made the suggestion. All I did was clear up a gross
misunderstanding about ordinary Software Instances versus the PORTABLE
kind you get from ShopZ. (BTW, you create a Portable Software Instance
from an ordinary one by using the Export function.)\
> How would this even work? Or be complete.. SMPE doesn’t know about my SERVERPAC customizations. Or how about the CPAC. ** datasets or other operational names I setup.
When you create a Software Instance, you select a CSI and as many target
zones as you wish (perhaps all?). Then you add any Non-SMP/E Managed
data sets you wish to include and any products and features associated
with them. That's your layout.
When you deploy a Portable Software Instance, it asks you for a model
configuration. I'm assuming that's where Marna was thinking you would
specify your existing Software Instance. That should save *significant*
time when there are many data sets.
Any questions beyond that need to be directed toward her, since she is
the one that made the suggestion. All I did was clear up a gross
misunderstanding about ordinary Software Instances versus the PORTABLE
kind you get from ShopZ. (BTW, you create a Portable Software Instance
from an ordinary one by using the Export function.)\
Marna WALLE
Jul 20, 2021, 12:18:04 PM7/20/21
to
Robert,
It's been done, and is the proceedings: https://www.share.org/Events/Past-Events/Proceedings/Proceeding-Details/installing-ibms-serverpac-using-zosmf-software-management
Look for Kurt Quackenbush's "Installing IBM's ServerPac Using z/OSMF Software Management", from Ft Worth 2020. Kurt will do another session for the upcoming SHARE too.
-Marna WALLE
z/OS System Installation and Upgrade
It's been done, and is the proceedings: https://www.share.org/Events/Past-Events/Proceedings/Proceeding-Details/installing-ibms-serverpac-using-zosmf-software-management
Look for Kurt Quackenbush's "Installing IBM's ServerPac Using z/OSMF Software Management", from Ft Worth 2020. Kurt will do another session for the upcoming SHARE too.
-Marna WALLE
z/OS System Installation and Upgrade
Richards, Robert B. , CTR
Jul 20, 2021, 12:47:57 PM7/20/21
to
Marna,
I thought it might have been done. 😊 Thank you for the references to those proceedings.
Bob
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Marna WALLE
Sent: Tuesday, July 20, 2021 12:18 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests
I thought it might have been done. 😊 Thank you for the references to those proceedings.
Bob
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Marna WALLE
Sent: Tuesday, July 20, 2021 12:18 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests
Colin Paice
Jul 20, 2021, 1:05:19 PM7/20/21
to
This may be off topic...
I used SMP(/e) about 35+ years ago, I used to build CICS.
I now get my z/OS from ADCD. I download some volumes and have an IPLable
system. I could download the DLIBs if I wanted them.
Is this the sort of direction we should be going in? If IBM was to provide
the volumes every month/3months this might mean that people do not need to
use SMP/E unless they need a hot fix, you just download the next set of
volumes (or download the CICS volume(s), or the IMS volume(s))
I remember hearing one large customer talk about building a new system
every month with all refreshed products on it (based on CST from POK). IPL
it, and kill the oldest system. it meant one maintenance window a month -
not one for CICS, one for IMS, one for z/OS etc. They said it improved
up time, and saved a lot of sysprog time which they used for more testing.
It was a brave new world!
Colin
On Tue, 20 Jul 2021 at 17:51, Marna WALLE <mwa...@us.ibm.com> wrote:
> Hi Terri,
> When adding an Software Instance that you already have (say, z/OS V2.4),
> you are telling z/OSMF the CSI and zones to use. Those DDDEFs, presumably,
> will be correct with the data set names, volumes, and paths. Those DDDEFs
> will be used as a model on the incoming z/OS CSI DDDEFs. That will save
> you hundreds of customizations to do for z/OS V2.5 and beyond. I've seen
> many ServerPac saved configurations that are stale, and the CSI DDDEFs are
> the correct and current values. Meaning, that the ServerPac saved
> configuration can "drift" out of accuracy over time, but the CSI DDDEFs had
> better not. That is what I mean by saving time. Especially when you are
> basing on a known, accurate, SMP/E configuration.
>
> For the shipped configuration data sets (like CPAC.*): if you add those
> data sets to that Software Instance, then those data sets can be modelled
> too. If you choose not to, the worst thing is that the 16 CPAC data sets
> shipped with z/OS V2.5, can be modified *en masse* within the z/OSMF
> interface. Since they are all shipped with a HLQ of CPAC, it is very easy
> to filter, select, move, rename them as a group. With the z/OS V2.5
> Software Instance, they then become known and can be modelled with future
> z/OS Portable Software Instances.
>
> For the catalog: depending on what catalog options you want - new master
> cat, existing master cat and the data set names you select - the existing
> structure you have on your driving system can be used and detected, should
> you wish to use it. If you want a new master cat, you will need to supply
> the name and the temporary catalog alias of your choice (aka SSA), just
> like in the old ServerPac. If you want all your data sets to begin with
> "ZOSV25", and you have that existing HLQ alias going to an existing usercat
> today, no problem, that will be used. If you want to create a new master
> catalog, and use "MYSSA" as the temporary catalog alias, you'll need to
> supply that, just like in the old ServerPac. The catalog structure, I see,
> is similar to how the old ServerPac did it. Although, there is a lot more
> flexibility, because you can rename any data set, and put it in any catalog
> you want, with only VSAM (including zFS) forced to be cataloged. The old
> ServerPac had lots of restrictions on what could be renamed, and where it
> had to be cataloged.
>
> -Marna WALLE
> z/OS System Install and Upgrade
> IBM Poughkeepsie
I used SMP(/e) about 35+ years ago, I used to build CICS.
I now get my z/OS from ADCD. I download some volumes and have an IPLable
system. I could download the DLIBs if I wanted them.
Is this the sort of direction we should be going in? If IBM was to provide
the volumes every month/3months this might mean that people do not need to
use SMP/E unless they need a hot fix, you just download the next set of
volumes (or download the CICS volume(s), or the IMS volume(s))
I remember hearing one large customer talk about building a new system
every month with all refreshed products on it (based on CST from POK). IPL
it, and kill the oldest system. it meant one maintenance window a month -
not one for CICS, one for IMS, one for z/OS etc. They said it improved
up time, and saved a lot of sysprog time which they used for more testing.
It was a brave new world!
Colin
On Tue, 20 Jul 2021 at 17:51, Marna WALLE <mwa...@us.ibm.com> wrote:
> Hi Terri,
> When adding an Software Instance that you already have (say, z/OS V2.4),
> you are telling z/OSMF the CSI and zones to use. Those DDDEFs, presumably,
> will be correct with the data set names, volumes, and paths. Those DDDEFs
> will be used as a model on the incoming z/OS CSI DDDEFs. That will save
> you hundreds of customizations to do for z/OS V2.5 and beyond. I've seen
> many ServerPac saved configurations that are stale, and the CSI DDDEFs are
> the correct and current values. Meaning, that the ServerPac saved
> configuration can "drift" out of accuracy over time, but the CSI DDDEFs had
> better not. That is what I mean by saving time. Especially when you are
> basing on a known, accurate, SMP/E configuration.
>
> For the shipped configuration data sets (like CPAC.*): if you add those
> data sets to that Software Instance, then those data sets can be modelled
> too. If you choose not to, the worst thing is that the 16 CPAC data sets
> shipped with z/OS V2.5, can be modified *en masse* within the z/OSMF
> interface. Since they are all shipped with a HLQ of CPAC, it is very easy
> to filter, select, move, rename them as a group. With the z/OS V2.5
> Software Instance, they then become known and can be modelled with future
> z/OS Portable Software Instances.
>
> For the catalog: depending on what catalog options you want - new master
> cat, existing master cat and the data set names you select - the existing
> structure you have on your driving system can be used and detected, should
> you wish to use it. If you want a new master cat, you will need to supply
> the name and the temporary catalog alias of your choice (aka SSA), just
> like in the old ServerPac. If you want all your data sets to begin with
> "ZOSV25", and you have that existing HLQ alias going to an existing usercat
> today, no problem, that will be used. If you want to create a new master
> catalog, and use "MYSSA" as the temporary catalog alias, you'll need to
> supply that, just like in the old ServerPac. The catalog structure, I see,
> is similar to how the old ServerPac did it. Although, there is a lot more
> flexibility, because you can rename any data set, and put it in any catalog
> you want, with only VSAM (including zFS) forced to be cataloged. The old
> ServerPac had lots of restrictions on what could be renamed, and where it
> had to be cataloged.
>
> -Marna WALLE
> z/OS System Install and Upgrade
> IBM Poughkeepsie
Marna WALLE
Jul 20, 2021, 1:05:51 PM7/20/21
to
Hi Carmen,
Sorry to hear that z/OS V2.4 will be your least release! Good luck in retirement!
Once you have laid down a z/OSMF ServerPac, it will have the same considerations as if you had done it with the ISPF ServerPac dialogs, so I'm guessing the comments weren't about z/OSMF specifically?
Q: ...still have yet to find how to update / get RSU maint and define or change anything once the instance is defined but I've not really spent
too much time either...
A: You'd acquire PTFs just as you did when you installed z/OS V2.4. If it were me, I'd set up an automated job to pull PTFs and HOLDDATA nightly/weekly with SMP/E RECEIVE ORDER, specifying my new z/OS V2.5 global zone. The SMP/E CSI is there, just as always, for you to install PTFs and run reports...just like before. Of course, now that it is also known to z/OSMF, you could do an APPLY with z/OSMF Software Update should you wish. Once the Software Instance is known to z/OSMF, it knows the global and target zones, and can guide you through an APPLY of corrective, recommended, or functional PTFs. Or, you can use the same SMP/E JCL batch jobs you've used for decades. Your choice, and it doesn't matter. PTFs are APPLY into the CSI and both ways uses the CSI.
Q: I wonder since my company does not allow access from my mainframe systems to the internet, what protocol will be used to query my CSI's,
maint level? get service
A: Same methods as before. Nothing has changed. You can acquire a ServerPac via internet or DVD. If you can't use RECEIVE ORDEER to acquire PTFs, you can use Shopz and upload your CSI (or other ways).
Sorry to hear that z/OS V2.4 will be your least release! Good luck in retirement!
Once you have laid down a z/OSMF ServerPac, it will have the same considerations as if you had done it with the ISPF ServerPac dialogs, so I'm guessing the comments weren't about z/OSMF specifically?
Q: ...still have yet to find how to update / get RSU maint and define or change anything once the instance is defined but I've not really spent
too much time either...
A: You'd acquire PTFs just as you did when you installed z/OS V2.4. If it were me, I'd set up an automated job to pull PTFs and HOLDDATA nightly/weekly with SMP/E RECEIVE ORDER, specifying my new z/OS V2.5 global zone. The SMP/E CSI is there, just as always, for you to install PTFs and run reports...just like before. Of course, now that it is also known to z/OSMF, you could do an APPLY with z/OSMF Software Update should you wish. Once the Software Instance is known to z/OSMF, it knows the global and target zones, and can guide you through an APPLY of corrective, recommended, or functional PTFs. Or, you can use the same SMP/E JCL batch jobs you've used for decades. Your choice, and it doesn't matter. PTFs are APPLY into the CSI and both ways uses the CSI.
Q: I wonder since my company does not allow access from my mainframe systems to the internet, what protocol will be used to query my CSI's,
maint level? get service
A: Same methods as before. Nothing has changed. You can acquire a ServerPac via internet or DVD. If you can't use RECEIVE ORDEER to acquire PTFs, you can use Shopz and upload your CSI (or other ways).
Mike Schwab
Jul 20, 2021, 1:10:30 PM7/20/21
to
On Tue, Jul 20, 2021 at 12:05 PM Marna WALLE <mwa...@us.ibm.com> wrote:
>
> Q: I wonder since my company does not allow access from my mainframe systems to the internet, what protocol will be used to query my CSI's,
> maint level? get service
> A: Same methods as before. Nothing has changed. You can acquire a ServerPac via internet or DVD. If you can't use RECEIVE ORDEER to acquire PTFs, you can use Shopz and upload your CSI (or other ways).
>
How about ordering a zPDT laptop and download ADCD and do your new
>
> Q: I wonder since my company does not allow access from my mainframe systems to the internet, what protocol will be used to query my CSI's,
> maint level? get service
> A: Same methods as before. Nothing has changed. You can acquire a ServerPac via internet or DVD. If you can't use RECEIVE ORDEER to acquire PTFs, you can use Shopz and upload your CSI (or other ways).
>
volume set ups there, then have the laptop scanned before downloading
backups for installs?
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Carmen Vitullo
Jul 20, 2021, 1:23:26 PM7/20/21
to
thank you for the sanity check. I see that I can inquire missing /
critical maint, I was hoping that I could take the info and perform a
receive from that missing maint. using a defined protocol (ftps or
https) and have z/osmf submit the job to receive from network.
I do have a weekly job setup to get holddata and I can use that same
process to get RSU updates, so I'm glad to see this process along with
the order process didn't change so much.
thank you
Carmen
--
/I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
critical maint, I was hoping that I could take the info and perform a
receive from that missing maint. using a defined protocol (ftps or
https) and have z/osmf submit the job to receive from network.
I do have a weekly job setup to get holddata and I can use that same
process to get RSU updates, so I'm glad to see this process along with
the order process didn't change so much.
thank you
Carmen
/I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
Marna WALLE
Jul 20, 2021, 1:58:33 PM7/20/21
to
Hello KB,
As a little reference table, here's what's available today (and in the future) from Shopz as a ServerPac, along with the installation method. You can see that z/OSMF ServerPac has been available for many products, for quite a while now.
CICS (and program products):
z/OSMF ServerPac: Dec 2019 onwards
Legacy ServerPac way back, until Jan 2022
Db2 and IMS (and program products):
z/OSMF ServerPac: August 2020 onwards
Legacy ServerPac way back, until Jan 2022
z/OS V2.4 (and program products):
Legacy ServerPac Sept 2019, until Jan 2022
z/OS V2.5 (and program products):
z/OSMF ServerPac: Sept 2021 onwards
Legacy ServerPac Sept 2021, until Jan 2022
CBPDO is still available, and remains available beyond Jan 2022.
-Marna WALLE
z/OS Install and Upgrade
As a little reference table, here's what's available today (and in the future) from Shopz as a ServerPac, along with the installation method. You can see that z/OSMF ServerPac has been available for many products, for quite a while now.
CICS (and program products):
z/OSMF ServerPac: Dec 2019 onwards
Legacy ServerPac way back, until Jan 2022
Db2 and IMS (and program products):
z/OSMF ServerPac: August 2020 onwards
Legacy ServerPac way back, until Jan 2022
z/OS V2.4 (and program products):
Legacy ServerPac Sept 2019, until Jan 2022
z/OS V2.5 (and program products):
z/OSMF ServerPac: Sept 2021 onwards
Legacy ServerPac Sept 2021, until Jan 2022
CBPDO is still available, and remains available beyond Jan 2022.
-Marna WALLE
z/OS Install and Upgrade
Ed Jaffe
Jul 21, 2021, 12:50:21 AM7/21/21
to
On 7/20/2021 10:47 AM, Marna WALLE wrote:
> ... even with enlarging the data sets with some predictive percentage (50%, 100%, 200%?) - still doesn't completely help with running out of space in some data sets or even volumes continually, and could result in some data sets being overly and unnecessarily large. Would it be better if z/OS itself was able to assist better when the problem occurred in a targeted and timely fashion? Do you feel that if z/OSMF Software Management provided this ability to one-time increase the size of allocated target and DLIBs, that would conclusively solve your space problems for these data sets?
Unless I am misunderstanding root cause, in particular the reason LNKLST
data sets are delivered with zero secondary space, the fundamental
problem is a lack of support for new extents being added to active
LNKLST (or STEPLIB or perhaps any open DCB) for old-school PDS. I do not
think the problem exists for PDSE and zFS.
If so, this architectural issue is not something z/OSMF can solve...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
> ... even with enlarging the data sets with some predictive percentage (50%, 100%, 200%?) - still doesn't completely help with running out of space in some data sets or even volumes continually, and could result in some data sets being overly and unnecessarily large. Would it be better if z/OS itself was able to assist better when the problem occurred in a targeted and timely fashion? Do you feel that if z/OSMF Software Management provided this ability to one-time increase the size of allocated target and DLIBs, that would conclusively solve your space problems for these data sets?
Unless I am misunderstanding root cause, in particular the reason LNKLST
data sets are delivered with zero secondary space, the fundamental
problem is a lack of support for new extents being added to active
LNKLST (or STEPLIB or perhaps any open DCB) for old-school PDS. I do not
think the problem exists for PDSE and zFS.
If so, this architectural issue is not something z/OSMF can solve...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
Gibney, Dave
Jul 21, 2021, 1:23:20 AM7/21/21
to
I don't know how it would work with zOSMF, but I don't worry about the dataset sizes of my SMPE target datasets. Because I never IPL using them.
I copy to new SYSRES, FDR and ADRDSSU dataset copies to single extents. Of course, I rarely (maybe 5 to 5 times in 30 years) put maintenance into a running system
> -----Original Message-----
> From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On
> Behalf Of Ed Jaffe
> Sent: Tuesday, July 20, 2021 9:50 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Serverpac installs January 2022 and beyond - Requests
>
> EgBY0HMszNaDT!8fkfhIsYHEp9Ax8Nex3iS2vOD0fjNwQSKRgiDD_pZGp7xn1t_
> xDQ2PZ06MHs6Q$
I copy to new SYSRES, FDR and ADRDSSU dataset copies to single extents. Of course, I rarely (maybe 5 to 5 times in 30 years) put maintenance into a running system
> -----Original Message-----
> From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On
> Behalf Of Ed Jaffe
> Sent: Tuesday, July 20, 2021 9:50 PM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Serverpac installs January 2022 and beyond - Requests
>
> On 7/20/2021 10:47 AM, Marna WALLE wrote:
> > ... even with enlarging the data sets with some predictive percentage (50%,
> 100%, 200%?) - still doesn't completely help with running out of space in
> some data sets or even volumes continually, and could result in some data
> sets being overly and unnecessarily large. Would it be better if z/OS itself
> was able to assist better when the problem occurred in a targeted and timely
> fashion? Do you feel that if z/OSMF Software Management provided this
> ability to one-time increase the size of allocated target and DLIBs, that would
> conclusively solve your space problems for these data sets?
> Unless I am misunderstanding root cause, in particular the reason LNKLST
> data sets are delivered with zero secondary space, the fundamental
> problem is a lack of support for new extents being added to active
> LNKLST (or STEPLIB or perhaps any open DCB) for old-school PDS. I do not
> think the problem exists for PDSE and zFS.
>
> If so, this architectural issue is not something z/OSMF can solve...
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!JmP
> > ... even with enlarging the data sets with some predictive percentage (50%,
> 100%, 200%?) - still doesn't completely help with running out of space in
> some data sets or even volumes continually, and could result in some data
> sets being overly and unnecessarily large. Would it be better if z/OS itself
> was able to assist better when the problem occurred in a targeted and timely
> fashion? Do you feel that if z/OSMF Software Management provided this
> ability to one-time increase the size of allocated target and DLIBs, that would
> conclusively solve your space problems for these data sets?
> Unless I am misunderstanding root cause, in particular the reason LNKLST
> data sets are delivered with zero secondary space, the fundamental
> problem is a lack of support for new extents being added to active
> LNKLST (or STEPLIB or perhaps any open DCB) for old-school PDS. I do not
> think the problem exists for PDSE and zFS.
>
> If so, this architectural issue is not something z/OSMF can solve...
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> EgBY0HMszNaDT!8fkfhIsYHEp9Ax8Nex3iS2vOD0fjNwQSKRgiDD_pZGp7xn1t_
> xDQ2PZ06MHs6Q$
Barbara Nitz
Jul 21, 2021, 4:08:13 AM7/21/21
to
Hi Marna,
>Making everything bigger is not a good option. Not everything "needs" to be bigger, but there are those that even 40% won't be enough. <snip> I think creating z/OSMF product delivery without the ability to change the size and location of the datasets (easily) is a bad idea.
I am with Brian on the subject of sizing. I would allocate lnklst (target) datasets without extents at 200% of what is used right now. And increase directory sizes accordingly. And remember to increase sizes for the corresponding DLIB data sets. But that won't help the x37 completely (and I don't think that there is definite help for it). If it helps, I can compile a list of which data sets blew up with x37 over the course of installing 2.3 and 8 refreshs (we do a refresh twice a year). IIRC, the datasets where new functions went in blew up.
I don't much care how converting PDS to PDSE is handled, but I also think that z/OSMF absolutely *MUST* provide the ability to edit the jobs before they are submitted.
>I am wondering, if it might be of better use to have the capability of accommodating the need for more space in a more ongoing manner?
What would help in my opinion would be a pre-apply hold action for each dataset that might blow up because a lot got changed. Then it is my responsibility to increase the size before apply. Or z/OSMF can take a look and automatically reallocate the target and DLIB data set, copy the old stuff in and then use the new stuff for the actual apply.
Of course, that assumes that apply is always done into inactive target data sets. Mine are not even catalogued. Apply of a large set of ptfs into the active system is a bad idea anyway, in my opinion.
My idea probably also runs counter to the way the full system replacement is set up, both in the dialogs and in z/OSMF, because they use the data sets the install went into for IPL.
Regards, Barbara
>Making everything bigger is not a good option. Not everything "needs" to be bigger, but there are those that even 40% won't be enough. <snip> I think creating z/OSMF product delivery without the ability to change the size and location of the datasets (easily) is a bad idea.
I am with Brian on the subject of sizing. I would allocate lnklst (target) datasets without extents at 200% of what is used right now. And increase directory sizes accordingly. And remember to increase sizes for the corresponding DLIB data sets. But that won't help the x37 completely (and I don't think that there is definite help for it). If it helps, I can compile a list of which data sets blew up with x37 over the course of installing 2.3 and 8 refreshs (we do a refresh twice a year). IIRC, the datasets where new functions went in blew up.
I don't much care how converting PDS to PDSE is handled, but I also think that z/OSMF absolutely *MUST* provide the ability to edit the jobs before they are submitted.
>I am wondering, if it might be of better use to have the capability of accommodating the need for more space in a more ongoing manner?
What would help in my opinion would be a pre-apply hold action for each dataset that might blow up because a lot got changed. Then it is my responsibility to increase the size before apply. Or z/OSMF can take a look and automatically reallocate the target and DLIB data set, copy the old stuff in and then use the new stuff for the actual apply.
Of course, that assumes that apply is always done into inactive target data sets. Mine are not even catalogued. Apply of a large set of ptfs into the active system is a bad idea anyway, in my opinion.
My idea probably also runs counter to the way the full system replacement is set up, both in the dialogs and in z/OSMF, because they use the data sets the install went into for IPL.
Regards, Barbara
Seymour J Metz
Jul 21, 2021, 8:59:24 AM7/21/21
to
I see the requirements as being different for dlib, target and operational datasets. For operational datasets, there is simply no way to have a "one size fits all", so IBM should make it as easy to tailor those as in the older delivery vehicles.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Brian Westerman [Brian_W...@SYZYGYINC.COM]
Sent: Wednesday, July 21, 2021 1:30 AM
Making everything bigger is not a good option. Not everything "needs" to be bigger, but there are those that even 40% won't be enough. The Serverpac used to ship with SMF and JES spool/checkpoint and SMF on the catalog volume, and I'm sure no one probably leaves it there, but the size of the datasets is a big issue. For instance, if you wanted to use a full 3390-27 for the spool dataset (not an unreasonable size), how would you do that using z/OSMF? My assumption from your previous answers is that you can't. It's not hard to change this later, but you have just made the installation process a LOT more difficult for people. Some people will want a 3390-9 or a 3390-54, and that's just the one single dataset, there are lots more that will end up with exactly the same issue(s). I think creating z/OSMF product delivery without the ability to change the size and location of the datasets (easily) is a bad idea. Among all of the other "bad ideas" I have already identified in z/OSMF.
Brian
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Brian Westerman [Brian_W...@SYZYGYINC.COM]
Sent: Wednesday, July 21, 2021 1:30 AM
Making everything bigger is not a good option. Not everything "needs" to be bigger, but there are those that even 40% won't be enough. The Serverpac used to ship with SMF and JES spool/checkpoint and SMF on the catalog volume, and I'm sure no one probably leaves it there, but the size of the datasets is a big issue. For instance, if you wanted to use a full 3390-27 for the spool dataset (not an unreasonable size), how would you do that using z/OSMF? My assumption from your previous answers is that you can't. It's not hard to change this later, but you have just made the installation process a LOT more difficult for people. Some people will want a 3390-9 or a 3390-54, and that's just the one single dataset, there are lots more that will end up with exactly the same issue(s). I think creating z/OSMF product delivery without the ability to change the size and location of the datasets (easily) is a bad idea. Among all of the other "bad ideas" I have already identified in z/OSMF.
Brian
Seymour J Metz
Jul 21, 2021, 9:23:14 AM7/21/21
to
What is SETPROG LNKLST, chopped liver?
Well, that doesn't help for active tasklibs, and it's a manual operation for the link list, but it is at least a partial solution.
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Ed Jaffe [edj...@PHOENIXSOFTWARE.COM]
Sent: Wednesday, July 21, 2021 12:50 AM
Well, that doesn't help for active tasklibs, and it's a manual operation for the link list, but it is at least a partial solution.
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Ed Jaffe [edj...@PHOENIXSOFTWARE.COM]
Sent: Wednesday, July 21, 2021 12:50 AM
On 7/20/2021 10:47 AM, Marna WALLE wrote:
> ... even with enlarging the data sets with some predictive percentage (50%, 100%, 200%?) - still doesn't completely help with running out of space in some data sets or even volumes continually, and could result in some data sets being overly and unnecessarily large. Would it be better if z/OS itself was able to assist better when the problem occurred in a targeted and timely fashion? Do you feel that if z/OSMF Software Management provided this ability to one-time increase the size of allocated target and DLIBs, that would conclusively solve your space problems for these data sets?
Unless I am misunderstanding root cause, in particular the reason LNKLST
data sets are delivered with zero secondary space, the fundamental
problem is a lack of support for new extents being added to active
LNKLST (or STEPLIB or perhaps any open DCB) for old-school PDS. I do not
think the problem exists for PDSE and zFS.
If so, this architectural issue is not something z/OSMF can solve...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://secure-web.cisco.com/1Hth1sk0gAiJNGXf8lh5wlTQRsObUw1JzYjdrJbdv0J-FbGvYNwz0mSqfwBZF7GNrWKHF0ZTM5saAjqWfjWxDbMcyl1Mtn3zUebm6hWXC2rUPVCNPkxGpOiktm57reU-C2rq1QMVFiFf5Jh_bYAr1JeYkXrg2Z2GgWpZMwSu24qmV1TRQIFF85jFZ_SLFzo5-eCKoBFqF3pZolPMAX4_8rs9HB0FeSjt8TKxH8KPbgWgloGo3SBmDiDSsKaP21FRTy8UKbSwRdwwGasZPuhE4B3VoNHIUEiDDdLn3VF-guSqeYohTYxf4NigLsm9udsjMxNJLJt1DlUyrYPy8nonLZpDxgfQEskNkHd6AMvIfvbPVwXMLvGhvJlreN1Ms4ArmU45r7-ifMuJZ0ni0Xteo_1kVrbUHzmR2ugyv3N4t0dhVqT6l6aetGsbiDkblNKrr05jQI2gnSS8UYQioW1MnPg/https%3A%2F%2Fwww.phoenixsoftware.com%2F
> ... even with enlarging the data sets with some predictive percentage (50%, 100%, 200%?) - still doesn't completely help with running out of space in some data sets or even volumes continually, and could result in some data sets being overly and unnecessarily large. Would it be better if z/OS itself was able to assist better when the problem occurred in a targeted and timely fashion? Do you feel that if z/OSMF Software Management provided this ability to one-time increase the size of allocated target and DLIBs, that would conclusively solve your space problems for these data sets?
Unless I am misunderstanding root cause, in particular the reason LNKLST
data sets are delivered with zero secondary space, the fundamental
problem is a lack of support for new extents being added to active
LNKLST (or STEPLIB or perhaps any open DCB) for old-school PDS. I do not
think the problem exists for PDSE and zFS.
If so, this architectural issue is not something z/OSMF can solve...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
Marna WALLE
Jul 21, 2021, 11:58:38 AM7/21/21
to
Brian,
Let's make a clear distinction. Inside the z/OS z/OSMF ServerPac package that is shipped to you, and I'm talking about the archived datasets for you to restore, these are the data sets you'll receive (which is somewhat based on what the product mix you ordered from Shopz):
--SMP/E target (including zFS), DLIB, CSIs,
--"non-SMP/E data sets" : CPAC data sets, sample RACF data bases, a sample VTAMLST, a sample SYS1.PARMLIB and sample SYS1.PROCLIB (empty), a sample IPLPARM data set, three sample zFS for z/OS UNIX (var, etc..), a sample TCPIP IVP data set, and three Workflows. Several of these non-SMP/E data sets (RACF db, IPLPARM, VTAMLST, SYS1.PARMLIB, SYS1.PROCLIB...), I doubt are ever really used. I also doubt that resizing the data sets you don't use is an issue here.
All these above data sets are those which you can rename, move and catalog anyway you want easily. However, note I didn't say "size" on that last sentence. I well understand that topic, as well as know that the most important on that list is the target and DLIBs. But I also understand that SMP/E maintenance activity isn't the only use case for running out of room in data sets and volumes. It is probably the one that system programmers most don't like to deal with. I also don't want to leave the impression that we don't know we need to do *something* to help here. Please let's not debate how important it is to not run out of space in data sets during an APPLY or ACCEPT, and we need a solution. We are in agreement there.
Now, there are additional operational data sets (JES, Sysplex couple ds, BCP page/SMF/dump..., Health Checker, DFSMS SMS, PFA, WLM, just to name a few) that ServerPac "provides" (both for the ISPF and the z/OSMF methods). For these additional operational data sets in a z/OS z/OSMF ServerPac, you will have complete control over placement, name, *and size*. These operational data sets are created with the z/OS z/OSMF ServerPac via Workflow steps. You don't need to run those Workflow steps if you want to reuse what you already have (aka Software Update vs. Full System Replace). Also - to go even a step farther - z/OSMF ServerPac can even give you a semi-Software Update that the ISPF ServerPac never could. Only want help setting up PFA, with keeping your existing page, spool, and couple data sets? Fine - just run only the PFA Workflow step. In that way, it is truly selectable on what operationals you want help with. I see this as a definite improvement over the ISPF ServerPac.
Using Workflow variables or the using *the ability to edit the JCL* you can do any changes you want. Please let's not debate that the size of page or SMF are not controllable by the user, or how important that is. You can put them wherever you want, size them however you want, and call them whatever you want. If anything, z/OSMF Workflows make these operational data sets more under your control than ever, if you want to even have them created in the first place.
I'm hoping that the above description with these three categories of data sets to expect with a z/OS z/OSMF ServerPac, has helped to understand what is, and is (currently) not under your control.
-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie
Let's make a clear distinction. Inside the z/OS z/OSMF ServerPac package that is shipped to you, and I'm talking about the archived datasets for you to restore, these are the data sets you'll receive (which is somewhat based on what the product mix you ordered from Shopz):
--SMP/E target (including zFS), DLIB, CSIs,
--"non-SMP/E data sets" : CPAC data sets, sample RACF data bases, a sample VTAMLST, a sample SYS1.PARMLIB and sample SYS1.PROCLIB (empty), a sample IPLPARM data set, three sample zFS for z/OS UNIX (var, etc..), a sample TCPIP IVP data set, and three Workflows. Several of these non-SMP/E data sets (RACF db, IPLPARM, VTAMLST, SYS1.PARMLIB, SYS1.PROCLIB...), I doubt are ever really used. I also doubt that resizing the data sets you don't use is an issue here.
All these above data sets are those which you can rename, move and catalog anyway you want easily. However, note I didn't say "size" on that last sentence. I well understand that topic, as well as know that the most important on that list is the target and DLIBs. But I also understand that SMP/E maintenance activity isn't the only use case for running out of room in data sets and volumes. It is probably the one that system programmers most don't like to deal with. I also don't want to leave the impression that we don't know we need to do *something* to help here. Please let's not debate how important it is to not run out of space in data sets during an APPLY or ACCEPT, and we need a solution. We are in agreement there.
Now, there are additional operational data sets (JES, Sysplex couple ds, BCP page/SMF/dump..., Health Checker, DFSMS SMS, PFA, WLM, just to name a few) that ServerPac "provides" (both for the ISPF and the z/OSMF methods). For these additional operational data sets in a z/OS z/OSMF ServerPac, you will have complete control over placement, name, *and size*. These operational data sets are created with the z/OS z/OSMF ServerPac via Workflow steps. You don't need to run those Workflow steps if you want to reuse what you already have (aka Software Update vs. Full System Replace). Also - to go even a step farther - z/OSMF ServerPac can even give you a semi-Software Update that the ISPF ServerPac never could. Only want help setting up PFA, with keeping your existing page, spool, and couple data sets? Fine - just run only the PFA Workflow step. In that way, it is truly selectable on what operationals you want help with. I see this as a definite improvement over the ISPF ServerPac.
Using Workflow variables or the using *the ability to edit the JCL* you can do any changes you want. Please let's not debate that the size of page or SMF are not controllable by the user, or how important that is. You can put them wherever you want, size them however you want, and call them whatever you want. If anything, z/OSMF Workflows make these operational data sets more under your control than ever, if you want to even have them created in the first place.
I'm hoping that the above description with these three categories of data sets to expect with a z/OS z/OSMF ServerPac, has helped to understand what is, and is (currently) not under your control.
-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie
Marna WALLE
Jul 21, 2021, 11:59:21 AM7/21/21
to
Bruce,
Thank you! This is very helpful for us to have!
Thank you! This is very helpful for us to have!
Tom Brennan
Jul 21, 2021, 2:19:19 PM7/21/21
to
Same with me when I ran ServerPac installs - I never IPL'd using the
datasets provided by the installer such as catalogs, RACF, spool, SMF,
page, etc. I never understood IBM's reason for doing that, and also
never understood the reason for running the system validation jobs on
the vanilla system. What was much more important for us was IPLing the
new res pack on a sandbox system with our own system datasets, parms,
and usermods - and then solve any issues that may come up.
So those IBM-supplied system datasets were never used, and although I
could not delete them using the CPP dialog, I would always set them to 1
track or 1 cylinder before running the alloc job - just to save space.
It just made little sense to me to prove the vanilla system from IBM
works correctly. Of course it does, otherwise why would they send it to me?
On 7/20/2021 10:23 PM, Gibney, Dave wrote:
> I don't know how it would work with zOSMF, but I don't worry about the dataset sizes of my SMPE target datasets. Because I never IPL using them.
> I copy to new SYSRES, FDR and ADRDSSU dataset copies to single extents. Of course, I rarely (maybe 5 to 5 times in 30 years) put maintenance into a running system
datasets provided by the installer such as catalogs, RACF, spool, SMF,
page, etc. I never understood IBM's reason for doing that, and also
never understood the reason for running the system validation jobs on
the vanilla system. What was much more important for us was IPLing the
new res pack on a sandbox system with our own system datasets, parms,
and usermods - and then solve any issues that may come up.
So those IBM-supplied system datasets were never used, and although I
could not delete them using the CPP dialog, I would always set them to 1
track or 1 cylinder before running the alloc job - just to save space.
It just made little sense to me to prove the vanilla system from IBM
works correctly. Of course it does, otherwise why would they send it to me?
On 7/20/2021 10:23 PM, Gibney, Dave wrote:
> I don't know how it would work with zOSMF, but I don't worry about the dataset sizes of my SMPE target datasets. Because I never IPL using them.
> I copy to new SYSRES, FDR and ADRDSSU dataset copies to single extents. Of course, I rarely (maybe 5 to 5 times in 30 years) put maintenance into a running system
Tom Brennan
Jul 21, 2021, 2:29:01 PM7/21/21
to
We always seemed to be at the limit of our res pack, so after a new
install I would run a job that to compress and trim (to zero) most PDS's
with the idea that they would just go into extents as needed if updates
were made. We rarely updated a res pack in place, so there was usually
no problem with this plan. However, I believe we did leave room in some
of the datasets people mentioned here (LINKLIB and similar) which saved
us from LLA issues if we need to make a mod to a running system.
These compress/trim jobs were outside the realm of the ServerPac dialog
of course.
install I would run a job that to compress and trim (to zero) most PDS's
with the idea that they would just go into extents as needed if updates
were made. We rarely updated a res pack in place, so there was usually
no problem with this plan. However, I believe we did leave room in some
of the datasets people mentioned here (LINKLIB and similar) which saved
us from LLA issues if we need to make a mod to a running system.
These compress/trim jobs were outside the realm of the ServerPac dialog
of course.
Brian Westerman
Jul 22, 2021, 12:25:44 AM7/22/21
to
Some of the problem here is that you are telling me what "will" be there, but I don't have anything that actually shows that or even implies it for z/OSMF for z/OS. I don't even have the workflows to verify anything.
I'm really hoping that I'm being Chicken Little here, but it's looking less and less like a good alternative to use z/OSMF. I still have a big fear of it being the "only" option so soon after it is first created. People won't have much time between Late September and January to discover and correct all of the bugs.
Brian
I'm really hoping that I'm being Chicken Little here, but it's looking less and less like a good alternative to use z/OSMF. I still have a big fear of it being the "only" option so soon after it is first created. People won't have much time between Late September and January to discover and correct all of the bugs.
Brian
>-Marna WALLE
>z/OS System Install and Upgrade
>IBM Poughkeepsie
>
>z/OS System Install and Upgrade
>IBM Poughkeepsie
>
Brian Westerman
Jul 22, 2021, 12:28:35 AM7/22/21
to
I'm almost completely the opposite, I use it as an opportunity to replace the datasets and make corrections to their allocations. Although in my case I am normally coming in after someone messed up or 5 to 10 years (or more) after the previous upgrade so the sizes and allocations in many cases no longer work the same.
Brian
On Wed, 21 Jul 2021 11:19:09 -0700, Tom Brennan <t...@TOMBRENNANSOFTWARE.COM> wrote:
>Same with me when I ran ServerPac installs - I never IPL'd using the
>datasets provided by the installer such as catalogs, RACF, spool, SMF,
>page, etc. I never understood IBM's reason for doing that, and also
>never understood the reason for running the system validation jobs on
>the vanilla system. What was much more important for us was IPLing the
>new res pack on a sandbox system with our own system datasets, parms,
>and usermods - and then solve any issues that may come up.
>
>So those IBM-supplied system datasets were never used, and although I
>could not delete them using the CPP dialog, I would always set them to 1
>track or 1 cylinder before running the alloc job - just to save space.
>
>It just made little sense to me to prove the vanilla system from IBM
>works correctly. Of course it does, otherwise why would they send it to me?
>
>On 7/20/2021 10:23 PM, Gibney, Dave wrote:
>> I don't know how it would work with zOSMF, but I don't worry about the dataset sizes of my SMPE target datasets. Because I never IPL using them.
>> I copy to new SYSRES, FDR and ADRDSSU dataset copies to single extents. Of course, I rarely (maybe 5 to 5 times in 30 years) put maintenance into a running system
>
Brian
On Wed, 21 Jul 2021 11:19:09 -0700, Tom Brennan <t...@TOMBRENNANSOFTWARE.COM> wrote:
>Same with me when I ran ServerPac installs - I never IPL'd using the
>datasets provided by the installer such as catalogs, RACF, spool, SMF,
>page, etc. I never understood IBM's reason for doing that, and also
>never understood the reason for running the system validation jobs on
>the vanilla system. What was much more important for us was IPLing the
>new res pack on a sandbox system with our own system datasets, parms,
>and usermods - and then solve any issues that may come up.
>
>So those IBM-supplied system datasets were never used, and although I
>could not delete them using the CPP dialog, I would always set them to 1
>track or 1 cylinder before running the alloc job - just to save space.
>
>It just made little sense to me to prove the vanilla system from IBM
>works correctly. Of course it does, otherwise why would they send it to me?
>
>On 7/20/2021 10:23 PM, Gibney, Dave wrote:
>> I don't know how it would work with zOSMF, but I don't worry about the dataset sizes of my SMPE target datasets. Because I never IPL using them.
>> I copy to new SYSRES, FDR and ADRDSSU dataset copies to single extents. Of course, I rarely (maybe 5 to 5 times in 30 years) put maintenance into a running system
>
deea alta
Jul 22, 2021, 7:35:29 AM7/22/21
to
On Monday, July 19, 2021 at 7:08:48 AM UTC-4, Shaffer, Terri wrote:
> So, I am going to ease up on IBM a little, except for the resources needed for z/OSMF, But have a few usability requests just as in the serverpac.
>
> I am not 100% convinced yet, but I see no way of editing a job that was generated, BEFORE submit!!
>
> I also see fields on the screen but no context help as to know what they want to fill in, like * Work data set name prefix: what was the equivalent ??
>
> This is critical, in many shops I have every installed SEVERPAC in, due to catalogs naming's mostly and where datasets live.
>
> In serverpac, you could SAVE JCL and recall using BACKUP to re-run something you had to modify for whatever reason. That ability seems gone??
>
> I will test using z/OSMF based on what I saw in the DEMO, but when dealing with 1200+ z/OS datasets across, probably 5 or 6 volumes, in my experience always needed tweaked!
>
> Again, maybe for the sysprog, who doesn’t understand, this make perfect sense, but there are many times, the canned/generated JCL will not work in an environment and the dialogs don’t allow it to be fixed.
> So, I am going to ease up on IBM a little, except for the resources needed for z/OSMF, But have a few usability requests just as in the serverpac.
>
> I am not 100% convinced yet, but I see no way of editing a job that was generated, BEFORE submit!!
>
> I also see fields on the screen but no context help as to know what they want to fill in, like * Work data set name prefix: what was the equivalent ??
>
> This is critical, in many shops I have every installed SEVERPAC in, due to catalogs naming's mostly and where datasets live.
>
> In serverpac, you could SAVE JCL and recall using BACKUP to re-run something you had to modify for whatever reason. That ability seems gone??
>
> I will test using z/OSMF based on what I saw in the DEMO, but when dealing with 1200+ z/OS datasets across, probably 5 or 6 volumes, in my experience always needed tweaked!
>
> Again, maybe for the sysprog, who doesn’t understand, this make perfect sense, but there are many times, the canned/generated JCL will not work in an environment and the dialogs don’t allow it to be fixed.
>
> Ms Terri E Shaffer
> Senior Systems Engineer,
> z/OS Support:
> ACIWorldwide – Telecommuter
> H(412-766-2697) C(412-519-2592)
> Terri....@aciworldwide.com
>
> ________________________________
> Ms Terri E Shaffer
> Senior Systems Engineer,
> z/OS Support:
> ACIWorldwide – Telecommuter
> H(412-766-2697) C(412-519-2592)
> Terri....@aciworldwide.com
>
> [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] <http://www.aciworldwide.com>
> This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
>
> This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OSMF needs to be updated in many aspects before this becomes the definitive tool to use for z/OS installation. I'm surprised that the dataset allocation issue has not been changed yet. Anyone with any experience with ServerPac knows about the SB37 abends with dataset sizing.
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Carmen Vitullo
Jul 22, 2021, 10:19:49 AM7/22/21
to
I think I IPL'd the CPAC system that was built from the ServerPac once
in my career, it was the company/dept's standard and we had a small LPAR
built just for that reason. Documentation was provided, IPLing the CPAC
system was only done to proceed with the ServerPac install.
moving on from that company I moved to a different process, seems
everyone has a better way, for me building the target sysres and zfs
file systems, running some IVP tests and build my new master catalog,
and IPL that system on my sandbox system.
I have a documented process to copy/migrate the new version or maint to
production that works well even for someone who's not a z/os sysprog.
Carmen
in my career, it was the company/dept's standard and we had a small LPAR
built just for that reason. Documentation was provided, IPLing the CPAC
system was only done to proceed with the ServerPac install.
moving on from that company I moved to a different process, seems
everyone has a better way, for me building the target sysres and zfs
file systems, running some IVP tests and build my new master catalog,
and IPL that system on my sandbox system.
I have a documented process to copy/migrate the new version or maint to
production that works well even for someone who's not a z/os sysprog.
Carmen
--
/I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
/I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
Tom Brennan
Jul 22, 2021, 10:38:11 AM7/22/21
to
"seems everyone has a better way"
I think you hit on the root of the problem. With Windows and Linux
installs, everyone (generally) does things the same exact way, including
filenames and directory locations. They don't have the problems we have
with mainframe installs.
Carmen Vitullo
Jul 22, 2021, 10:53:59 AM7/22/21
to
ah YUP!
I was going to add, when I did a short jaunt with IGS, most of the IBM
sysprog's never heard of ServerPac and most never provided or worked
with a custompac install.
The clients systems are built based on what the client needs, sometime
just the base system, sometimes the base+OEM products, that info is
provided to another IBM service that builds the system, then restored to
the clients systems using Txxxxx and Dxxxxx volumes. so the customer is
not really involved.
Curious where z/osmf will participate, if at all in these scenario's
unfortunately and somewhat fortunate for me I've worked at a lot of
different sites, only when I was 'THE GUY" did the install process stay
the same from company to company. :)
I think, with anything else new, z/osmf once embarrassed, installing the
OS and products will be somewhat like 'those' platforms.
Carmen
I was going to add, when I did a short jaunt with IGS, most of the IBM
sysprog's never heard of ServerPac and most never provided or worked
with a custompac install.
The clients systems are built based on what the client needs, sometime
just the base system, sometimes the base+OEM products, that info is
provided to another IBM service that builds the system, then restored to
the clients systems using Txxxxx and Dxxxxx volumes. so the customer is
not really involved.
Curious where z/osmf will participate, if at all in these scenario's
unfortunately and somewhat fortunate for me I've worked at a lot of
different sites, only when I was 'THE GUY" did the install process stay
the same from company to company. :)
I think, with anything else new, z/osmf once embarrassed, installing the
OS and products will be somewhat like 'those' platforms.
Carmen
--
/I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
/I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
Gibney, Dave
Jul 22, 2021, 12:39:40 PM7/22/21
to
My last several Serverpac installs had very few issues. Most were self-inflicted. Like the time I failed to order the optional regulated encryption. Or this last time, when do to poor timing, I had to start with a z/OS 2.3 archive, then add Java 😊
For at least the last 3, implementation in production was a non-event. Which is as it should be.
> -----Original Message-----
> From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On
> Behalf Of Tom Brennan
> Sent: Thursday, July 22, 2021 7:38 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Serverpac installs January 2022 and beyond - Requests
>
For at least the last 3, implementation in production was a non-event. Which is as it should be.
> -----Original Message-----
> From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On
> Behalf Of Tom Brennan
> Sent: Thursday, July 22, 2021 7:38 AM
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Serverpac installs January 2022 and beyond - Requests
>
Brian Westerman
Jul 23, 2021, 2:19:31 AM7/23/21
to
Except for C:\Windows and the Program files directory, I don't think I keep anything where Microsoft wants me to. I like to keep everything that isn't the vanilla MS system on other drives and I create links to them so that I can reinstall when I want and just redo the links.
But then I also update the registry manually as well, so maybe I'm a bad example.
Brian
But then I also update the registry manually as well, so maybe I'm a bad example.
Brian
Barbara Nitz
Jul 23, 2021, 4:27:43 AM7/23/21
to
>Its interesting, because I don’t have any products that give me extra extents except what SMS does for me space wise, and I have never increased my dataset size allocations.
Just as a preparation for increasing allocations, here is what failed x37 in the past 8 refreshes (all on the *installation* target volume, never IPL'd from). I apply maintenance twice a year, too, and it is always upwards of 1000ptfs. SMPE was dealing with a few of those x37 doing in-flight compresses, but I had only the last refresh without having to increase sizes.
#1
IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB
IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS
IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0
IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0
IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN
#2
IEC032I E37-04,IFG0554P,,APPLY,SGIMTENU,GIM.SGIMTENU
IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG
IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG
IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD
IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG
IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG
IOEZ00312I Dynamic growth of aggregate xxxxx.SIZUUSRD in progress
#3
Made an error during increase of data sets, ended up restoring everything and increasing (joblogs from before restore not saved)
SCBDMENU
SMPSTS 16->50 trks, sec 5
SASMMOD1 50->80 trks
#4
Accept of previous maintenance:
IEC032I E37-04,IFG0554P,,ACCEPT,ABBLLIB,BBL.ABBLLIB
Apply new:
IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB
IEC031I D37-04,IFG0554P,,APPLY,SICELINK,SYS1.SICELINK
#5
Accept of previous maintenance:
IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU
IEC032I E37-04,IFG0554P,,ACCEPT,AERBPWSV,SYS1.AERBPWSV
IEC032I E37-04,IFG0554P,,ACCEPT,AHAPINC3,HAP.AHAPINC3
IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU
Apply new:
IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV
IEC032I E37-04,IFG0554P,,APPLY,SEEQINST,SYS1.SEEQINST
IEC031I D37-04,IFG0554P,,APPLY,MIGLIB,SYS1.MIGLIB
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD
IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN
#6
IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK
IEC031I D37-04,IFG0554P,,APPLY,CMDLIB,SYS1.CMDLIB
IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB
IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS
IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1
#7
IEC032I E37-04,IFG0554P,,APPLY,SISFTLIB,ISF.SISFTLIB
IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV
IOEZ00312I Dynamic growth of aggregate xxxxx.SAZFAMOD in progress
IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK
IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD
IEC032I E37-04,IFG0554P,,APPLY,SCEELPA,CEE.SCEELPA
#8
Accept of previous maintenance:
IEC032I E37-04,IFG0554P,1,ACCEPT,AGIMTENU,GIM.AGIMTENU
IEC032I E37-04,IFG0554P,1,ACCEPT,AISFTLIB,ISF.AISFTLIB
IEC032I E37-04,IFG0554P,1,ACCEPT,AAZFAMOD,AZF.AAZFAMOD
IEC032I E37-04,IFG0554P,1,ACCEPT,AHAPINC3,HAP.AHAPINC3
Apply new:
IEC031I D37-04,IFG0554P,,APPLY,DGTLLIB,SYS1.DGTLLIB
With z/OS 2.5, I'll probably triple allocations for those data sets during allocation.
>That being said, my cloning process copies my res volume and ZFS datasets to new volumes and resets extents to current used, which is why I never used the software deployment and NEVER will in z/OSMF.
Right now the plan is for my successor to install z/OSMF once we're on 2.5. *I* will certainly NEVER use z/OSMF to do the rollout to all the other sysplexes. Cloning is done in 4 jobs and they work and are easily controlled.
Regards, Barbara
Just as a preparation for increasing allocations, here is what failed x37 in the past 8 refreshes (all on the *installation* target volume, never IPL'd from). I apply maintenance twice a year, too, and it is always upwards of 1000ptfs. SMPE was dealing with a few of those x37 doing in-flight compresses, but I had only the last refresh without having to increase sizes.
#1
IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB
IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS
IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0
IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
IEC031I D37-04,IFG0554P,,APPLY,SGIMLMD0,GIM.SGIMLMD0
IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN
#2
IEC032I E37-04,IFG0554P,,APPLY,SGIMTENU,GIM.SGIMTENU
IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG
IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG
IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD
IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG
IEC031I D37-04,IFG0554P,,APPLY,SHASMIG,SYS1.SHASMIG
IOEZ00312I Dynamic growth of aggregate xxxxx.SIZUUSRD in progress
#3
Made an error during increase of data sets, ended up restoring everything and increasing (joblogs from before restore not saved)
SCBDMENU
SMPSTS 16->50 trks, sec 5
SASMMOD1 50->80 trks
#4
Accept of previous maintenance:
IEC032I E37-04,IFG0554P,,ACCEPT,ABBLLIB,BBL.ABBLLIB
Apply new:
IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB
IEC031I D37-04,IFG0554P,,APPLY,SICELINK,SYS1.SICELINK
#5
Accept of previous maintenance:
IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU
IEC032I E37-04,IFG0554P,,ACCEPT,AERBPWSV,SYS1.AERBPWSV
IEC032I E37-04,IFG0554P,,ACCEPT,AHAPINC3,HAP.AHAPINC3
IEC032I E37-04,IFG0554P,,ACCEPT,AGIMTENU,GIM.AGIMTENU
Apply new:
IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV
IEC032I E37-04,IFG0554P,,APPLY,SEEQINST,SYS1.SEEQINST
IEC031I D37-04,IFG0554P,,APPLY,MIGLIB,SYS1.MIGLIB
IEC031I D37-04,IFG0554P,,APPLY,SCSFMOD0,CSF.SCSFMOD0
IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD
IEC031I D37-04,IFG0554P,,APPLY,SCEERUN,CEE.SCEERUN
#6
IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK
IEC031I D37-04,IFG0554P,,APPLY,CMDLIB,SYS1.CMDLIB
IEC031I D37-04,IFG0554P,,APPLY,LINKLIB,SYS1.LINKLIB
IEC031I D37-04,IFG0554P,,APPLY,NUCLEUS,SYS1.NUCLEUS
IEC031I D37-04,IFG0554P,,APPLY,SASMMOD1,ASM.SASMMOD1
#7
IEC032I E37-04,IFG0554P,,APPLY,SISFTLIB,ISF.SISFTLIB
IEC032I E37-04,IFG0554P,,APPLY,SERBPWSV,SYS1.SERBPWSV
IOEZ00312I Dynamic growth of aggregate xxxxx.SAZFAMOD in progress
IEC031I D37-04,IFG0554P,,APPLY,SERBLINK,SYS1.SERBLINK
IEC031I D37-04,IFG0554P,,APPLY,SISFLOAD,ISF.SISFLOAD
IEC032I E37-04,IFG0554P,,APPLY,SCEELPA,CEE.SCEELPA
#8
Accept of previous maintenance:
IEC032I E37-04,IFG0554P,1,ACCEPT,AGIMTENU,GIM.AGIMTENU
IEC032I E37-04,IFG0554P,1,ACCEPT,AISFTLIB,ISF.AISFTLIB
IEC032I E37-04,IFG0554P,1,ACCEPT,AAZFAMOD,AZF.AAZFAMOD
IEC032I E37-04,IFG0554P,1,ACCEPT,AHAPINC3,HAP.AHAPINC3
Apply new:
IEC031I D37-04,IFG0554P,,APPLY,DGTLLIB,SYS1.DGTLLIB
With z/OS 2.5, I'll probably triple allocations for those data sets during allocation.
>That being said, my cloning process copies my res volume and ZFS datasets to new volumes and resets extents to current used, which is why I never used the software deployment and NEVER will in z/OSMF.
Right now the plan is for my successor to install z/OSMF once we're on 2.5. *I* will certainly NEVER use z/OSMF to do the rollout to all the other sysplexes. Cloning is done in 4 jobs and they work and are easily controlled.
Regards, Barbara
Carmen Vitullo
Jul 23, 2021, 8:06:55 AM7/23/21
to
Barb, how did you get my apply and accept sysouts :)
joking aside, these datasets are the same datasets I've always had space
issues with or I needed to up the directory size, go thru the pain of
allocating a .NEW datasets larger, or with more directories or both,
copy the failed library to the new one, rename, delete.....rerun only to
get a D37 on another dataset :(
other issues I've had was the SMPWRKx datasets are ALWAYS under allocated
Carmen
joking aside, these datasets are the same datasets I've always had space
issues with or I needed to up the directory size, go thru the pain of
allocating a .NEW datasets larger, or with more directories or both,
copy the failed library to the new one, rename, delete.....rerun only to
get a D37 on another dataset :(
other issues I've had was the SMPWRKx datasets are ALWAYS under allocated
Carmen
--
/I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
/I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
Richards, Robert B. , CTR
Jul 23, 2021, 8:26:16 AM7/23/21
to
For SMPWRKx datasets, see SYS1.SAMPLIB(GIMDDALC). Turn it into a usermod:
++USERMOD(SMP1K1) REWORK(2021204).
++VER(Z038) FMID(HMP1K00) .
++SAMP(GIMDDALC) DISTLIB(ASAMPLIB) .
Contents of GIMDDALC pasted here with your changes.
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Carmen Vitullo
Sent: Friday, July 23, 2021 8:06 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests
++USERMOD(SMP1K1) REWORK(2021204).
++VER(Z038) FMID(HMP1K00) .
++SAMP(GIMDDALC) DISTLIB(ASAMPLIB) .
Contents of GIMDDALC pasted here with your changes.
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Carmen Vitullo
Sent: Friday, July 23, 2021 8:06 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests
Carmen Vitullo
Jul 23, 2021, 8:49:09 AM7/23/21
to
Nice! thanks Bob
Carmen Vitullo
-----Original Message-----
Carmen Vitullo
-----Original Message-----
Steve Smith
Jul 23, 2021, 1:43:28 PM7/23/21
to
A USERMOD is overkill. SMP/E parmlib is specified in the JCL, so just
create your own and use it.
That's what I do. But if you really want to have a usermod, I don't mind.
sas
On Fri, Jul 23, 2021 at 8:26 AM Richards, Robert B. (CTR) <
000001c91f408b9...@listserv.ua.edu> wrote:
> For SMPWRKx datasets, see SYS1.SAMPLIB(GIMDDALC). Turn it into a usermod:
>
> ++USERMOD(SMP1K1) REWORK(2021204).
> ++VER(Z038) FMID(HMP1K00) .
> ++SAMP(GIMDDALC) DISTLIB(ASAMPLIB) .
> Contents of GIMDDALC pasted here with your changes.
>
>
create your own and use it.
That's what I do. But if you really want to have a usermod, I don't mind.
sas
On Fri, Jul 23, 2021 at 8:26 AM Richards, Robert B. (CTR) <
000001c91f408b9...@listserv.ua.edu> wrote:
> For SMPWRKx datasets, see SYS1.SAMPLIB(GIMDDALC). Turn it into a usermod:
>
> ++USERMOD(SMP1K1) REWORK(2021204).
> ++VER(Z038) FMID(HMP1K00) .
> ++SAMP(GIMDDALC) DISTLIB(ASAMPLIB) .
> Contents of GIMDDALC pasted here with your changes.
>
>
Marna WALLE
Jul 23, 2021, 4:24:20 PM7/23/21
to
Brian,
Might there be a conversion error to XML? Yes, of course that is possible. But that is why we have my second comment below...
>> People won't have much time between Late September and January to discover and correct all of the bugs.
For each z/OS new release, and V2.5 more than ever, there are early customer programs. The release level early program for z/OS V2.5 has its main focus on the installation of and upgrade to z/OS V2.5. We understood that the installation process would be different and wanted as much exposure, testing, and validation in customer environments before it GAs. We have early customers that represent many different industries and geographies. Each of these customers has installed with a z/OS V2.5 z/OSMF ServerPac. Not a single one of them used the old ISPF ServerPac.
-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie
>> Some of the problem here is that you are telling me what "will" be there, but I don't have anything that actually shows that or even implies it for z/OSMF for z/OS. I don't even have the workflows to verify anything.
For the z/OS Workflows that you haven't seen yet, they are Workflow steps that are submitting the same JCL jobs that you used to submit through the ISPF interface and should be familiar with today. Meaning, instead of using an ISPF panel to submit the job, you will now submit those same jobs from the z/OSMF Workflow interface. That is the difference. The jobs remain the same, in probably 99.99% of the cases. They are being converted from ISPF JCL skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, you haven't seen them in their XML format, but you certainly have seen them when they were JCL skeletons. And remember, every single Workflow step JCL that is submitted is able to be edited from z/OSMF, just like it was with the CustomPac dialog.
Might there be a conversion error to XML? Yes, of course that is possible. But that is why we have my second comment below...
>> People won't have much time between Late September and January to discover and correct all of the bugs.
-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie
Brian Westerman
Jul 24, 2021, 12:21:22 AM7/24/21
to
Did you think to have even ONE of those early sites be one with a small processor (single CPU) like a low end single CPU z/13, z14 or z15? Most likely you didn't and that's very sad. A good percentage of "new" clients that IBM has added over the past 5 to 8 years are in that boat and IBM has decided to set sail without them.
I have no doubt that the early customers represented vast swaths of geographies and industries, but how low did you guys dip to test with a "small" site. The ones IBM called strategic so that they would not go to Open Systems and instead go with a small box and z/OS?
It's very disappointing. Not all of the people IBM is ignoring have access to large and small boxes like I do, if you have a small box and want to upgrade after January to 2.5 from say 2.3, they will not be able to do it without beefing up their machine or coming to someone like us to do it for them. I'm not complaining about the business that IBM is pushing my way, but I think it's sad that IBM appears to care very little about the damage (via frustration) they are about to do. Some will buy an upgraded box, but many will simply drop their mainframe path in favor of some other direction (away from z/OS).
Brian
I have no doubt that the early customers represented vast swaths of geographies and industries, but how low did you guys dip to test with a "small" site. The ones IBM called strategic so that they would not go to Open Systems and instead go with a small box and z/OS?
It's very disappointing. Not all of the people IBM is ignoring have access to large and small boxes like I do, if you have a small box and want to upgrade after January to 2.5 from say 2.3, they will not be able to do it without beefing up their machine or coming to someone like us to do it for them. I'm not complaining about the business that IBM is pushing my way, but I think it's sad that IBM appears to care very little about the damage (via frustration) they are about to do. Some will buy an upgraded box, but many will simply drop their mainframe path in favor of some other direction (away from z/OS).
Brian
kekronbekron
Jul 24, 2021, 1:42:14 AM7/24/21
to
And therein begins a new line where some company offers services to move small machine workloads to zPDT.
Or whatever...
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, July 24th, 2021 at 9:51 AM, Brian Westerman <Brian_W...@SYZYGYINC.COM> wrote:
> Did you think to have even ONE of those early sites be one with a small processor (single CPU) like a low end single CPU z/13, z14 or z15? Most likely you didn't and that's very sad. A good percentage of "new" clients that IBM has added over the past 5 to 8 years are in that boat and IBM has decided to set sail without them.
>
> I have no doubt that the early customers represented vast swaths of geographies and industries, but how low did you guys dip to test with a "small" site. The ones IBM called strategic so that they would not go to Open Systems and instead go with a small box and z/OS?
>
> It's very disappointing. Not all of the people IBM is ignoring have access to large and small boxes like I do, if you have a small box and want to upgrade after January to 2.5 from say 2.3, they will not be able to do it without beefing up their machine or coming to someone like us to do it for them. I'm not complaining about the business that IBM is pushing my way, but I think it's sad that IBM appears to care very little about the damage (via frustration) they are about to do. Some will buy an upgraded box, but many will simply drop their mainframe path in favor of some other direction (away from z/OS).
>
> Brian
>
> On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE mwa...@US.IBM.COM wrote:
>
> > Brian,
> >
> > > > Some of the problem here is that you are telling me what "will" be there, but I don't have anything that actually shows that or even implies it for z/OSMF for z/OS. I don't even have the workflows to verify anything.
> >
> > For the z/OS Workflows that you haven't seen yet, they are Workflow steps that are submitting the same JCL jobs that you used to submit through the ISPF interface and should be familiar with today. Meaning, instead of using an ISPF panel to submit the job, you will now submit those same jobs from the z/OSMF Workflow interface. That is the difference. The jobs remain the same, in probably 99.99% of the cases. They are being converted from ISPF JCL skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, you haven't seen them in their XML format, but you certainly have seen them when they were JCL skeletons. And remember, every single Workflow step JCL that is submitted is able to be edited from z/OSMF, just like it was with the CustomPac dialog.
> >
> > Might there be a conversion error to XML? Yes, of course that is possible. But that is why we have my second comment below...
> >
> > > > People won't have much time between Late September and January to discover and correct all of the bugs.
> >
> > For each z/OS new release, and V2.5 more than ever, there are early customer programs. The release level early program for z/OS V2.5 has its main focus on the installation of and upgrade to z/OS V2.5. We understood that the installation process would be different and wanted as much exposure, testing, and validation in customer environments before it GAs. We have early customers that represent many different industries and geographies. Each of these customers has installed with a z/OS V2.5 z/OSMF ServerPac. Not a single one of them used the old ISPF ServerPac.
> >
> > -Marna WALLE
> >
> > z/OS System Install and Upgrade
> >
> > IBM Poughkeepsie
> >
Or whatever...
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, July 24th, 2021 at 9:51 AM, Brian Westerman <Brian_W...@SYZYGYINC.COM> wrote:
> Did you think to have even ONE of those early sites be one with a small processor (single CPU) like a low end single CPU z/13, z14 or z15? Most likely you didn't and that's very sad. A good percentage of "new" clients that IBM has added over the past 5 to 8 years are in that boat and IBM has decided to set sail without them.
>
> I have no doubt that the early customers represented vast swaths of geographies and industries, but how low did you guys dip to test with a "small" site. The ones IBM called strategic so that they would not go to Open Systems and instead go with a small box and z/OS?
>
> It's very disappointing. Not all of the people IBM is ignoring have access to large and small boxes like I do, if you have a small box and want to upgrade after January to 2.5 from say 2.3, they will not be able to do it without beefing up their machine or coming to someone like us to do it for them. I'm not complaining about the business that IBM is pushing my way, but I think it's sad that IBM appears to care very little about the damage (via frustration) they are about to do. Some will buy an upgraded box, but many will simply drop their mainframe path in favor of some other direction (away from z/OS).
>
> Brian
>
> On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE mwa...@US.IBM.COM wrote:
>
> > Brian,
> >
> > > > Some of the problem here is that you are telling me what "will" be there, but I don't have anything that actually shows that or even implies it for z/OSMF for z/OS. I don't even have the workflows to verify anything.
> >
> > For the z/OS Workflows that you haven't seen yet, they are Workflow steps that are submitting the same JCL jobs that you used to submit through the ISPF interface and should be familiar with today. Meaning, instead of using an ISPF panel to submit the job, you will now submit those same jobs from the z/OSMF Workflow interface. That is the difference. The jobs remain the same, in probably 99.99% of the cases. They are being converted from ISPF JCL skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, you haven't seen them in their XML format, but you certainly have seen them when they were JCL skeletons. And remember, every single Workflow step JCL that is submitted is able to be edited from z/OSMF, just like it was with the CustomPac dialog.
> >
> > Might there be a conversion error to XML? Yes, of course that is possible. But that is why we have my second comment below...
> >
> > > > People won't have much time between Late September and January to discover and correct all of the bugs.
> >
> > For each z/OS new release, and V2.5 more than ever, there are early customer programs. The release level early program for z/OS V2.5 has its main focus on the installation of and upgrade to z/OS V2.5. We understood that the installation process would be different and wanted as much exposure, testing, and validation in customer environments before it GAs. We have early customers that represent many different industries and geographies. Each of these customers has installed with a z/OS V2.5 z/OSMF ServerPac. Not a single one of them used the old ISPF ServerPac.
> >
> > -Marna WALLE
> >
> > z/OS System Install and Upgrade
> >
> > IBM Poughkeepsie
> >
Clark Morris
Jul 24, 2021, 11:20:18 AM7/24/21
to
[Default] On 23 Jul 2021 21:21:19 -0700, in bit.listserv.ibm-main
reported that the current COBOL compile takes significantly more
resources. Since IBM is moving to common compiler backends, has this
become a problem for small shops?
Clark Morris
Brian_W...@SYZYGYINC.COM (Brian Westerman) wrote:
>Did you think to have even ONE of those early sites be one with a small processor (single CPU) like a low end single CPU z/13, z14 or z15? Most likely you didn't and that's very sad. A good percentage of "new" clients that IBM has added over the past 5 to 8 years are in that boat and IBM has decided to set sail without them.
In addition to the resource use by z/OSMF, at the last SHARE Tom Ross
>Did you think to have even ONE of those early sites be one with a small processor (single CPU) like a low end single CPU z/13, z14 or z15? Most likely you didn't and that's very sad. A good percentage of "new" clients that IBM has added over the past 5 to 8 years are in that boat and IBM has decided to set sail without them.
reported that the current COBOL compile takes significantly more
resources. Since IBM is moving to common compiler backends, has this
become a problem for small shops?
Clark Morris
Brian Westerman
Jul 25, 2021, 12:55:01 AM7/25/21
to
Unfortunately, you can't run a production system on a zPDT, it's not allowed under the agreement with IBM.
On Sat, 24 Jul 2021 05:41:56 +0000, kekronbekron <kekron...@PROTONMAIL.COM> wrote:
>And therein begins a new line where some company offers services to move small machine workloads to zPDT.
>Or whatever...
>
>- KB
>
>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
On Sat, 24 Jul 2021 05:41:56 +0000, kekronbekron <kekron...@PROTONMAIL.COM> wrote:
>And therein begins a new line where some company offers services to move small machine workloads to zPDT.
>Or whatever...
>
>- KB
>
>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
>On Saturday, July 24th, 2021 at 9:51 AM, Brian Westerman <Brian_W...@SYZYGYINC.COM> wrote:
>
>> Did you think to have even ONE of those early sites be one with a small processor (single CPU) like a low end single CPU z/13, z14 or z15? Most likely you didn't and that's very sad. A good percentage of "new" clients that IBM has added over the past 5 to 8 years are in that boat and IBM has decided to set sail without them.
>>
>
>> Did you think to have even ONE of those early sites be one with a small processor (single CPU) like a low end single CPU z/13, z14 or z15? Most likely you didn't and that's very sad. A good percentage of "new" clients that IBM has added over the past 5 to 8 years are in that boat and IBM has decided to set sail without them.
>>
>> I have no doubt that the early customers represented vast swaths of geographies and industries, but how low did you guys dip to test with a "small" site. The ones IBM called strategic so that they would not go to Open Systems and instead go with a small box and z/OS?
>>
>> It's very disappointing. Not all of the people IBM is ignoring have access to large and small boxes like I do, if you have a small box and want to upgrade after January to 2.5 from say 2.3, they will not be able to do it without beefing up their machine or coming to someone like us to do it for them. I'm not complaining about the business that IBM is pushing my way, but I think it's sad that IBM appears to care very little about the damage (via frustration) they are about to do. Some will buy an upgraded box, but many will simply drop their mainframe path in favor of some other direction (away from z/OS).
>>
>> Brian
>>
>> On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE mwa...@US.IBM.COM wrote:
>>
>> > Brian,
>> >
>> > > > Some of the problem here is that you are telling me what "will" be there, but I don't have anything that actually shows that or even implies it for z/OSMF for z/OS. I don't even have the workflows to verify anything.
>> >
>> > For the z/OS Workflows that you haven't seen yet, they are Workflow steps that are submitting the same JCL jobs that you used to submit through the ISPF interface and should be familiar with today. Meaning, instead of using an ISPF panel to submit the job, you will now submit those same jobs from the z/OSMF Workflow interface. That is the difference. The jobs remain the same, in probably 99.99% of the cases. They are being converted from ISPF JCL skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, you haven't seen them in their XML format, but you certainly have seen them when they were JCL skeletons. And remember, every single Workflow step JCL that is submitted is able to be edited from z/OSMF, just like it was with the CustomPac dialog.
>> >
>> > Might there be a conversion error to XML? Yes, of course that is possible. But that is why we have my second comment below...
>> >
>> > > > People won't have much time between Late September and January to discover and correct all of the bugs.
>> >
>> > For each z/OS new release, and V2.5 more than ever, there are early customer programs. The release level early program for z/OS V2.5 has its main focus on the installation of and upgrade to z/OS V2.5. We understood that the installation process would be different and wanted as much exposure, testing, and validation in customer environments before it GAs. We have early customers that represent many different industries and geographies. Each of these customers has installed with a z/OS V2.5 z/OSMF ServerPac. Not a single one of them used the old ISPF ServerPac.
>> >
>> > -Marna WALLE
>> >
>> > z/OS System Install and Upgrade
>> >
>> > IBM Poughkeepsie
>> >
>>
>> It's very disappointing. Not all of the people IBM is ignoring have access to large and small boxes like I do, if you have a small box and want to upgrade after January to 2.5 from say 2.3, they will not be able to do it without beefing up their machine or coming to someone like us to do it for them. I'm not complaining about the business that IBM is pushing my way, but I think it's sad that IBM appears to care very little about the damage (via frustration) they are about to do. Some will buy an upgraded box, but many will simply drop their mainframe path in favor of some other direction (away from z/OS).
>>
>> Brian
>>
>> On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE mwa...@US.IBM.COM wrote:
>>
>> > Brian,
>> >
>> > > > Some of the problem here is that you are telling me what "will" be there, but I don't have anything that actually shows that or even implies it for z/OSMF for z/OS. I don't even have the workflows to verify anything.
>> >
>> > For the z/OS Workflows that you haven't seen yet, they are Workflow steps that are submitting the same JCL jobs that you used to submit through the ISPF interface and should be familiar with today. Meaning, instead of using an ISPF panel to submit the job, you will now submit those same jobs from the z/OSMF Workflow interface. That is the difference. The jobs remain the same, in probably 99.99% of the cases. They are being converted from ISPF JCL skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, you haven't seen them in their XML format, but you certainly have seen them when they were JCL skeletons. And remember, every single Workflow step JCL that is submitted is able to be edited from z/OSMF, just like it was with the CustomPac dialog.
>> >
>> > Might there be a conversion error to XML? Yes, of course that is possible. But that is why we have my second comment below...
>> >
>> > > > People won't have much time between Late September and January to discover and correct all of the bugs.
>> >
>> > For each z/OS new release, and V2.5 more than ever, there are early customer programs. The release level early program for z/OS V2.5 has its main focus on the installation of and upgrade to z/OS V2.5. We understood that the installation process would be different and wanted as much exposure, testing, and validation in customer environments before it GAs. We have early customers that represent many different industries and geographies. Each of these customers has installed with a z/OS V2.5 z/OSMF ServerPac. Not a single one of them used the old ISPF ServerPac.
>> >
>> > -Marna WALLE
>> >
>> > z/OS System Install and Upgrade
>> >
>> > IBM Poughkeepsie
>> >
Brian Westerman
Jul 25, 2021, 12:57:53 AM7/25/21
to
Not really, the smaller the shop, the less programmers they have performing compiles, even if it takes 4 to 5 times as long to compile LE COBOL compared to something like COBOL-II, there are not enough of them to really matter. A large shop wouldn't see that same problem, because while the compile times have gotten higher, the normally have the capacity to handle it, or at least handle it better.
Brian
On Sat, 24 Jul 2021 12:19:58 -0300, Clark Morris <cfm...@UNISERVE.COM> wrote:
>[Default] On 23 Jul 2021 21:21:19 -0700, in bit.listserv.ibm-main
Brian
On Sat, 24 Jul 2021 12:19:58 -0300, Clark Morris <cfm...@UNISERVE.COM> wrote:
>[Default] On 23 Jul 2021 21:21:19 -0700, in bit.listserv.ibm-main
>Brian_W...@SYZYGYINC.COM (Brian Westerman) wrote:
>
>>Did you think to have even ONE of those early sites be one with a small processor (single CPU) like a low end single CPU z/13, z14 or z15? Most likely you didn't and that's very sad. A good percentage of "new" clients that IBM has added over the past 5 to 8 years are in that boat and IBM has decided to set sail without them.
>
>
>>Did you think to have even ONE of those early sites be one with a small processor (single CPU) like a low end single CPU z/13, z14 or z15? Most likely you didn't and that's very sad. A good percentage of "new" clients that IBM has added over the past 5 to 8 years are in that boat and IBM has decided to set sail without them.
>
>In addition to the resource use by z/OSMF, at the last SHARE Tom Ross
>reported that the current COBOL compile takes significantly more
>resources. Since IBM is moving to common compiler backends, has this
>become a problem for small shops?
>
>Clark Morris
>>
>reported that the current COBOL compile takes significantly more
>resources. Since IBM is moving to common compiler backends, has this
>become a problem for small shops?
>
>Clark Morris
>>
>>I have no doubt that the early customers represented vast swaths of geographies and industries, but how low did you guys dip to test with a "small" site. The ones IBM called strategic so that they would not go to Open Systems and instead go with a small box and z/OS?
>>
>>It's very disappointing. Not all of the people IBM is ignoring have access to large and small boxes like I do, if you have a small box and want to upgrade after January to 2.5 from say 2.3, they will not be able to do it without beefing up their machine or coming to someone like us to do it for them. I'm not complaining about the business that IBM is pushing my way, but I think it's sad that IBM appears to care very little about the damage (via frustration) they are about to do. Some will buy an upgraded box, but many will simply drop their mainframe path in favor of some other direction (away from z/OS).
>>
>>Brian
>>
>>
>>On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE <mwa...@US.IBM.COM> wrote:
>>
>>>Brian,
>>>>> Some of the problem here is that you are telling me what "will" be there, but I don't have anything that actually shows that or even implies it for z/OSMF for z/OS. I don't even have the workflows to verify anything.
>>>
>>>For the z/OS Workflows that you haven't seen yet, they are Workflow steps that are submitting the same JCL jobs that you used to submit through the ISPF interface and should be familiar with today. Meaning, instead of using an ISPF panel to submit the job, you will now submit those same jobs from the z/OSMF Workflow interface. That is the difference. The jobs remain the same, in probably 99.99% of the cases. They are being converted from ISPF JCL skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, you haven't seen them in their XML format, but you certainly have seen them when they were JCL skeletons. And remember, every single Workflow step JCL that is submitted is able to be edited from z/OSMF, just like it was with the CustomPac dialog.
>>>
>>>Might there be a conversion error to XML? Yes, of course that is possible. But that is why we have my second comment below...
>>>
>>>
>>>>> People won't have much time between Late September and January to discover and correct all of the bugs.
>>>
>>>For each z/OS new release, and V2.5 more than ever, there are early customer programs. The release level early program for z/OS V2.5 has its main focus on the installation of and upgrade to z/OS V2.5. We understood that the installation process would be different and wanted as much exposure, testing, and validation in customer environments before it GAs. We have early customers that represent many different industries and geographies. Each of these customers has installed with a z/OS V2.5 z/OSMF ServerPac. Not a single one of them used the old ISPF ServerPac.
>>>
>>>-Marna WALLE
>>>z/OS System Install and Upgrade
>>>IBM Poughkeepsie
>>>
>>
>>It's very disappointing. Not all of the people IBM is ignoring have access to large and small boxes like I do, if you have a small box and want to upgrade after January to 2.5 from say 2.3, they will not be able to do it without beefing up their machine or coming to someone like us to do it for them. I'm not complaining about the business that IBM is pushing my way, but I think it's sad that IBM appears to care very little about the damage (via frustration) they are about to do. Some will buy an upgraded box, but many will simply drop their mainframe path in favor of some other direction (away from z/OS).
>>
>>Brian
>>
>>
>>On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE <mwa...@US.IBM.COM> wrote:
>>
>>>Brian,
>>>>> Some of the problem here is that you are telling me what "will" be there, but I don't have anything that actually shows that or even implies it for z/OSMF for z/OS. I don't even have the workflows to verify anything.
>>>
>>>For the z/OS Workflows that you haven't seen yet, they are Workflow steps that are submitting the same JCL jobs that you used to submit through the ISPF interface and should be familiar with today. Meaning, instead of using an ISPF panel to submit the job, you will now submit those same jobs from the z/OSMF Workflow interface. That is the difference. The jobs remain the same, in probably 99.99% of the cases. They are being converted from ISPF JCL skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, you haven't seen them in their XML format, but you certainly have seen them when they were JCL skeletons. And remember, every single Workflow step JCL that is submitted is able to be edited from z/OSMF, just like it was with the CustomPac dialog.
>>>
>>>Might there be a conversion error to XML? Yes, of course that is possible. But that is why we have my second comment below...
>>>
>>>
>>>>> People won't have much time between Late September and January to discover and correct all of the bugs.
>>>
>>>For each z/OS new release, and V2.5 more than ever, there are early customer programs. The release level early program for z/OS V2.5 has its main focus on the installation of and upgrade to z/OS V2.5. We understood that the installation process would be different and wanted as much exposure, testing, and validation in customer environments before it GAs. We have early customers that represent many different industries and geographies. Each of these customers has installed with a z/OS V2.5 z/OSMF ServerPac. Not a single one of them used the old ISPF ServerPac.
>>>
>>>-Marna WALLE
>>>z/OS System Install and Upgrade
>>>IBM Poughkeepsie
>>>
kekronbekron
Jul 25, 2021, 1:50:16 AM7/25/21
to
I realized as much.
However, that's one way for IBM to build a bridge.
zSMB or something.
Instead of leaving no option but to get out-of-support older machines (and h/w support from other companies), or getting more MSUs and such...
IBM could instead sell software-only small machine.
Comparing Mac Pro to a full-on z15, IBM could offer a Mac mini or Macbook Air.
Business class model will be more like MacBook Pro or something.
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
However, that's one way for IBM to build a bridge.
zSMB or something.
Instead of leaving no option but to get out-of-support older machines (and h/w support from other companies), or getting more MSUs and such...
IBM could instead sell software-only small machine.
Comparing Mac Pro to a full-on z15, IBM could offer a Mac mini or Macbook Air.
Business class model will be more like MacBook Pro or something.
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
Mike Schwab
Jul 25, 2021, 2:14:58 AM7/25/21
to
You can rent an account on a dallas (or other) center machine and run
real production.
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
real production.
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Ed Jaffe
Jul 25, 2021, 9:22:47 AM7/25/21
to
On 7/24/2021 11:14 PM, Mike Schwab wrote:
> You can rent an account on a dallas (or other) center machine and run
> real production.
https://assets.toolbox.com/research/make-your-mainframe-environment-more-agile-and-responsive-with-ibms-zcloud-47582
> You can rent an account on a dallas (or other) center machine and run
> real production.
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
Marna WALLE
Jul 25, 2021, 9:42:04 AM7/25/21
to
Brian,
Concerning small environments, does having z/OS (and z/OS V2.5) available to all participating ISVs count as part of our early programs? Whereby they could use z/OS V2.5 and z/OSMF in their own environment, or use it as a z/VM guest? Does it count that these same ISVs, who can run in their own very small environments on their own purchased HW, have had z/OSMF for quite a while and we've delivered PTFs to help with the performance in those environments because of their z/OSMF feedback? Does it count that any early customer in the z/OS V2.5 release program can and do have small sandbox systems, on which they perform their installation and service work? Does having the function testing for z/OS V2.5 across all the z/OS Development labs as z/VM guests count, with these environments sometimes being smaller than a zPDT?
I do understand that you are unhappy with the choice of using z/OSMF for z/OS V2.5 after Jan 2022. I'm not sure there's anymore I can offer. We have been moving in this direction for a very long time.
-Marna WALLE
z/OS System Installation and Upgrade
IBM Poughkeepsie
Concerning small environments, does having z/OS (and z/OS V2.5) available to all participating ISVs count as part of our early programs? Whereby they could use z/OS V2.5 and z/OSMF in their own environment, or use it as a z/VM guest? Does it count that these same ISVs, who can run in their own very small environments on their own purchased HW, have had z/OSMF for quite a while and we've delivered PTFs to help with the performance in those environments because of their z/OSMF feedback? Does it count that any early customer in the z/OS V2.5 release program can and do have small sandbox systems, on which they perform their installation and service work? Does having the function testing for z/OS V2.5 across all the z/OS Development labs as z/VM guests count, with these environments sometimes being smaller than a zPDT?
I do understand that you are unhappy with the choice of using z/OSMF for z/OS V2.5 after Jan 2022. I'm not sure there's anymore I can offer. We have been moving in this direction for a very long time.
-Marna WALLE
z/OS System Installation and Upgrade
IBM Poughkeepsie
Clark Morris
Jul 25, 2021, 11:56:28 AM7/25/21
to
[Default] On 25 Jul 2021 06:42:01 -0700, in bit.listserv.ibm-main
remember putting a zap on a console display module so that the default
was 1 not 100 when a display unit command was issued.. The result of
displaying 100 device statuses on a 1052 (deserving of the
sledgehammer award) bouncing ball console printer was painful. This
lasted from MVT well into MVS and was the subject of a requirement. If
it takes 300 concurrent threads to run the default of 100 qualifies
for being inappropriate. Also someone whose talent is improving
systems performance may be needed. I was the type of person who would
not have designed a good system but I could in many cases drastically
improve the performance of an existing systems, preferably in COBOL
although I did a speed up a couple of assembler programs.
Clark Morris
mwa...@US.IBM.COM (Marna WALLE) wrote:
>Brian,
>Concerning small environments, does having z/OS (and z/OS V2.5) available to all participating ISVs count as part of our early programs? Whereby they could use z/OS V2.5 and z/OSMF in their own environment, or use it as a z/VM guest? Does it count that these same ISVs, who can run in their own very small environments on their own purchased HW, have had z/OSMF for quite a while and we've delivered PTFs to help with the performance in those environments because of their z/OSMF feedback? Does it count that any early customer in the z/OS V2.5 release program can and do have small sandbox systems, on which they perform their installation and service work? Does having the function testing for z/OS V2.5 across all the z/OS Development labs as z/VM guests count, with these environments sometimes being smaller than a zPDT?
I am wondering if some of the problem is the inappropriate default. I
>Brian,
>Concerning small environments, does having z/OS (and z/OS V2.5) available to all participating ISVs count as part of our early programs? Whereby they could use z/OS V2.5 and z/OSMF in their own environment, or use it as a z/VM guest? Does it count that these same ISVs, who can run in their own very small environments on their own purchased HW, have had z/OSMF for quite a while and we've delivered PTFs to help with the performance in those environments because of their z/OSMF feedback? Does it count that any early customer in the z/OS V2.5 release program can and do have small sandbox systems, on which they perform their installation and service work? Does having the function testing for z/OS V2.5 across all the z/OS Development labs as z/VM guests count, with these environments sometimes being smaller than a zPDT?
remember putting a zap on a console display module so that the default
was 1 not 100 when a display unit command was issued.. The result of
displaying 100 device statuses on a 1052 (deserving of the
sledgehammer award) bouncing ball console printer was painful. This
lasted from MVT well into MVS and was the subject of a requirement. If
it takes 300 concurrent threads to run the default of 100 qualifies
for being inappropriate. Also someone whose talent is improving
systems performance may be needed. I was the type of person who would
not have designed a good system but I could in many cases drastically
improve the performance of an existing systems, preferably in COBOL
although I did a speed up a couple of assembler programs.
Clark Morris
Colin Paice
Jul 25, 2021, 2:19:56 PM7/25/21
to
This might get more interest if they called it rent a system, rather than
cloud. Cloud has many negative images for z/OS people.
cloud. Cloud has many negative images for z/OS people.
Seymour J Metz
Jul 25, 2021, 5:56:39 PM7/25/21
to
Did you ever see a 1052-7, or even a 3210, on an MVS system? Admiitedly the D U message flood is a nuisance even on a 3270, but every shop that I saw used 3066 and 3270 for consoles, with hardcopy on syslog and no keyboard-printer consoles. Was anybody here on a S/370 that used a 3210 or 3215 as an MCS console?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Clark Morris [000003b2c618bdf...@LISTSERV.UA.EDU]
Sent: Sunday, July 25, 2021 11:56 AM
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Clark Morris [000003b2c618bdf...@LISTSERV.UA.EDU]
Sent: Sunday, July 25, 2021 11:56 AM
Andrew Rowley
Jul 25, 2021, 7:09:10 PM7/25/21
to
On 25/07/2021 11:41 pm, Marna WALLE wrote:
> Concerning small environments, does having z/OS (and z/OS V2.5) available to all participating ISVs count as part of our early programs? Whereby they could use z/OS V2.5 and z/OSMF in their own environment, or use it as a z/VM guest?
If you are comparing to the Dallas RDP systems, I would not call them
> Concerning small environments, does having z/OS (and z/OS V2.5) available to all participating ISVs count as part of our early programs? Whereby they could use z/OS V2.5 and z/OSMF in their own environment, or use it as a z/VM guest?
small. My Dallas system is about 20 times the capacity of the smallest
z15 IBM sells. The systems Brian has described also sound about 5% of
the capacity of the RDP system, and I have customers with production
workloads on similar systems.
By the LSPR ratings, the largest systems are well over 1000 times the
capacity of the smallest systems. That makes the smallest systems very,
very small. (Was system recovery boost created so you could start z/OSMF
on these small systems?)
--
Andrew Rowley
Black Hill Software
Clark Morris
Jul 25, 2021, 8:46:30 PM7/25/21
to
[Default] On 25 Jul 2021 14:56:33 -0700, in bit.listserv.ibm-main
our 4341.
Clark Morris
sme...@GMU.EDU (Seymour J Metz) wrote:
>Did you ever see a 1052-7, or even a 3210, on an MVS system? Admiitedly the D U message flood is a nuisance even on a 3270, but every shop that I saw used 3066 and 3270 for consoles, with hardcopy on syslog and no keyboard-printer consoles. Was anybody here on a S/370 that used a 3210 or 3215 as an MCS console?
This was a 1052 on a 360/65. As I recall we graduated to a 3287 on
>Did you ever see a 1052-7, or even a 3210, on an MVS system? Admiitedly the D U message flood is a nuisance even on a 3270, but every shop that I saw used 3066 and 3270 for consoles, with hardcopy on syslog and no keyboard-printer consoles. Was anybody here on a S/370 that used a 3210 or 3215 as an MCS console?
our 4341.
Clark Morris
Brian Westerman
Jul 26, 2021, 1:01:17 AM7/26/21
to
Running on a VM on a 400mip box doesn't count, no. The information provided to me was that the "smallest" box that had been tested by IBM is a 400+mip one, so the answer is "no", none of those count. I'm frankly kind of astonished that it never occurred to IBM to test on the smallest box they sell for z/OS use, one would think that would have occurred to "someone".
Working on something for a long time doesn't make it okay to provide only a 2 month "window" to install for those small sites. I still don't understand why IBM didn't just say that they will provide 2.5 with both installation methods and starting with the next release, move to z/OSMF only. It seems unrealistic to provide it for 3 months only.
On Sun, 25 Jul 2021 12:56:05 -0300, Clark Morris <cfm...@UNISERVE.COM> wrote:
>[Default] On 25 Jul 2021 06:42:01 -0700, in bit.listserv.ibm-main
>mwa...@US.IBM.COM (Marna WALLE) wrote:
>
>>Brian,
>>Concerning small environments, does having z/OS (and z/OS V2.5) available to all participating ISVs count as part of our early programs? Whereby they could use z/OS V2.5 and z/OSMF in their own environment, or use it as a z/VM guest? Does it count that these same ISVs, who can run in their own very small environments on their own purchased HW, have had z/OSMF for quite a while and we've delivered PTFs to help with the performance in those environments because of their z/OSMF feedback? Does it count that any early customer in the z/OS V2.5 release program can and do have small sandbox systems, on which they perform their installation and service work? Does having the function testing for z/OS V2.5 across all the z/OS Development labs as z/VM guests count, with these environments sometimes being smaller than a zPDT?
>
>I am wondering if some of the problem is the inappropriate default. I
>remember putting a zap on a console display module so that the default
>was 1 not 100 when a display unit command was issued.. The result of
>displaying 100 device statuses on a 1052 (deserving of the
>sledgehammer award) bouncing ball console printer was painful. This
>lasted from MVT well into MVS and was the subject of a requirement. If
>it takes 300 concurrent threads to run the default of 100 qualifies
>for being inappropriate. Also someone whose talent is improving
>systems performance may be needed. I was the type of person who would
>not have designed a good system but I could in many cases drastically
>improve the performance of an existing systems, preferably in COBOL
>although I did a speed up a couple of assembler programs.
>
>Clark Morris
>
>>
>>I do understand that you are unhappy with the choice of using z/OSMF for z/OS V2.5 after Jan 2022. I'm not sure there's anymore I can offer. We have been moving in this direction for a very long time.
>>
>>-Marna WALLE
>>z/OS System Installation and Upgrade
>>IBM Poughkeepsie
>>
Working on something for a long time doesn't make it okay to provide only a 2 month "window" to install for those small sites. I still don't understand why IBM didn't just say that they will provide 2.5 with both installation methods and starting with the next release, move to z/OSMF only. It seems unrealistic to provide it for 3 months only.
On Sun, 25 Jul 2021 12:56:05 -0300, Clark Morris <cfm...@UNISERVE.COM> wrote:
>[Default] On 25 Jul 2021 06:42:01 -0700, in bit.listserv.ibm-main
>mwa...@US.IBM.COM (Marna WALLE) wrote:
>
>>Brian,
>>Concerning small environments, does having z/OS (and z/OS V2.5) available to all participating ISVs count as part of our early programs? Whereby they could use z/OS V2.5 and z/OSMF in their own environment, or use it as a z/VM guest? Does it count that these same ISVs, who can run in their own very small environments on their own purchased HW, have had z/OSMF for quite a while and we've delivered PTFs to help with the performance in those environments because of their z/OSMF feedback? Does it count that any early customer in the z/OS V2.5 release program can and do have small sandbox systems, on which they perform their installation and service work? Does having the function testing for z/OS V2.5 across all the z/OS Development labs as z/VM guests count, with these environments sometimes being smaller than a zPDT?
>
>I am wondering if some of the problem is the inappropriate default. I
>remember putting a zap on a console display module so that the default
>was 1 not 100 when a display unit command was issued.. The result of
>displaying 100 device statuses on a 1052 (deserving of the
>sledgehammer award) bouncing ball console printer was painful. This
>lasted from MVT well into MVS and was the subject of a requirement. If
>it takes 300 concurrent threads to run the default of 100 qualifies
>for being inappropriate. Also someone whose talent is improving
>systems performance may be needed. I was the type of person who would
>not have designed a good system but I could in many cases drastically
>improve the performance of an existing systems, preferably in COBOL
>although I did a speed up a couple of assembler programs.
>
>Clark Morris
>
>>
>>I do understand that you are unhappy with the choice of using z/OSMF for z/OS V2.5 after Jan 2022. I'm not sure there's anymore I can offer. We have been moving in this direction for a very long time.
>>
>>-Marna WALLE
>>z/OS System Installation and Upgrade
>>IBM Poughkeepsie
>>
Ed Jaffe
Jul 26, 2021, 1:11:56 AM7/26/21
to
On 7/25/2021 10:01 PM, Brian Westerman wrote:
> Running on a VM on a 400mip box doesn't count, no. The information provided to me was that the "smallest" box that had been tested by IBM is a 400+mip one, so the answer is "no", none of those count. I'm frankly kind of astonished that it never occurred to IBM to test on the smallest box they sell for z/OS use, one would think that would have occurred to "someone".
z/OSMF has been used and tested extensively on zPDT and zD&T by various
> Running on a VM on a 400mip box doesn't count, no. The information provided to me was that the "smallest" box that had been tested by IBM is a 400+mip one, so the answer is "no", none of those count. I'm frankly kind of astonished that it never occurred to IBM to test on the smallest box they sell for z/OS use, one would think that would have occurred to "someone".
ISVs and others. One of z/OSMF's biggest proponents is Watson & Walker.
The last time I saw them live at SHARE, Frank Kyne mentioned at the
bottom of slide 40 of
https://watsonwalker.com/wp-content/uploads/2020/11/2020-09-100-Whats-New-in-Parmlib.pdf
that running ZFS inside OMVS took minutes off z/OSMF startup time on
their zPDT.
Until Frank mentioned it, I did not even know running ZFS that way was
an option...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
Seymour J Metz
Jul 26, 2021, 9:37:57 AM7/26/21
to
Lot's of OS/360 MVT systems used a 1052-7, but that's not MVS. Did you actually use the 3287 as a hardcopy console rather than for copying screens and for applications?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Clark Morris [000003b2c618bdf...@LISTSERV.UA.EDU]
Sent: Sunday, July 25, 2021 8:46 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: D U o a 1052 was Re: Serverpac installs January 2022 and beyond - Requests
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Clark Morris [000003b2c618bdf...@LISTSERV.UA.EDU]
To: IBM-...@LISTSERV.UA.EDU
Subject: D U o a 1052 was Re: Serverpac installs January 2022 and beyond - Requests
Carmen Vitullo
Jul 26, 2021, 10:01:32 AM7/26/21
to
I've never tried to run zfs under omvs, but it looks pretty straight forward, soemthing I'd need to test.
good doc here to help you set this up;
https://www.ibm.com/docs/en/zos/2.3.0?topic=zfs-installation-configuration-steps
Carmen Vitullo
-----Original Message-----
good doc here to help you set this up;
https://www.ibm.com/docs/en/zos/2.3.0?topic=zfs-installation-configuration-steps
Carmen Vitullo
-----Original Message-----
Ed Jaffe
Jul 26, 2021, 10:45:04 AM7/26/21
to
On 7/26/2021 7:01 AM, Carmen Vitullo wrote:
> I've never tried to run zfs under omvs, but it looks pretty straight forward, soemthing I'd need to test.
> good doc here to help you set this up;
>
> https://www.ibm.com/docs/en/zos/2.3.0?topic=zfs-installation-configuration-steps
We currently specify the following in BPXPRMxx:
> I've never tried to run zfs under omvs, but it looks pretty straight forward, soemthing I'd need to test.
> good doc here to help you set this up;
>
> https://www.ibm.com/docs/en/zos/2.3.0?topic=zfs-installation-configuration-steps
FILESYSTYPE TYPE(ZFS) ENTRYPOINT(IOEFSCM) ASNAME(ZFS,'SUB=MSTR')
It would appear all we need do is remove the ASNAME keyword from the
above specification to run zFS under OMVS.
We'll give that a try and see how our systems on the z15 run...
Carmen Vitullo
Jul 26, 2021, 10:48:25 AM7/26/21
to
thats my current setup also, and yes it appears all you need to do is
remove the ASNAME and viola !
I think you still need to make sure the IOEPRM DD is not in the PROC and
is only in the parmlib?
Carmen
On 7/26/2021 9:44 AM, Ed Jaffe wrote:
> On 7/26/2021 7:01 AM, Carmen Vitullo wrote:
>> I've never tried to run zfs under omvs, but it looks pretty straight
>> forward, soemthing I'd need to test.
>> good doc here to help you set this up;
>> https://www.ibm.com/docs/en/zos/2.3.0?topic=zfs-installation-configuration-steps
>
> We currently specify the following in BPXPRMxx:
>
> FILESYSTYPE TYPE(ZFS) ENTRYPOINT(IOEFSCM) ASNAME(ZFS,'SUB=MSTR')
>
> It would appear all we need do is remove the ASNAME keyword from the
> above specification to run zFS under OMVS.
>
> We'll give that a try and see how our systems on the z15 run...
>
--
remove the ASNAME and viola !
I think you still need to make sure the IOEPRM DD is not in the PROC and
is only in the parmlib?
Carmen
On 7/26/2021 9:44 AM, Ed Jaffe wrote:
> On 7/26/2021 7:01 AM, Carmen Vitullo wrote:
>> I've never tried to run zfs under omvs, but it looks pretty straight
>> forward, soemthing I'd need to test.
>> good doc here to help you set this up;
>> https://www.ibm.com/docs/en/zos/2.3.0?topic=zfs-installation-configuration-steps
>
> We currently specify the following in BPXPRMxx:
>
> FILESYSTYPE TYPE(ZFS) ENTRYPOINT(IOEFSCM) ASNAME(ZFS,'SUB=MSTR')
>
> It would appear all we need do is remove the ASNAME keyword from the
> above specification to run zFS under OMVS.
>
> We'll give that a try and see how our systems on the z15 run...
>
--
/I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
Carmen Vitullo
Jul 26, 2021, 10:51:15 AM7/26/21
to
also the recommendation if you do this;
Specify KERNELSTACKS(ABOVE) when zFS is running in the OMVS address space.
Carmen
Specify KERNELSTACKS(ABOVE) when zFS is running in the OMVS address space.
Carmen
Ed Jaffe
Jul 26, 2021, 11:00:46 AM7/26/21
to
On 7/26/2021 7:50 AM, Carmen Vitullo wrote:
> also the recommendation if you do this;
>
> Specify KERNELSTACKS(ABOVE) when zFS is running in the OMVS address
> space.
Haha! No kidding! You are way, Way, WAY behind the curve if you don't
> also the recommendation if you do this;
>
> Specify KERNELSTACKS(ABOVE) when zFS is running in the OMVS address
> space.
already have that specification... LOL
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
Carmen Vitullo
Jul 26, 2021, 11:06:04 AM7/26/21
to
I may be pointin out the obvious, but maybe not so obvious for all - ya
just never know
I know some folks on my team, so glad they don't subscribe here, that
will ask how to....I point to some doc, they read what they want, when
they get a failure or an error message they come back to me, I tell them
to RTFM again, thoroughly
:)
Carmen
On 7/26/2021 10:00 AM, Ed Jaffe wrote:
> On 7/26/2021 7:50 AM, Carmen Vitullo wrote:
>> also the recommendation if you do this;
>>
>> Specify KERNELSTACKS(ABOVE) when zFS is running in the OMVS address
>> space.
>
> Haha! No kidding! You are way, Way, WAY behind the curve if you don't
> already have that specification... LOL
>
>
--
just never know
I know some folks on my team, so glad they don't subscribe here, that
will ask how to....I point to some doc, they read what they want, when
they get a failure or an error message they come back to me, I tell them
to RTFM again, thoroughly
:)
Carmen
On 7/26/2021 10:00 AM, Ed Jaffe wrote:
> On 7/26/2021 7:50 AM, Carmen Vitullo wrote:
>> also the recommendation if you do this;
>>
>> Specify KERNELSTACKS(ABOVE) when zFS is running in the OMVS address
>> space.
>
> Haha! No kidding! You are way, Way, WAY behind the curve if you don't
> already have that specification... LOL
>
>
--
/I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
succeed, but I am bound to live by the light that I have. I must stand
with anybody that stands right, and stand with him while he is right,
and part with him when he goes wrong. *Abraham Lincoln*/
Colin Paice
Jul 26, 2021, 11:51:51 AM7/26/21
to
See Taking the brakes off ZFS on z/OS – move it to OMVS
<https://colinpaice.blog/2021/02/17/taking-the-brakes-off-zfs-on-z-os-move-it-to-omvs/>.
It is easy. I raised a doc comment saying it was not well documented.
<https://colinpaice.blog/2021/02/17/taking-the-brakes-off-zfs-on-z-os-move-it-to-omvs/>.
It is easy. I raised a doc comment saying it was not well documented.
John Abell
Jul 26, 2021, 11:59:19 AM7/26/21
to
I have been running with zfs for years now with no issues.
John T. Abell
Tel: 800-295-7608 Option 4
President
International: 1-416-593-5578 Option 4
E-mail: john....@intnlsoftwareproducts.com
Fax: 800-295-7609
International: 1-416-593-5579
International Software Products
www.ispinfo.com
This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception,
tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Colin Paice
Sent: Monday, July 26, 2021 11:51 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests
See Taking the brakes off ZFS on z/OS – move it to OMVS <https://colinpaice.blog/2021/02/17/taking-the-brakes-off-zfs-on-z-os-move-it-to-omvs/>.
It is easy. I raised a doc comment saying it was not well documented.
On Mon, 26 Jul 2021 at 15:01, Carmen Vitullo <cvit...@hughes.net> wrote:
> I've never tried to run zfs under omvs, but it looks pretty straight
> forward, soemthing I'd need to test.
> good doc here to help you set this up;
>
>
> https://www.ibm.com/docs/en/zos/2.3.0?topic=zfs-installation-configura
> tion-steps
>
>
> Carmen Vitullo
>
>
>
> -----Original Message-----
>
> From: Ed <edj...@PHOENIXSOFTWARE.COM>
> To: IBM-MAIN <IBM-...@LISTSERV.UA.EDU>
> Date: Monday, 26 July 2021 12:12 AM CDT
> Subject: Re: Serverpac installs January 2022 and beyond - Requests
>
> On 7/25/2021 10:01 PM, Brian Westerman wrote:
> > Running on a VM on a 400mip box doesn't count, no. The information
> provided to me was that the "smallest" box that had been tested by IBM
> is a
> 400+mip one, so the answer is "no", none of those count. I'm frankly
> 400+kind
John T. Abell
Tel: 800-295-7608 Option 4
President
International: 1-416-593-5578 Option 4
E-mail: john....@intnlsoftwareproducts.com
Fax: 800-295-7609
International: 1-416-593-5579
International Software Products
www.ispinfo.com
This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception,
tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Colin Paice
Sent: Monday, July 26, 2021 11:51 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests
See Taking the brakes off ZFS on z/OS – move it to OMVS <https://colinpaice.blog/2021/02/17/taking-the-brakes-off-zfs-on-z-os-move-it-to-omvs/>.
It is easy. I raised a doc comment saying it was not well documented.
On Mon, 26 Jul 2021 at 15:01, Carmen Vitullo <cvit...@hughes.net> wrote:
> I've never tried to run zfs under omvs, but it looks pretty straight
> forward, soemthing I'd need to test.
> good doc here to help you set this up;
>
>
> https://www.ibm.com/docs/en/zos/2.3.0?topic=zfs-installation-configura
> tion-steps
>
>
> Carmen Vitullo
>
>
>
> -----Original Message-----
>
> From: Ed <edj...@PHOENIXSOFTWARE.COM>
> To: IBM-MAIN <IBM-...@LISTSERV.UA.EDU>
> Date: Monday, 26 July 2021 12:12 AM CDT
> Subject: Re: Serverpac installs January 2022 and beyond - Requests
>
> On 7/25/2021 10:01 PM, Brian Westerman wrote:
> > Running on a VM on a 400mip box doesn't count, no. The information
> provided to me was that the "smallest" box that had been tested by IBM
> is a
> 400+mip one, so the answer is "no", none of those count. I'm frankly
Clark Morris
Jul 26, 2021, 3:29:35 PM7/26/21
to
[Default] On 26 Jul 2021 06:37:53 -0700, in bit.listserv.ibm-main
ball) version of the 1052 on our mod 30, 40 and 65 systems. With long
displays it quickly went down hill. I am fairly certain that the 3287
was our hardcopy device on MVS although at this late point I don't
recall how much console traffic was routed to it. Starting with MVT
we also printed SYSLOG to Fiche once a day.
sme...@GMU.EDU (Seymour J Metz) wrote:
>Lot's of OS/360 MVT systems used a 1052-7, but that's not MVS. Did you actually use the 3287 as a hardcopy console rather than for copying screens and for applications?
As I recall from around 40 years ago, we had the Selectric (bouncing
>Lot's of OS/360 MVT systems used a 1052-7, but that's not MVS. Did you actually use the 3287 as a hardcopy console rather than for copying screens and for applications?
ball) version of the 1052 on our mod 30, 40 and 65 systems. With long
displays it quickly went down hill. I am fairly certain that the 3287
was our hardcopy device on MVS although at this late point I don't
recall how much console traffic was routed to it. Starting with MVT
we also printed SYSLOG to Fiche once a day.
Seymour J Metz
Jul 26, 2021, 4:17:02 PM7/26/21
to
As I recall the only 1052 for use as a S/360 console was the 1052-7. I believe that the 3210 also used the "golfball" but that the 3215 and 3287 had dot matrix impact printers.
Having COM in those days sounds like luxury; I'm envious.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Clark Morris [000003b2c618bdf...@LISTSERV.UA.EDU]
Sent: Monday, July 26, 2021 3:29 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: D U o a 1052 was Re: Serverpac installs January 2022 and beyond - Requests
Having COM in those days sounds like luxury; I'm envious.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Clark Morris [000003b2c618bdf...@LISTSERV.UA.EDU]
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: D U o a 1052 was Re: Serverpac installs January 2022 and beyond - Requests
Clark Morris
Jul 26, 2021, 9:22:05 PM7/26/21
to
[Default] On 26 Jul 2021 13:16:58 -0700, in bit.listserv.ibm-main
HASP cancelled a job and that neither the night shift operator nor had
anything to do with it.
sme...@GMU.EDU (Seymour J Metz) wrote:
>As I recall the only 1052 for use as a S/360 console was the 1052-7. I believe that the 3210 also used the "golfball" but that the 3215 and 3287 had dot matrix impact printers.
>
>Having COM in those days sounds like luxury; I'm envious.
On one occasion, I used the fiche to show our operations manager that
>As I recall the only 1052 for use as a S/360 console was the 1052-7. I believe that the 3210 also used the "golfball" but that the 3215 and 3287 had dot matrix impact printers.
>
>Having COM in those days sounds like luxury; I'm envious.
HASP cancelled a job and that neither the night shift operator nor had
anything to do with it.
0 new messages