subject:"Serverpac installs January 2022 and beyond \- Requests"

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 toI 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*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-26 Thread Ed Jaffe


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



--
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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests


also the recommendation if you do this;

Specify KERNELSTACKS(ABOVE) when zFS is running in the OMVS address space.


Carmen


On 7/26/2021 9:48 AM, Carmen Vitullo wrote:
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...


--
/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*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

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...


--
/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*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-26 Thread Ed Jaffe


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...

--
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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

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-

From: Ed 
To: IBM-MAIN 
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 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 by various 
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. 

-- 
For IBM-MAIN subscribe / signoff / archive access instructions, 
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: D U o a 1052 was Re: Serverpac installs January 2022 and beyond - Requests

2021-07-26 Thread Seymour J Metz

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-MAIN@LISTSERV.UA.EDU] on behalf of 
Clark Morris [03b2c618bdfc-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, July 25, 2021 8:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: D U o a 1052 was Re: Serverpac installs January 2022 and beyond - 
Requests

[Default] On 25 Jul 2021 14:56:33 -0700, in bit.listserv.ibm-main
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
our 4341.

Clark Morris

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-25 Thread Ed Jaffe

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 by various
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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-25 Thread Brian Westerman

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  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
>>
>>--
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

D U o a 1052 was Re: Serverpac installs January 2022 and beyond - Requests

2021-07-25 Thread Clark Morris

[Default] On 25 Jul 2021 14:56:33 -0700, in bit.listserv.ibm-main
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
our 4341.

Clark Morris

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-25 Thread Andrew Rowley


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 
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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-25 Thread Seymour J Metz

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-MAIN@LISTSERV.UA.EDU] on behalf of 
Clark Morris [03b2c618bdfc-dmarc-requ...@listserv.ua.edu]
Sent: Sunday, July 25, 2021 11:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

[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
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-25 Thread Colin Paice

This might get more interest if they called it rent a system, rather than
cloud.  Cloud has many negative images for z/OS people.

On Sun, 25 Jul 2021 at 14:23, Ed Jaffe  wrote:

> 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
>
> --
> 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.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-25 Thread Clark Morris

[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
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-25 Thread Marna WALLE

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-25 Thread Ed Jaffe


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

--
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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-25 Thread Mike Schwab

You can rent an account on a dallas (or other) center machine and run
real production.

On Sun, Jul 25, 2021 at 12:50 AM kekronbekron
<02dee3fcae33-dmarc-requ...@listserv.ua.edu> wrote:
>
> 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 ‐‐‐
>
> On Sunday, July 25th, 2021 at 10:24 AM, Brian Westerman 
>  wrote:
>
> > 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 +, kekronbekron 
> > kekronbek...@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_wester...@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.
> > > >

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-24 Thread kekronbekron

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 ‐‐‐

On Sunday, July 25th, 2021 at 10:24 AM, Brian Westerman 
 wrote:

> 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 +, kekronbekron kekronbek...@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_wester...@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
> > > >
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > >
> > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > >
> > > send email to

Re: Excessive resource use was Re: Serverpac installs January 2022 and beyond - Requests

2021-07-24 Thread Brian Westerman

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  wrote:

>[Default] On 23 Jul 2021 21:21:19 -0700, in bit.listserv.ibm-main
>brian_wester...@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
>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  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
>>>
>>>--
>>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>--
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-24 Thread Brian Westerman

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 +, kekronbekron  
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 
> 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
>> >
>> > For IBM-MAIN subscribe / signoff / archive access instructions,
>> >
>> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Excessive resource use was Re: Serverpac installs January 2022 and beyond - Requests

2021-07-24 Thread Clark Morris

[Default] On 23 Jul 2021 21:21:19 -0700, in bit.listserv.ibm-main
brian_wester...@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
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  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
>>
>>--
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-23 Thread kekronbekron

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 
 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
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-23 Thread Brian Westerman

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  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
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-23 Thread Marna WALLE

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-23 Thread Steve Smith

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) <
01c91f408b9e-dmarc-requ...@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.
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-23 Thread Carmen Vitullo

Nice! thanks Bob  
  
   
Carmen Vitullo 

   

-Original Message-

From: Robert <01c91f408b9e-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN 
Date: Friday, 23 July 2021 7:26 AM CDT
Subject: Re: Serverpac installs January 2022 and beyond - Requests

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  On Behalf Of 
Carmen Vitullo 
Sent: Friday, July 23, 2021 8:06 AM 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Serverpac installs January 2022 and beyond - Requests 

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 

On 7/23/2021 3:27 AM, Barbara Nitz wrote: 
>> 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 x.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 x.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,AHAPI

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-23 Thread Richards, Robert B. (CTR)

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  On Behalf Of 
Carmen Vitullo
Sent: Friday, July 23, 2021 8:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

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

On 7/23/2021 3:27 AM, Barbara Nitz wrote:
>> 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 x.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 x.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 reset

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-23 Thread Carmen Vitullo


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

On 7/23/2021 3:27 AM, Barbara Nitz wrote:

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 x.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 x.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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
/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*/

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-23 Thread Barbara Nitz

>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 x.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 x.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

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-23 Thread Brian Westerman

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

On Thu, 22 Jul 2021 07:38:02 -0700, Tom Brennan  
wrote:

>"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.
>
>On 7/22/2021 7:19 AM, Carmen Vitullo wrote:
>> 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
>>
>>
>> On 7/21/2021 1:19 PM, Tom Brennan 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
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-22 Thread Gibney, Dave

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  On
> Behalf Of Tom Brennan
> Sent: Thursday, July 22, 2021 7:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Serverpac installs January 2022 and beyond - Requests
> 
> "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.
> 
> On 7/22/2021 7:19 AM, Carmen Vitullo wrote:
> > 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
> >
> >
> > On 7/21/2021 1:19 PM, Tom Brennan 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
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >>
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-22 Thread Shaffer, Terri

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.

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.

I also DEFRAG my RES volumes after an apply and with my 2 - MOD-27, have always 
had enough room, for my 2.2, 2.3 and 2.4 and hopefully for 2.5.  My z/OS 2.2, 
will be replaced in the SYSPLEX.

I apply around 1000 PTF each time, I do RSU upgrades normally twice a year over 
the life of a z/OS release and can say I might have had 10 datasets/ZFS 
expansion, I needed to expand during an APPLY.

This is the least of my concerns/issues for the serverpac.

I think, to say the Saved Config is out of date, is short sided and in 20 years 
I have always used it since serverpac gave me the MERGE and UPGRADE option.  
Fixed anything new to the Serverpac order and was ready to install in a short 
time.This saves SO MUCH TIME with installation as all I have to do verify, 
make very few updates and install.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Marna WALLE
Sent: Tuesday, July 20, 2021 12:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

External Email


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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@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.

--
For IBM-MAIN subscribe / signoff / archive acce

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-22 Thread Carmen Vitullo


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 Tx and Dx 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


On 7/22/2021 9:38 AM, Tom Brennan wrote:

"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.


On 7/22/2021 7:19 AM, Carmen Vitullo wrote:
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


On 7/21/2021 1:19 PM, Tom Brennan 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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
/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*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-22 Thread Tom Brennan


"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.


On 7/22/2021 7:19 AM, Carmen Vitullo wrote:
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


On 7/21/2021 1:19 PM, Tom Brennan 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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-22 Thread Carmen Vitullo

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


On 7/21/2021 1:19 PM, Tom Brennan 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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
/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*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-21 Thread Brian Westerman

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  
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
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-21 Thread Brian Westerman

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

On Wed, 21 Jul 2021 10:58:28 -0500, Marna WALLE  wrote:

>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 
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-21 Thread Tom Brennan

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.

On 7/21/2021 1:08 AM, Barbara Nitz wrote:

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.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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-21 Thread Tom Brennan

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


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-21 Thread Marna WALLE

Bruce,
Thank you!  This is very helpful for us to have!

-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-21 Thread Marna WALLE

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 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-21 Thread Seymour J Metz

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.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Ed 
Jaffe [edja...@phoenixsoftware.com]
Sent: Wednesday, July 21, 2021 12:50 AM
To: IBM-MAIN@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://secure-web.cisco.com/1Hth1sk0gAiJNGXf8lh5wlTQRsObUw1JzYjdrJbdv0J-FbGvYNwz0mSqfwBZF7GNrWKHF0ZTM5saAjqWfjWxDbMcyl1Mtn3zUebm6hWXC2rUPVCNPkxGpOiktm57reU-C2rq1QMVFiFf5Jh_bYAr1JeYkXrg2Z2GgWpZMwSu24qmV1TRQIFF85jFZ_SLFzo5-eCKoBFqF3pZolPMAX4_8rs9HB0FeSjt8TKxH8KPbgWgloGo3SBmDiDSsKaP21FRTy8UKbSwRdwwGasZPuhE4B3VoNHIUEiDDdLn3VF-guSqeYohTYxf4NigLsm9udsjMxNJLJt1DlUyrYPy8nonLZpDxgfQEskNkHd6AMvIfvbPVwXMLvGhvJlreN1Ms4ArmU45r7-ifMuJZ0ni0Xteo_1kVrbUHzmR2ugyv3N4t0dhVqT6l6aetGsbiDkblNKrr05jQI2gnSS8UYQioW1MnPg/https%3A%2F%2Fwww.phoenixsoftware.com%2F

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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-21 Thread Seymour J Metz

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-MAIN@LISTSERV.UA.EDU] on behalf of 
Brian Westerman [brian_wester...@syzygyinc.com]
Sent: Wednesday, July 21, 2021 1:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-21 Thread Barbara Nitz

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.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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-20 Thread Brian Westerman

Very good point.

Brian

On Tue, 20 Jul 2021 20:22:41 +, Seymour J Metz  wrote:

>Increasing the size is certainly important, but increasing the size of PDS 
>directories is absolutely crucial. Of course, in most cases letting them be 
>PDS/E would solve the issue.
>
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3
>
>
>From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>Marna WALLE [mwa...@us.ibm.com]
>Sent: Tuesday, July 20, 2021 1:47 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Serverpac installs January 2022 and beyond - Requests
>
>Hi Barbara (and others),
>Nice to see so many users of PDSEs!  We do not today have the capability to 
>switch from PDS to PDSE in z/OSMF, but we've got it in our backlog from 
>requests to have it.  If PDSEs users would like to help us prioritize that, 
>with their business impacts without this capability, please feel free to email 
>me (mwa...@us.ibm.com).
>
>As for the sizes, for z/OSMF ServerPac we have increased the shipped free 
>space to 40% per data set, and with linklst data sets have zero secondary.  
>This is an increase over the prior free space size we used to provide, in 
>hopes that will help for the time being.  This was done because we don't have 
>the ability to re-size today in z/OSMF.
>
>Now...I would like to look at the data set size problem in a larger context - 
>in order to understand where to solve this problem.  More than ever, we have 
>been shipping Continuous Delivery PTFs.  Many of these PTFs are quite large, 
>and occur over the life of a release.  This can put quite a lot of pressure on 
>the size of the target and DLIB data sets being able to accommodate these 
>updates for every service install episode.  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?  Meaning, installing a release for a first time - 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?
>
>-Marna WALLE
>z/OS System Install and Upgrade
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-20 Thread Brian Westerman

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

On Tue, 20 Jul 2021 12:47:54 -0500, Marna WALLE  wrote:

>Hi Barbara (and others),
>Nice to see so many users of PDSEs!  We do not today have the capability to 
>switch from PDS to PDSE in z/OSMF, but we've got it in our backlog from 
>requests to have it.  If PDSEs users would like to help us prioritize that, 
>with their business impacts without this capability, please feel free to email 
>me (mwa...@us.ibm.com).
>
>As for the sizes, for z/OSMF ServerPac we have increased the shipped free 
>space to 40% per data set, and with linklst data sets have zero secondary.  
>This is an increase over the prior free space size we used to provide, in 
>hopes that will help for the time being.  This was done because we don't have 
>the ability to re-size today in z/OSMF.  
>
>Now...I would like to look at the data set size problem in a larger context - 
>in order to understand where to solve this problem.  More than ever, we have 
>been shipping Continuous Delivery PTFs.  Many of these PTFs are quite large, 
>and occur over the life of a release.  This can put quite a lot of pressure on 
>the size of the target and DLIB data sets being able to accommodate these 
>updates for every service install episode.  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?  Meaning, installing a release for a first time - 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?
>
>-Marna WALLE
>z/OS System Install and Upgrade
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-20 Thread Bruce Hewson

Hello Marna,

I use:-

Rules for re-sizing datasets:-  

Target volume datasets to be allocated in CYLINDERS 
Distribution volume datasets to be allocated in TRACKS  

LINKLIST datasets:- 
  o Primary allocation   = 3 times Used space   
  o Secondary allocation = 0
  o PDS Directory Blocks = 1.5 times used directory blocks  

SPECIAL  datasets:- 
  o Primary allocation   = 1.4 times Used space 
  o Secondary allocation = 0
  o PDS Directory Blocks = 1.5 times used directory blocks  

PROCLIB datasets:-  
  o Primary allocation   = 3 times Used space   
  o Secondary allocation = 0
  o PDS Directory Blocks = 2.0 times used directory blocks  

OTHER datasets:-
  o Primary allocation   = 1.2 times Used space 
  o Secondary allocation = 0.5 times Used space 
  o PDS Directory Blocks = 2.0 times used directory blocks  

All calculations to be performed in TRACKS, rounded up. 
Conversion TRACK to CYLINDER to be rounded up.  


Regards
Bruce



On Tue, 20 Jul 2021 12:47:54 -0500, Marna WALLE  wrote:


>
>Now...I would like to look at the data set size problem in a larger context - 
>in order to understand where to solve this problem.  More than ever, we have 
>been shipping Continuous Delivery PTFs.  Many of these PTFs are quite large, 
>and occur over the life of a release.  This can put quite a lot of pressure on 
>the size of the target and DLIB data sets being able to accommodate these 
>updates for every service install episode.  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?  Meaning, installing a release for a first time - 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?
>
>-Marna WALLE
>z/OS System Install and Upgrade

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-20 Thread Gibney, Dave

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  On
> Behalf Of Ed Jaffe
> Sent: Tuesday, July 20, 2021 9:50 PM
> To: IBM-MAIN@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
> EgBY0HMszNaDT!8fkfhIsYHEp9Ax8Nex3iS2vOD0fjNwQSKRgiDD_pZGp7xn1t_
> xDQ2PZ06MHs6Q$
> 
> 
> 
> 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.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: 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://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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

It'd be great if IBM disappeared the problem by buying one of the stop x37 
companies :)

- KB

‐‐‐ Original Message ‐‐‐

On Tuesday, July 20th, 2021 at 11:17 PM, Marna WALLE  wrote:

> Hi Barbara (and others),
>
> Nice to see so many users of PDSEs! We do not today have the capability to 
> switch from PDS to PDSE in z/OSMF, but we've got it in our backlog from 
> requests to have it. If PDSEs users would like to help us prioritize that, 
> with their business impacts without this capability, please feel free to 
> email me (mwa...@us.ibm.com).
>
> As for the sizes, for z/OSMF ServerPac we have increased the shipped free 
> space to 40% per data set, and with linklst data sets have zero secondary. 
> This is an increase over the prior free space size we used to provide, in 
> hopes that will help for the time being. This was done because we don't have 
> the ability to re-size today in z/OSMF.
>
> Now...I would like to look at the data set size problem in a larger context - 
> in order to understand where to solve this problem. More than ever, we have 
> been shipping Continuous Delivery PTFs. Many of these PTFs are quite large, 
> and occur over the life of a release. This can put quite a lot of pressure on 
> the size of the target and DLIB data sets being able to accommodate these 
> updates for every service install episode. 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? Meaning, installing a release for a first time - 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?
>
> -Marna WALLE
>
> z/OS System Install and Upgrade
>
> -
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

Okay I am out. Thanks for the clarifications. I will revisit with z/OS 2.6... I 
will just order the serverpac Nov 1, and install, then just apply maint in Feb 
2022 and go-live in March 2022.   In 3 years I can revisit as you have not sold 
me on being simpler and much more work!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Marna WALLE
Sent: Tuesday, July 20, 2021 12:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

External Email


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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-20 Thread Seymour J Metz

Increasing the size is certainly important, but increasing the size of PDS 
directories is absolutely crucial. Of course, in most cases letting them be 
PDS/E would solve the issue.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Marna WALLE [mwa...@us.ibm.com]
Sent: Tuesday, July 20, 2021 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

Hi Barbara (and others),
Nice to see so many users of PDSEs!  We do not today have the capability to 
switch from PDS to PDSE in z/OSMF, but we've got it in our backlog from 
requests to have it.  If PDSEs users would like to help us prioritize that, 
with their business impacts without this capability, please feel free to email 
me (mwa...@us.ibm.com).

As for the sizes, for z/OSMF ServerPac we have increased the shipped free space 
to 40% per data set, and with linklst data sets have zero secondary.  This is 
an increase over the prior free space size we used to provide, in hopes that 
will help for the time being.  This was done because we don't have the ability 
to re-size today in z/OSMF.

Now...I would like to look at the data set size problem in a larger context - 
in order to understand where to solve this problem.  More than ever, we have 
been shipping Continuous Delivery PTFs.  Many of these PTFs are quite large, 
and occur over the life of a release.  This can put quite a lot of pressure on 
the size of the target and DLIB data sets being able to accommodate these 
updates for every service install episode.  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?  Meaning, installing a release for a first time - 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?

-Marna WALLE
z/OS System Install and Upgrade

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

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
IBM Poughkeepsie

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

Hi Barbara (and others),
Nice to see so many users of PDSEs!  We do not today have the capability to 
switch from PDS to PDSE in z/OSMF, but we've got it in our backlog from 
requests to have it.  If PDSEs users would like to help us prioritize that, 
with their business impacts without this capability, please feel free to email 
me (mwa...@us.ibm.com).

As for the sizes, for z/OSMF ServerPac we have increased the shipped free space 
to 40% per data set, and with linklst data sets have zero secondary.  This is 
an increase over the prior free space size we used to provide, in hopes that 
will help for the time being.  This was done because we don't have the ability 
to re-size today in z/OSMF.  

Now...I would like to look at the data set size problem in a larger context - 
in order to understand where to solve this problem.  More than ever, we have 
been shipping Continuous Delivery PTFs.  Many of these PTFs are quite large, 
and occur over the life of a release.  This can put quite a lot of pressure on 
the size of the target and DLIB data sets being able to accommodate these 
updates for every service install episode.  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?  Meaning, installing a release for a first time - 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?

-Marna WALLE
z/OS System Install and Upgrade

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-20 Thread Carmen Vitullo

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

On 7/20/2021 12:05 PM, Marna WALLE wrote:

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).

-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
/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*/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-20 Thread Mike Schwab

On Tue, Jul 20, 2021 at 12:05 PM Marna WALLE  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
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?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

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). 

-Marna WALLE
z/OS System Install and Upgrade
IBM Poughkeepsie

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-20 Thread Colin Paice

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  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
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-20 Thread Mike Schwab

I'm partial to Johnny Cash's - One Piece At A Time.
https://www.youtube.com/watch?v=18cW_yHo3PY

On Tue, Jul 20, 2021 at 8:41 AM Richards, Robert B. (CTR)
<01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:
>
> The mind is the first thing to go. Kelly Clarkson's  song title "Piece By 
> Piece" applies here. I am glad for manuals!!!
>
> IIRC, the answer is no. I am participating in a Db2 install under z/OSMF 
> though. Maybe I'll pick up a few tidbits.
>
> Bob
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> kekronbekron
> Sent: Tuesday, July 20, 2021 9:35 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Serverpac installs January 2022 and beyond - Requests
>
> 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) 
> <01c91f408b9e-dmarc-requ...@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-MAIN@LISTSERV.UA.EDU On Behalf
> > Of kekronbekron
> >
> > Sent: Tuesday, July 20, 2021 9:24 AM
> >
> > To: IBM-MAIN@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) 
> > 01c91f408b9e-dmarc-requ...@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 lists...@listserv.ua.edu with the message: INFO
> > > IBM-MAIN
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > -
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

Marna,

I thought it might have been done.  Thank you for the references to those 
proceedings.

Bob

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Marna WALLE
Sent: Tuesday, July 20, 2021 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

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

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

2021-07-20 Thread Carmen Vitullo

I have defined my 2.3 instance and my 2.4 instance, getting the CSI - 
ZONE info, products is not a big deal, getting datasets and datasets 
info is not so intuitive, actions/view/datasets, other options are a 
pull down from the actions bar.


I 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.


the only difference with my 2.3 and 2.4 instance is the 2.4 serverpac 
order came with a link to download and import the workflow that replaced 
the migration guide.


2.4 will probably be my last order/install since I too am planning 
retirement and someone else will need to figure this out.


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?


As others have said, I've never had a serverpac come in that need not 
need the datasets to be enlarged, or changed, some linklist datasets 
were defined with secondary extents! most like MIGLIB, LINKLIB LPALIB 
SCEE* were defined very small and my first maint always blows up with E37's


I like to have time to read TFM, but there's too much going on for one 
person right now.



Carmen



On 7/20/2021 9:27 AM, Shaffer, Terri wrote:

Ed,
   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.

How about my master catalog or usercatalog names..  and many other things..  I 
don’t understand how this would help or solve the layout issues.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Tuesday, July 20, 2021 10:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

External Email


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 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.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
/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

Re: Serverpac installs January 2022 and beyond - Requests


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.)\


--

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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

Ed,
  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.

How about my master catalog or usercatalog names..  and many other things..  I 
don’t understand how this would help or solve the layout issues.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Tuesday, July 20, 2021 10:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

External Email

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 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.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

"... 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 ‐‐‐

On Tuesday, July 20th, 2021 at 7:08 PM, Shaffer, Terri 
<017d5f778222-dmarc-requ...@listserv.ua.edu> wrote:

> 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.shaf...@aciworldwide.com
>
> -Original Message-
>
> From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of 
> kekronbekron
>
> Sent: Tuesday, July 20, 2021 9:24 AM
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Re: Serverpac installs January 2022 and beyond - Requests
>
> External Email
>
> 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) 
> 01c91f408b9e-dmarc-requ...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> [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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

Sounds like great SHARE session material (if it isn't already there for the 
next one).

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: Tuesday, July 20, 2021 10:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

On 7/20/2021 6:34 AM, kekronbekron wrote:
> Hmm.. is 2.4 is available as a zOSMF Software Instance via ShopZ?

No products are available as Software Instances from ShopZ, they come as 
PORTABLE Software Instances.

You can create a Software Instance for any collection of software you have -- 
SMP/E based or not. It's a trivial exercise to create a Software Instance for a 
target zone in an existing CSI. Doing that is what has been suggested by Marna.

--
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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests


On 7/20/2021 6:34 AM, kekronbekron wrote:

Hmm.. is 2.4 is available as a zOSMF Software Instance via ShopZ?


No products are available as Software Instances from ShopZ, they come as 
PORTABLE Software Instances.


You can create a Software Instance for any collection of software you 
have -- SMP/E based or not. It's a trivial exercise to create a Software 
Instance for a target zone in an existing CSI. Doing that is what has 
been suggested by Marna.



--
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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests


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 
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.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

The mind is the first thing to go. Kelly Clarkson's  song title "Piece By 
Piece" applies here. I am glad for manuals!!!

IIRC, the answer is no. I am participating in a Db2 install under z/OSMF 
though. Maybe I'll pick up a few tidbits.

Bob

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
kekronbekron
Sent: Tuesday, July 20, 2021 9:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

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) 
<01c91f408b9e-dmarc-requ...@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-MAIN@LISTSERV.UA.EDU On Behalf 
> Of kekronbekron
>
> Sent: Tuesday, July 20, 2021 9:24 AM
>
> To: IBM-MAIN@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) 
> 01c91f408b9e-dmarc-requ...@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 lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
>
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> -
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

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.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
kekronbekron
Sent: Tuesday, July 20, 2021 9:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Serverpac installs January 2022 and beyond - Requests

External Email

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) 
<01c91f408b9e-dmarc-requ...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

 [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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

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) 
<01c91f408b9e-dmarc-requ...@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-MAIN@LISTSERV.UA.EDU On Behalf Of 
> kekronbekron
>
> Sent: Tuesday, July 20, 2021 9:24 AM
>
> To: IBM-MAIN@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) 
> 01c91f408b9e-dmarc-requ...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ---
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

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  On Behalf Of 
kekronbekron
Sent: Tuesday, July 20, 2021 9:24 AM
To: IBM-MAIN@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) 
<01c91f408b9e-dmarc-requ...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: 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) 
<01c91f408b9e-dmarc-requ...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Serverpac installs January 2022 and beyond - Requests