Re: New Mainframe Community

[Seymour J Metz]

> I'll go further and advance the modest proposal that a compiler that supports 
> UTF-8
> should treat non-ASCII characters as honorary alphabetic. 

I would support a new ANSI standard (way overdue anyway) for PL/I that allowed 
any Unicode alphabetic character in identifiers, but I am leery about changing 
the rules for the existing language level. At a minimum, any compiler 
supporting extended identifiers should have an option for enforcing strict 
compliance with the current syntax.

> 507 $ ls -alrt

?

I understand about touch not getting a syntax error, but what is the ls 
supposedf to be telling?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Friday, June 26, 2020 9:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

On Sat, 27 Jun 2020 00:21:08 +, Seymour J Metz wrote:
>
>> Should they turn off their Hebrew or Chinese names too?
>
>Yes, for variables names in code samples where the language doesn't allow them.
>Consider these two lines in a PL/I program for a compiler that supports 
>Unicode.
>The first is legitimate; the second is not.
>
>foo = bar /* פּלוני Good */;
>foo = פּלוני /* Bad! */;
>
I'll go further and advance the modest proposal that a compiler that supports 
UTF-8
should treat non-ASCII characters as honorary alphabetic.  So your "Bad!" 
example
would be Good.  Bash on MacOS and Linux goes partway there:
506 $ touch פּלוני
507 $ ls -alrt
total 0
drwxr-xr-x  7 paulgilm  wheel  224 Jun 26 19:06 ..
-rw-r--r--  1 paulgilm  wheel0 Jun 26 19:06 פּלוני
drwxr-xr-x  3 paulgilm  wheel   96 Jun 26 19:06 .
508 $
>...
>> "Dumb" quotes are an artifact of typewriters and 6- or 7-bit character sets.
>
>There's nothing smart about using invalid syntax in code samples, and even
>where it's only a style issue there are millennials who don't agree with you.
>
OTOH, I laud modern (non-Bourne) shells for providing as an alternative
for symmetrical command substitution "` list `" the asymmetrical yet
ASCII "$( list )".  The latter can be nested without a nightmare of escapes.

-- gil

--
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: New Mainframe Community

[Wayne Bickerdike]

I Manifest Hostile Opinions

On Sat, Jun 27, 2020 at 1:05 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 26 Jun 2020 22:28:02 -0400, Doug wrote:
>
> >We currently have a Strong Supportive group. Opinions are freely given
> and taken period. Banter and brainstorming lead to ideas that when given
> the space to grow are fortuitous for all.
> >Continue as we have and we will still be a great group!
> >Participants in the ‘new community’ are trying to communicate at and in
> their comfort zone.
> >I for one do not fault them for that but do fear they will have to
> reinvent years of the work those of us already know.
> >
> Several experts from IBM are frequent and valuable contributors to
> IBM-MAIN.  Does a similar resource exist for https://mainframe.community/
> ?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: New Mainframe Community

[Paul Gilmartin]

On Fri, 26 Jun 2020 22:28:02 -0400, Doug wrote:

>We currently have a Strong Supportive group. Opinions are freely given and 
>taken period. Banter and brainstorming lead to ideas that when given the space 
>to grow are fortuitous for all.
>Continue as we have and we will still be a great group! 
>Participants in the ‘new community’ are trying to communicate at and in their 
>comfort zone.
>I for one do not fault them for that but do fear they will have to reinvent 
>years of the work those of us already know.
> 
Several experts from IBM are frequent and valuable contributors to
IBM-MAIN.  Does a similar resource exist for https://mainframe.community/
?

-- gil

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

Re: New Mainframe Community

[Doug]

We currently have a Strong Supportive group. Opinions are freely given and 
taken period. Banter and brainstorming lead to ideas that when given the space 
to grow are fortuitous for all.
Continue as we have and we will still be a great group! 
Participants in the ‘new community’ are trying to communicate at and in their 
comfort zone.
I for one do not fault them for that but do fear they will have to reinvent 
years of the work those of us already know.

Ah yes
When you can change the system, you have become the system.

My 2 cents

Have a wonderful weekend!
Best Regards, Doug
.

On Jun 26, 2020, at 17:34, Phil Smith III  wrote:

Of course Charles is correct-I did not mean to imply that I thought IBM-MAIN 
was the zenith of information sharing. It's still on LISTSERV, which is 
near to my heart as a long-time VMer, but whose day has largely come and 
gone, due to the issues Charles mentions (and more).



Now, if someone wanted to migrate IBM-MAIN to (say) groups.io, that might be 
good; OTOH, who knows whether groups.io will persist. There's risk in moving 
and then losing that platform.



Oh for the good old days, when LISTSERV was the only real choice, so we were 
happy to have it!



...phsiii 


--
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: New Mainframe Community

[Paul Gilmartin]

On Sat, 27 Jun 2020 00:21:08 +, Seymour J Metz wrote:
>
>> Should they turn off their Hebrew or Chinese names too? 
>
>Yes, for variables names in code samples where the language doesn't allow 
>them. 
>Consider these two lines in a PL/I program for a compiler that supports 
>Unicode. 
>The first is legitimate; the second is not.
>
>foo = bar /* פּלוני Good */;
>foo = פּלוני /* Bad! */;
>
I'll go further and advance the modest proposal that a compiler that supports 
UTF-8
should treat non-ASCII characters as honorary alphabetic.  So your "Bad!" 
example
would be Good.  Bash on MacOS and Linux goes partway there:
506 $ touch פּלוני
507 $ ls -alrt
total 0
drwxr-xr-x  7 paulgilm  wheel  224 Jun 26 19:06 ..
-rw-r--r--  1 paulgilm  wheel0 Jun 26 19:06 פּלוני
drwxr-xr-x  3 paulgilm  wheel   96 Jun 26 19:06 .
508 $ 
>...
>> "Dumb" quotes are an artifact of typewriters and 6- or 7-bit character sets.
>
>There's nothing smart about using invalid syntax in code samples, and even 
>where it's only a style issue there are millennials who don't agree with you.
>
OTOH, I laud modern (non-Bourne) shells for providing as an alternative
for symmetrical command substitution "` list `" the asymmetrical yet
ASCII "$( list )".  The latter can be nested without a nightmare of escapes.

-- gil

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

Re: New Mainframe Community

[Seymour J Metz]

> Why? Because "pure" ASCII is ordained somewhere? 

Stop with the straw dummies. Rebut arguments that somebody actually made and 
people will take you more seriously.

> Should they turn off their Hebrew or Chinese names too? 

Yes, for variables names in code samples where the language doesn't allow them. 
Consider these two lines in a PL/I program for a compiler that supports 
Unicode. The first is legitimate; the second is not.

foo = bar /* פּלוני Good */;
foo = פּלוני /* Bad! */;

> Unicode rulz, dude! 

Even if that were true it wouldn't justify using the *WRONG* Unicode code point.

> Readability rulz!

No. Work with a tech writer who turns your broken English into polished prose 
that no longer matches the product and you'll understand why.

> "Dumb" quotes are an artifact of typewriters and 6- or 7-bit character sets.

There's nothing smart about using invalid syntax in code samples, and even 
where it's only a style issue there are millennials who don't agree with you.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Friday, June 26, 2020 6:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

+1 on redundant replies.

> wish is that the WWW interface supported composing in a
> monospaced font

What's the difference? It shows up for the recipient in whatever font they 
choose, typically monospaced.

> that submitters turn off "smart" quotes

Why? Because "pure" ASCII is ordained somewhere? Should they turn off their 
Hebrew or Chinese names too? Unicode rulz, dude! Readability rulz! I agree -- 
it looks better that way. "Dumb" quotes are an artifact of typewriters and 6- 
or 7-bit character sets. Real type has used "smart" quotes for centuries.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, June 26, 2020 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

On Fri, 26 Jun 2020 13:46:06 -0700, Charles Mills wrote:

>There *are* IMHO some problems with IBMMAIN but it is not clear to me that
>they are significant enough to worry about nor that some new forum would
>necessarily be better overall.
>
>- Searchability. The archives leave a lot to be desired in this regard IMHO.
>- Topic drift. There is something of tendency for many threads here to drift
>into hardware nostalgia, sometimes with the effect of obscuring the original
>question. There are often answers here from people who did not read the
>original question.
>
Conversely, redundant replies from people who read only the original
question which has already been sufficiently answered.  I can wish for
the ancient USENET etiquette of replying directly to originator who is
responsible for following up with a summary.

>A better "threaded" interface would help prevent this.
>
Examples:

http://secure-web.cisco.com/1DIq6_IG177X7FZE0F-KdEbgeUN8XBYWxs3iRKawJ2FuusQLNkPR94GxdABapLs8XC1pLpNw6ojRslZKiqgcyYDH3A-GzAtubq_wY0jgCs7AiN4k8ASYDYetTNXvkvsaKXri1ttfbwptiGu1sXNA7ksgxirXahW4Le2TL3f4OeXjQy9gHZHANGGjDd0CGI347uHexXOZVfEc4Tf6m9AR69KlAFg6HlFtQZ3u29Iy0TwcoQUMC2Axgt4O7GYqFD7RjPKK4bkwaVIj2yh8BOP_mudi6oV1xV_G1rfMP6O-lmHTL9cWZ8cls6QV6s5KcwdhAMcv0G1wJSZ4rS6d0z0Y71gbTihQibz2MhIBEMRoqzD_7NRrRBan5V3wJihzHG0QtQx9dRvYTbKivHSj4ImG9ofBkBvk1_rEl5OKrkmEVu_c8-3RLvIVVdEn8-zJKEm5-/http%3A%2F%2Fmm.icann.org%2Fpipermail%2Ftz%2F2020-January%2Fthread.html

https://secure-web.cisco.com/1gU3Y9dWpjXR4lEJiZN6BwxLExLnFsMb3yMudDH8Ct1SM60Ug7HXC_a7RaWUY12rRs203KlvmXpRkKo6YRsMuMBsNzo5-BRbuAqtW3IAUZkcWYYg_Mz0KdhfIwsBvQ1c1ITtZQR11EnHnrecZdboOxyv7390IkAWhk7ir39rpxVrQFaN-Ae2cE1NTDPITJS-JRSQIsoHlQFMcrEr0XJHDPFAAGjbs-4LCFrMliq4aLlfKllTQWeD_Rgh5y_rVJVzC2E7iAHBrj8AXtyMIxERzz1mS8uxWyFItLJCQ7DFdryh1mkZGoU_dmMmbEaZoZXBbcwRVCSptKGw2_AKQrMzTcHHUl6QGtJdvm7zukxHATyBj2RVGDxhI3m5jHEqf9GajYIIZd58pfBsqz_bgCABSZG5X38QrPpF_P3HLRLyk1AYAMMQhT6EIpbvHe9mV1rYX-Bb2kQYTBN-AmEeVxty41A/https%3A%2F%2Fcurl.haxx.se%2Fmail%2Farchive-2020-01%2F
C'mon, LISTSERV.

>- Lack of formatting. Yeah, I know a lot of old-timers love plain text (let
>the flames begin!) but most modern fora have the ability to set off code
>examples at the very least. I think that would be useful here.
>
To that end, my simplest wish is that the WWW interface supported
composing in a monospaced font.
C'mon, LISTSERV.

And, of course, that submitters turn off "smart" quotes.  Such problems
exist even in IBM Reference Manuals.  I went to RCF on one such and
got the reply that it looks better that way.

--
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: DASD migration -- Re: Hitachi RAID box going out of support

[Mike Schwab]

I have used FDRPAS, TDMF which were all vendor compatible, and Dell
z/OS Migrator which must have their hardware as the target.  Most
movement was done with the system running at full speed.  The
different software packages did require different software products to
be down to SWAP their files.  Did require IPL to use new volumes.
25TB 3000 volumes in two days from an IBM F20 / 800 source with vendor
assistance for the z/OS migrator to Dell / EMC VMAX.  TDMF was in
house and did as 'time as available' task.  Consolidating onto bigger
volumes is what takes time and we would have exceeded UCB count limit
on LCU without it. But you are unlikely to be attempting that process.
So your purchase should include software to move your data while the
system is operating.

Probably a 90 day window once the hardware is operating, with one week
vendor assistance (onsite / webex).  For the mainframe, I would
suggest a z13 so you can IPL your old system with 31 bit IPL text that
switches to 64 bit operation.  Its old so you should be able to get a
cheap one but with a maintenance contract.  And watch the
compatibility on FICON cards / directors.

On Fri, Jun 26, 2020 at 3:04 PM Grant Taylor
<023065957af1-dmarc-requ...@listserv.ua.edu> wrote:
>
> On 6/26/20 3:16 AM, R.S. wrote:
> > 3. 18 months is close to half of typical service contract for new dasd
> > array. Still we don't know how sure is 18 months - maybe it would be 36
> > months? Even 12 months means the dasd array would have some residual value.
>
> n00b questions:
>
> 1)  Is it possible to migrate from old DASD to new DASD?
>
> 2)  How disruptive would this be to the day-to-day operation of the
> existing mainframe?
>
> 3)  What sort of prerequisites exist for this?
>
> I have some experience with this in the Open Systems environment, but
> I'd like to know more about how such a storage migration would be done
> in the mainframe world.
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
> 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: New Mainframe Community

[Seymour J Metz]

> underscored blanks nearly vanished

Wouldn't bolding each underscore be a better solution?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Friday, June 26, 2020 7:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

On Fri, 26 Jun 2020 16:06:56 -0700, Charles Mills wrote:

>No, I know of no computer language that treats "smart" quotes as equivalent to 
>"dumb" quotes. Did not know you were referring to code samples. You meant 
>smart quotes in code samples in IBM manuals? That is just flat out wrong, 
>wrong, wrong. It's just as wrong as if they used ENQUEUE rather than ENQ in an 
>example -- it looks better too. The point of code samples is not to "look 
>good."
>
OK.  I chiseled a bit.  IIRC more precisely, a manual used something
like __BPX__SHAREAS rather than _BPX_SHAREAS because the
underscored blanks nearly vanished in the proportional font used
in the manual. It was a deliberate decision by the writer, not
autocorrection by the tool.  However nice it appeared in the .pdf
it failed when I pasted it into a script.

-- gil

--
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: New Mainframe Community

[Paul Gilmartin]

On Fri, 26 Jun 2020 16:06:56 -0700, Charles Mills wrote:

>No, I know of no computer language that treats "smart" quotes as equivalent to 
>"dumb" quotes. Did not know you were referring to code samples. You meant 
>smart quotes in code samples in IBM manuals? That is just flat out wrong, 
>wrong, wrong. It's just as wrong as if they used ENQUEUE rather than ENQ in an 
>example -- it looks better too. The point of code samples is not to "look 
>good."
>
OK.  I chiseled a bit.  IIRC more precisely, a manual used something
like __BPX__SHAREAS rather than _BPX_SHAREAS because the
underscored blanks nearly vanished in the proportional font used
in the manual. It was a deliberate decision by the writer, not
autocorrection by the tool.  However nice it appeared in the .pdf
it failed when I pasted it into a script.

-- gil

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

Re: Virtual SHARE

[Lund James E]

Don't forget the 5 minutes of live Q/A at the end of your session, Phil...  

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Friday, June 26, 2020 4:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] Virtual SHARE

Be aware that virtual SHARE sessions will apparently be 40 minutes long. Don't 
blame the messenger: not my idea, nor was I particularly thrilled to discover 
it, since the session I'm giving was, surprise, targeted at 60 minutes. I'll 
just have to talk real fast :)

 

I guess the good news is that if you're trying to  fit a virtual SHARE session 
in between meetings, it won't run over and make you late.


--
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: New Mainframe Community

[Charles Mills]

No, I know of no computer language that treats "smart" quotes as equivalent to 
"dumb" quotes. Did not know you were referring to code samples. You meant smart 
quotes in code samples in IBM manuals? That is just flat out wrong, wrong, 
wrong. It's just as wrong as if they used ENQUEUE rather than ENQ in an example 
-- it looks better too. The point of code samples is not to "look good."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, June 26, 2020 3:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

On Fri, 26 Jun 2020 15:33:36 -0700, Charles Mills wrote:

>+1 on redundant replies.
>
>> wish is that the WWW interface supported composing in a 
>> monospaced font
>
>What's the difference? It shows up for the recipient in whatever font they 
>choose, typically monospaced.
> 
But I'm the composer.  LISTSERV WWW has no monospace option.
I'd like to see vertical alignment in code samples that I type or paste.

>> that submitters turn off "smart" quotes
>
>Why? Because "pure" ASCII is ordained somewhere? Should they turn off their 
>Hebrew or Chinese names too? Unicode rulz, dude! Readability rulz! I agree -- 
>it looks better that way. "Dumb" quotes are an artifact of typewriters and 6- 
>or 7-bit character sets. Real type has used "smart" quotes for centuries.
> 
For code samples.  Do compilers nowadays understand "smart" quotes?
HLASM, for one, doesn't.

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

Re: New Mainframe Community

[Paul Gilmartin]

On Fri, 26 Jun 2020 15:33:36 -0700, Charles Mills wrote:

>+1 on redundant replies.
>
>> wish is that the WWW interface supported composing in a 
>> monospaced font
>
>What's the difference? It shows up for the recipient in whatever font they 
>choose, typically monospaced.
> 
But I'm the composer.  LISTSERV WWW has no monospace option.
I'd like to see vertical alignment in code samples that I type or paste.

>> that submitters turn off "smart" quotes
>
>Why? Because "pure" ASCII is ordained somewhere? Should they turn off their 
>Hebrew or Chinese names too? Unicode rulz, dude! Readability rulz! I agree -- 
>it looks better that way. "Dumb" quotes are an artifact of typewriters and 6- 
>or 7-bit character sets. Real type has used "smart" quotes for centuries.
> 
For code samples.  Do compilers nowadays understand "smart" quotes?
HLASM, for one, doesn't.

-- gil

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

Re: New Mainframe Community

[Charles Mills]

+1 on redundant replies.

> wish is that the WWW interface supported composing in a 
> monospaced font

What's the difference? It shows up for the recipient in whatever font they 
choose, typically monospaced.

> that submitters turn off "smart" quotes

Why? Because "pure" ASCII is ordained somewhere? Should they turn off their 
Hebrew or Chinese names too? Unicode rulz, dude! Readability rulz! I agree -- 
it looks better that way. "Dumb" quotes are an artifact of typewriters and 6- 
or 7-bit character sets. Real type has used "smart" quotes for centuries.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, June 26, 2020 2:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

On Fri, 26 Jun 2020 13:46:06 -0700, Charles Mills wrote:

>There *are* IMHO some problems with IBMMAIN but it is not clear to me that
>they are significant enough to worry about nor that some new forum would
>necessarily be better overall.
>
>- Searchability. The archives leave a lot to be desired in this regard IMHO.
>- Topic drift. There is something of tendency for many threads here to drift
>into hardware nostalgia, sometimes with the effect of obscuring the original
>question. There are often answers here from people who did not read the
>original question. 
>
Conversely, redundant replies from people who read only the original
question which has already been sufficiently answered.  I can wish for
the ancient USENET etiquette of replying directly to originator who is
responsible for following up with a summary.

>A better "threaded" interface would help prevent this.
>
Examples:
http://mm.icann.org/pipermail/tz/2020-January/thread.html
https://curl.haxx.se/mail/archive-2020-01/
C'mon, LISTSERV.

>- Lack of formatting. Yeah, I know a lot of old-timers love plain text (let
>the flames begin!) but most modern fora have the ability to set off code
>examples at the very least. I think that would be useful here.
>
To that end, my simplest wish is that the WWW interface supported
composing in a monospaced font.
C'mon, LISTSERV.

And, of course, that submitters turn off "smart" quotes.  Such problems
exist even in IBM Reference Manuals.  I went to RCF on one such and
got the reply that it looks better that way.

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

Virtual SHARE

[Phil Smith III]

Be aware that virtual SHARE sessions will apparently be 40 minutes long. Don't 
blame the messenger: not my idea, nor was I particularly thrilled to discover 
it, since the session I'm giving was, surprise, targeted at 60 minutes. I'll 
just have to talk real fast :)

 

I guess the good news is that if you're trying to  fit a virtual SHARE session 
in between meetings, it won't run over and make you late.


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

Re: New Mainframe Community

[Phil Smith III]

Of course Charles is correct-I did not mean to imply that I thought IBM-MAIN 
was the zenith of information sharing. It's still on LISTSERV, which is 
near to my heart as a long-time VMer, but whose day has largely come and 
gone, due to the issues Charles mentions (and more).

 

Now, if someone wanted to migrate IBM-MAIN to (say) groups.io, that might be 
good; OTOH, who knows whether groups.io will persist. There's risk in moving 
and then losing that platform.

 

Oh for the good old days, when LISTSERV was the only real choice, so we were 
happy to have it!

 

...phsiii 


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

Re: New Mainframe Community

[Paul Gilmartin]

On Fri, 26 Jun 2020 13:46:06 -0700, Charles Mills wrote:

>There *are* IMHO some problems with IBMMAIN but it is not clear to me that
>they are significant enough to worry about nor that some new forum would
>necessarily be better overall.
>
>- Searchability. The archives leave a lot to be desired in this regard IMHO.
>- Topic drift. There is something of tendency for many threads here to drift
>into hardware nostalgia, sometimes with the effect of obscuring the original
>question. There are often answers here from people who did not read the
>original question. 
>
Conversely, redundant replies from people who read only the original
question which has already been sufficiently answered.  I can wish for
the ancient USENET etiquette of replying directly to originator who is
responsible for following up with a summary.

>A better "threaded" interface would help prevent this.
>
Examples:
http://mm.icann.org/pipermail/tz/2020-January/thread.html
https://curl.haxx.se/mail/archive-2020-01/
C'mon, LISTSERV.

>- Lack of formatting. Yeah, I know a lot of old-timers love plain text (let
>the flames begin!) but most modern fora have the ability to set off code
>examples at the very least. I think that would be useful here.
>
To that end, my simplest wish is that the WWW interface supported
composing in a monospaced font.
C'mon, LISTSERV.

And, of course, that submitters turn off "smart" quotes.  Such problems
exist even in IBM Reference Manuals.  I went to RCF on one such and
got the reply that it looks better that way.

>Phil is of course right: whether you are inventing a forum or a software
>product, it is good to start from a user problem and proceed from there to a
>solution. Solutions in search of a problem lead to the dread situation of
>"educating the market."

-- gil

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

Re: New Mainframe Community

[Seymour J Metz]

Try google or google is trying? Every time they improve google it gets harder 
to use.

A lot of times I get better results using Wikipedia as a search engine than I 
get from google,  and the thing that I depended on most, the Usenet archive 
they took over from DejaNews, they've destroyed.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Steve Smith [sasd...@gmail.com]
Sent: Friday, June 26, 2020 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

Inscrutable mostly harmless offal.

btw, there's this new thing, Google.  It's free to try.

sas

--
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: New Mainframe Community

[Charles Mills]

There *are* IMHO some problems with IBMMAIN but it is not clear to me that
they are significant enough to worry about nor that some new forum would
necessarily be better overall.

- Searchability. The archives leave a lot to be desired in this regard IMHO.
- Topic drift. There is something of tendency for many threads here to drift
into hardware nostalgia, sometimes with the effect of obscuring the original
question. There are often answers here from people who did not read the
original question. A better "threaded" interface would help prevent this.
- Lack of formatting. Yeah, I know a lot of old-timers love plain text (let
the flames begin!) but most modern fora have the ability to set off code
examples at the very least. I think that would be useful here.

Phil is of course right: whether you are inventing a forum or a software
product, it is good to start from a user problem and proceed from there to a
solution. Solutions in search of a problem lead to the dread situation of
"educating the market."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith III
Sent: Friday, June 26, 2020 1:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

Henri Kuiper wrote:

>Wow. What a lot of pushback.

Well, nobody has offered any problem that this new forum is going to solve.
Nor does that web page you cite: it says "I did this technically interesting
thing", but that isn't solving a *problem*. That's my objection: we have a
solution to the problem that works. If there's a better one, great; but
there have, as has been noted, been several other fora created, and since
none of them solved a problem that IBM-MAIN had, they're pretty well all
dead.

That's key both for products and open source offerings: there needs to be an
actual problem that gets solved. Mattermost/MatterMost (it's unclear from
that page which is the actual name) looks like yet another Teams/Lync/Fuze,
and that's a real problem that companies have-but IBM-MAIN does not.

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

Re: New Mainframe Community

[Phil Smith III]

Henri Kuiper wrote:

>Wow. What a lot of pushback.

 

Well, nobody has offered any problem that this new forum is going to solve. Nor 
does that web page you cite: it says "I did this technically interesting 
thing", but that isn't solving a *problem*. That's my objection: we have a 
solution to the problem that works. If there's a better one, great; but there 
have, as has been noted, been several other fora created, and since none of 
them solved a problem that IBM-MAIN had, they're pretty well all dead.

 

That's key both for products and open source offerings: there needs to be an 
actual problem that gets solved. Mattermost/MatterMost (it's unclear from that 
page which is the actual name) looks like yet another Teams/Lync/Fuze, and 
that's a real problem that companies have-but IBM-MAIN does not.

 

For those of us who have been using email for 40+ years, email is a good 
solution for this kind of information. In fact, Teams (to pick one) fails, for 
me at least, because it's too ephemeral: I cannot easily search an archive of 
information that has appeared in Teams and extract valuable tidbits. Irritating.

 

Old = good is foolish; so is new = good.

 

...phsiii 


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

Re: make /etc/ smaller

[Mark Charles]

On advice from Michael Brennan I created the smaller ZFS dataset and used PAX 
to copy into it (instead of IDCAMS REPRO).  That worked great!  Now I'm ready 
to IPL...

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

Re: DASD migration

[Matthew Stitt]

My favorite method of migrating to new DASD works for almost all the datasets.  
Define the new Disk volumes to your DFSMS Storage Group configuration(s).  
Change the old Disk volumes in each Storage Group to "DISNEW".  This method 
ensures that as each dataset is moved/copied/reorg/created it will show up on 
the new DASD.  Seamless and painless.  Finally a short outage to move the ones 
which are proving difficult.

Matthew

On Fri, 26 Jun 2020 09:27:42 -0600, Grant Taylor  
wrote:

>On 6/26/20 9:09 AM, Bill Bishop (TMNA) wrote:
>> One issue that you may encounter with going to a new storage system on
>> a z9 processor is the speed of the ficon cards and whether the new unit
>> can z9 cards.  I am not sure the new Hitachi's can work with 4GB ficon.
>
>I would naively assume that the FICON switch (director?) would
>facilitate speed conversion.  Is that an incorrect assumption?
>
>
>
>--
>Grant. . . .
>unix || die

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

Re: New Mainframe Community

[Tony Harminc]

On Fri, 26 Jun 2020 at 12:57, Henri Kuiper  wrote:
>
> Wow. What a lot of pushback.
>
> This is (IMHO) precisely what’s wrong with the (generic average)  mainframe 
> community. New is bad.  Different is bad.

No one has said anything remotely like that.

> Dudes (m/f) : it’s not the 80s anymore.
>
> That being said : here’s a little “why” for the existence of the thing : 
> https://zdevops.tumblr.com/post/620908065704853504/mainframe-community-mattermost

OK - looks cool. But why is it good because it's posted on a site that
evidently exists not to make cool new stuff public, but to monetize
it? How does the existence of something nifty on it justify such a
site? Why not post nifty stuff right here on IBM-MAIN?

> That being said I’d say “traditional”  peeps like some of the reactions I 
> read here should probably not even try to see what it is.

Well look who has the attitude now...

> There’s no punch cards. No bus But an easy, modern, new (young) blood 
> friendly environment where about 100 peeps are having some fun discussing 
> mainframe things.

Seriously...? As opposed to a mailing list that must obviously be
difficult, old-fashioned, unfriendly to youth?

> No hard feelings.

You're sure...?

Tony H.

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

Re: New Mainframe Community

[Gord Tomlin]

On 2020-06-26 12:57, Henri Kuiper wrote:

here’s a little “why” for the existence of the thing 
:https://zdevops.tumblr.com/post/620908065704853504/mainframe-community-mattermost


I read the above, and then headed over to see https://mainframe.community/

I see that the privacy policy and terms are the default ones supplied by 
Mattermost. Has this site set up its own privacy policy and terms, or is 
it relying on the defaults provided by Mattermost? I have to ask, 
because there isn't much to see without creating an account and logging in.


Thanks!

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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

Re: New Mainframe Community

[Steve Smith]

Inscrutable mostly harmless offal.

btw, there's this new thing, Google.  It's free to try.

sas

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

Re: New Mainframe Community

[Lionel B Dyck]

IMHO - In My Humble Opinion

IMNSHO - In My Not So Humble Opinion




Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
McCabe, Ron
Sent: Friday, June 26, 2020 1:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

I know this is off topic but what does IMHO stand for?

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Henri Kuiper
Sent: Friday, June 26, 2020 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

CAUTION: This email is from an external address. Please be careful of links and 
attachments.


I was referring to the generic average. Not to anything anyone wrote here.

I already regret replying.

/EOT


> On 26 Jun 2020, at 19:30, Seymour J Metz  wrote:
>
> Not all change is progress, nor does an ad hominem argument bolster your 
> case. Neither does constructing straw dummies. "New is bad.  Different is 
> bad." is a free construct of your imagination, unrelated to anything that 
> anybody here wrote.
>
> Are their objections valid? I don't know, but misrepresenting them won't 
> convince anybody that they're wrong.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://nam03.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g
> mu.edu%2F~smetz3data=02%7C01%7Crmccabe%40MUTUALOFENUMCLAW.COM%7Ca
> 1e943177ffc4f2d25da08d819fd702e%7C5a381f7dcc3d4a93b2cbd2fd072e535a%7C1
> %7C0%7C637287923585463930sdata=SjLcLbjqGR3mfHqipZQ1m9cCXLbjpal983
> ru177s4ow%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on 
> behalf of Henri Kuiper [henrikui...@zdevops.com]
> Sent: Friday, June 26, 2020 12:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: New Mainframe Community
>
> Wow. What a lot of pushback.
>
> This is (IMHO) precisely what’s wrong with the (generic average)  mainframe 
> community. New is bad.  Different is bad.
>
> Dudes (m/f) : it’s not the 80s anymore.
>
> That being said : here’s a little “why” for the existence of the thing
> :
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecu
> re-web.cisco.com%2F1XvN1_V6ok1sJNlFaq7Z343XlW_wRn1pLUP1SgDYhckTcNv1FTR
> NKBGu8BhJjyQFtzWCCdxOEkvQnVbzjpkqyIRWBMVMKO5NSI-_UQmV1T4GP85WyNx0I4tfX
> KY1GyyBAr7-13umt61eWdwZnJ4bmDSMkvpmk0_byLSjeOa645E40X2BFl2gbfYLVB5tGPd
> 17bav80BvBMpmwbZflaSxkwRKCxNL5XcRfUQPMhpXZWZmUKY1zXMYL7_BESm8M2UUp15ds
> c7B9m8yYh98BuxkEmTbrJsw_AtpWxwk9--8dv2iecdL4nxNDhXzCt6cDHOu1q85TVJ2MqE
> pSo446EYbJAKC4r5vEuKvLDlI1DJ2XnTNZopVXqx9eofDzOzd8aDo1iWe_YjyhkhxGMZSC
> 3vWLVdzgWUvbc1ciqLqZXVnjecO_3YH03XnqCv8Bk5um6Tm4%2Fhttps%253A%252F%252
> Fzdevops.tumblr.com%252Fpost%252F620908065704853504%252Fmainframe-comm
> unity-mattermostdata=02%7C01%7Crmccabe%40MUTUALOFENUMCLAW.COM%7Ca
> 1e943177ffc4f2d25da08d819fd702e%7C5a381f7dcc3d4a93b2cbd2fd072e535a%7C1
> %7C0%7C637287923585463930sdata=feh79oxBKnJUOLcX0pYmtHJwYoOABeIety
> 9EMMxcYUM%3Dreserved=0
>
> That being said I’d say “traditional”  peeps like some of the reactions I 
> read here should probably not even try to see what it is.
>
> There’s no punch cards. No bus But an easy, modern, new (young) blood 
> friendly environment where about 100 peeps are having some fun discussing 
> mainframe things.
>
> No hard feelings.
>
> And a happy weekend !
>
>
>
> Sent from my wireless iPhone
>
>> On 17 Jun 2020, at 01:12, Peter Bishop  wrote:
>>
>> Hi Carmen,
>>
>> "there's no such thing as a dumb question" comes to mind.  No need for any 
>> corner for you.  I also learned a bit of history and now know why that site 
>> Kolosu mentioned looks like so much rubbish now...
>>
>> cheers,
>> Peter
>>
 On 16/06/2020 10:31 pm, Carmen Vitullo wrote:
>>> Kolusu, reached out to me personally and I replied to the wrong message and 
>>> my response went to this forum, so I need more coffee.
>>> thanks for the kind words and now that my response is 'out there' I have to 
>>> apologize to Mark for naming names. As a novice it's sometimes frustrating 
>>> when the company you support does not pay for Q support from IBM and has 
>>> been so terrible to loose all their MF staff.
>>> I've been lucky to be able to move on and learn more about design and build 
>>> and supporting my environment.
>>> back to my corner
>>>
>>>
>>>
>>>
>>> - Original Message -
>>>
>>> From: "Lionel B Dyck" 
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Sent: Tuesday, June 16, 2020 7:24:06 AM
>>> Subject: Re: New Mainframe Community
>>>
>>> Carmen - never put yourself down. While you may not be 'as smart' as some, 
>>> I'm sure you are 'smarter' than some as well. We each bring to the table 
>>> (forum/life) our own skills and capabilities which complement rather than 
>>> replace those of 

Re: New Mainframe Community

[Pew, Curtis G]

On Jun 26, 2020, at 1:43 PM, McCabe, Ron  wrote:
> 
> I know this is off topic but what does IMHO stand for?
> 

In My Humble Opinion.


-- 
Pew, Curtis G
curtis@austin.utexas.edu

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

Re: New Mainframe Community

[Joe Monk]

In my humble opinion

joe

On Fri, Jun 26, 2020 at 1:44 PM McCabe, Ron 
wrote:

> I know this is off topic but what does IMHO stand for?
>
> Thanks,
> Ron McCabe
> Manager of Mainframe/Midrange Systems
> Mutual of Enumclaw
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Henri Kuiper
> Sent: Friday, June 26, 2020 11:19 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: New Mainframe Community
>
> CAUTION: This email is from an external address. Please be careful of
> links and attachments.
>
>
> I was referring to the generic average. Not to anything anyone wrote here.
>
> I already regret replying.
>
> /EOT
>
>
> > On 26 Jun 2020, at 19:30, Seymour J Metz  wrote:
> >
> > Not all change is progress, nor does an ad hominem argument bolster
> your case. Neither does constructing straw dummies. "New is bad.  Different
> is bad." is a free construct of your imagination, unrelated to anything
> that anybody here wrote.
> >
> > Are their objections valid? I don't know, but misrepresenting them won't
> convince anybody that they're wrong.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > https://nam03.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g
> > mu.edu%2F~smetz3data=02%7C01%7Crmccabe%40MUTUALOFENUMCLAW.COM%7Ca
> > 1e943177ffc4f2d25da08d819fd702e%7C5a381f7dcc3d4a93b2cbd2fd072e535a%7C1
> > %7C0%7C637287923585463930sdata=SjLcLbjqGR3mfHqipZQ1m9cCXLbjpal983
> > ru177s4ow%3Dreserved=0
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> > behalf of Henri Kuiper [henrikui...@zdevops.com]
> > Sent: Friday, June 26, 2020 12:57 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: New Mainframe Community
> >
> > Wow. What a lot of pushback.
> >
> > This is (IMHO) precisely what’s wrong with the (generic average)
> mainframe community. New is bad.  Different is bad.
> >
> > Dudes (m/f) : it’s not the 80s anymore.
> >
> > That being said : here’s a little “why” for the existence of the thing
> > :
> > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecu
> > re-web.cisco.com%2F1XvN1_V6ok1sJNlFaq7Z343XlW_wRn1pLUP1SgDYhckTcNv1FTR
> > NKBGu8BhJjyQFtzWCCdxOEkvQnVbzjpkqyIRWBMVMKO5NSI-_UQmV1T4GP85WyNx0I4tfX
> > KY1GyyBAr7-13umt61eWdwZnJ4bmDSMkvpmk0_byLSjeOa645E40X2BFl2gbfYLVB5tGPd
> > 17bav80BvBMpmwbZflaSxkwRKCxNL5XcRfUQPMhpXZWZmUKY1zXMYL7_BESm8M2UUp15ds
> > c7B9m8yYh98BuxkEmTbrJsw_AtpWxwk9--8dv2iecdL4nxNDhXzCt6cDHOu1q85TVJ2MqE
> > pSo446EYbJAKC4r5vEuKvLDlI1DJ2XnTNZopVXqx9eofDzOzd8aDo1iWe_YjyhkhxGMZSC
> > 3vWLVdzgWUvbc1ciqLqZXVnjecO_3YH03XnqCv8Bk5um6Tm4%2Fhttps%253A%252F%252
> > Fzdevops.tumblr.com%252Fpost%252F620908065704853504%252Fmainframe-comm
> > unity-mattermostdata=02%7C01%7Crmccabe%40MUTUALOFENUMCLAW.COM%7Ca
> > 1e943177ffc4f2d25da08d819fd702e%7C5a381f7dcc3d4a93b2cbd2fd072e535a%7C1
> > %7C0%7C637287923585463930sdata=feh79oxBKnJUOLcX0pYmtHJwYoOABeIety
> > 9EMMxcYUM%3Dreserved=0
> >
> > That being said I’d say “traditional”  peeps like some of the reactions
> I read here should probably not even try to see what it is.
> >
> > There’s no punch cards. No bus But an easy, modern, new (young)
> blood friendly environment where about 100 peeps are having some fun
> discussing mainframe things.
> >
> > No hard feelings.
> >
> > And a happy weekend !
> >
> >
> >
> > Sent from my wireless iPhone
> >
> >> On 17 Jun 2020, at 01:12, Peter Bishop  wrote:
> >>
> >> Hi Carmen,
> >>
> >> "there's no such thing as a dumb question" comes to mind.  No need for
> any corner for you.  I also learned a bit of history and now know why that
> site Kolosu mentioned looks like so much rubbish now...
> >>
> >> cheers,
> >> Peter
> >>
>  On 16/06/2020 10:31 pm, Carmen Vitullo wrote:
> >>> Kolusu, reached out to me personally and I replied to the wrong
> message and my response went to this forum, so I need more coffee.
> >>> thanks for the kind words and now that my response is 'out there' I
> have to apologize to Mark for naming names. As a novice it's sometimes
> frustrating when the company you support does not pay for Q support from
> IBM and has been so terrible to loose all their MF staff.
> >>> I've been lucky to be able to move on and learn more about design and
> build and supporting my environment.
> >>> back to my corner
> >>>
> >>>
> >>>
> >>>
> >>> - Original Message -
> >>>
> >>> From: "Lionel B Dyck" 
> >>> To: IBM-MAIN@LISTSERV.UA.EDU
> >>> Sent: Tuesday, June 16, 2020 7:24:06 AM
> >>> Subject: Re: New Mainframe Community
> >>>
> >>> Carmen - never put yourself down. While you may not be 'as smart' as
> some, I'm sure you are 'smarter' than some as well. We each bring to the
> table (forum/life) our own skills and capabilities which complement rather
> than replace those of others.
> >>>
> >>> Flames should be reserved for fires and stars, not for shaming others.
> >>>
> >>> Lionel B. Dyck <
> >>> Website:
> >>> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fse
> >>> 

Re: New Mainframe Community

[McCabe, Ron]

I know this is off topic but what does IMHO stand for?

Thanks,
Ron McCabe
Manager of Mainframe/Midrange Systems
Mutual of Enumclaw

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Henri Kuiper
Sent: Friday, June 26, 2020 11:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

CAUTION: This email is from an external address. Please be careful of links and 
attachments.


I was referring to the generic average. Not to anything anyone wrote here.

I already regret replying.

/EOT


> On 26 Jun 2020, at 19:30, Seymour J Metz  wrote:
>
> Not all change is progress, nor does an ad hominem argument bolster your 
> case. Neither does constructing straw dummies. "New is bad.  Different is 
> bad." is a free construct of your imagination, unrelated to anything that 
> anybody here wrote.
>
> Are their objections valid? I don't know, but misrepresenting them won't 
> convince anybody that they're wrong.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://nam03.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g
> mu.edu%2F~smetz3data=02%7C01%7Crmccabe%40MUTUALOFENUMCLAW.COM%7Ca
> 1e943177ffc4f2d25da08d819fd702e%7C5a381f7dcc3d4a93b2cbd2fd072e535a%7C1
> %7C0%7C637287923585463930sdata=SjLcLbjqGR3mfHqipZQ1m9cCXLbjpal983
> ru177s4ow%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Henri Kuiper [henrikui...@zdevops.com]
> Sent: Friday, June 26, 2020 12:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: New Mainframe Community
>
> Wow. What a lot of pushback.
>
> This is (IMHO) precisely what’s wrong with the (generic average)  mainframe 
> community. New is bad.  Different is bad.
>
> Dudes (m/f) : it’s not the 80s anymore.
>
> That being said : here’s a little “why” for the existence of the thing
> :
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecu
> re-web.cisco.com%2F1XvN1_V6ok1sJNlFaq7Z343XlW_wRn1pLUP1SgDYhckTcNv1FTR
> NKBGu8BhJjyQFtzWCCdxOEkvQnVbzjpkqyIRWBMVMKO5NSI-_UQmV1T4GP85WyNx0I4tfX
> KY1GyyBAr7-13umt61eWdwZnJ4bmDSMkvpmk0_byLSjeOa645E40X2BFl2gbfYLVB5tGPd
> 17bav80BvBMpmwbZflaSxkwRKCxNL5XcRfUQPMhpXZWZmUKY1zXMYL7_BESm8M2UUp15ds
> c7B9m8yYh98BuxkEmTbrJsw_AtpWxwk9--8dv2iecdL4nxNDhXzCt6cDHOu1q85TVJ2MqE
> pSo446EYbJAKC4r5vEuKvLDlI1DJ2XnTNZopVXqx9eofDzOzd8aDo1iWe_YjyhkhxGMZSC
> 3vWLVdzgWUvbc1ciqLqZXVnjecO_3YH03XnqCv8Bk5um6Tm4%2Fhttps%253A%252F%252
> Fzdevops.tumblr.com%252Fpost%252F620908065704853504%252Fmainframe-comm
> unity-mattermostdata=02%7C01%7Crmccabe%40MUTUALOFENUMCLAW.COM%7Ca
> 1e943177ffc4f2d25da08d819fd702e%7C5a381f7dcc3d4a93b2cbd2fd072e535a%7C1
> %7C0%7C637287923585463930sdata=feh79oxBKnJUOLcX0pYmtHJwYoOABeIety
> 9EMMxcYUM%3Dreserved=0
>
> That being said I’d say “traditional”  peeps like some of the reactions I 
> read here should probably not even try to see what it is.
>
> There’s no punch cards. No bus But an easy, modern, new (young) blood 
> friendly environment where about 100 peeps are having some fun discussing 
> mainframe things.
>
> No hard feelings.
>
> And a happy weekend !
>
>
>
> Sent from my wireless iPhone
>
>> On 17 Jun 2020, at 01:12, Peter Bishop  wrote:
>>
>> Hi Carmen,
>>
>> "there's no such thing as a dumb question" comes to mind.  No need for any 
>> corner for you.  I also learned a bit of history and now know why that site 
>> Kolosu mentioned looks like so much rubbish now...
>>
>> cheers,
>> Peter
>>
 On 16/06/2020 10:31 pm, Carmen Vitullo wrote:
>>> Kolusu, reached out to me personally and I replied to the wrong message and 
>>> my response went to this forum, so I need more coffee.
>>> thanks for the kind words and now that my response is 'out there' I have to 
>>> apologize to Mark for naming names. As a novice it's sometimes frustrating 
>>> when the company you support does not pay for Q support from IBM and has 
>>> been so terrible to loose all their MF staff.
>>> I've been lucky to be able to move on and learn more about design and build 
>>> and supporting my environment.
>>> back to my corner
>>>
>>>
>>>
>>>
>>> - Original Message -
>>>
>>> From: "Lionel B Dyck" 
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Sent: Tuesday, June 16, 2020 7:24:06 AM
>>> Subject: Re: New Mainframe Community
>>>
>>> Carmen - never put yourself down. While you may not be 'as smart' as some, 
>>> I'm sure you are 'smarter' than some as well. We each bring to the table 
>>> (forum/life) our own skills and capabilities which complement rather than 
>>> replace those of others.
>>>
>>> Flames should be reserved for fires and stars, not for shaming others.
>>>
>>> Lionel B. Dyck <
>>> Website:
>>> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fse
>>> cure-web.cisco.com%2F1yULUSmjcKu0JnI82-5pjv0k_Bny1yocXQ9O03xc8h1NKHo
>>> p6zLYzmNDxJ6z8LbrWzqNKRE7ptnw5iOhkRQ2c8tlxUmxWlMCHga0Sh61wLJ5v7tIB3F
>>> Pgl7P0FZbnO2IGRvYoNImo91L3m4-Nh3nMPatReD2DgXqFRZJCuAAK6hvnhfK5RfaTyv
>>> 

Re: New Mainframe Community

[Henri Kuiper]

I was referring to the generic average. Not to anything anyone wrote here. 

I already regret replying. 

/EOT


> On 26 Jun 2020, at 19:30, Seymour J Metz  wrote:
> 
> Not all change is progress, nor does an ad hominem argument bolster your 
> case. Neither does constructing straw dummies. "New is bad.  Different is 
> bad." is a free construct of your imagination, unrelated to anything that 
> anybody here wrote.
> 
> Are their objections valid? I don't know, but misrepresenting them won't 
> convince anybody that they're wrong.
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Henri Kuiper [henrikui...@zdevops.com]
> Sent: Friday, June 26, 2020 12:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: New Mainframe Community
> 
> Wow. What a lot of pushback.
> 
> This is (IMHO) precisely what’s wrong with the (generic average)  mainframe 
> community. New is bad.  Different is bad.
> 
> Dudes (m/f) : it’s not the 80s anymore.
> 
> That being said : here’s a little “why” for the existence of the thing : 
> https://secure-web.cisco.com/1XvN1_V6ok1sJNlFaq7Z343XlW_wRn1pLUP1SgDYhckTcNv1FTRNKBGu8BhJjyQFtzWCCdxOEkvQnVbzjpkqyIRWBMVMKO5NSI-_UQmV1T4GP85WyNx0I4tfXKY1GyyBAr7-13umt61eWdwZnJ4bmDSMkvpmk0_byLSjeOa645E40X2BFl2gbfYLVB5tGPd17bav80BvBMpmwbZflaSxkwRKCxNL5XcRfUQPMhpXZWZmUKY1zXMYL7_BESm8M2UUp15dsc7B9m8yYh98BuxkEmTbrJsw_AtpWxwk9--8dv2iecdL4nxNDhXzCt6cDHOu1q85TVJ2MqEpSo446EYbJAKC4r5vEuKvLDlI1DJ2XnTNZopVXqx9eofDzOzd8aDo1iWe_YjyhkhxGMZSC3vWLVdzgWUvbc1ciqLqZXVnjecO_3YH03XnqCv8Bk5um6Tm4/https%3A%2F%2Fzdevops.tumblr.com%2Fpost%2F620908065704853504%2Fmainframe-community-mattermost
> 
> That being said I’d say “traditional”  peeps like some of the reactions I 
> read here should probably not even try to see what it is.
> 
> There’s no punch cards. No bus But an easy, modern, new (young) blood 
> friendly environment where about 100 peeps are having some fun discussing 
> mainframe things.
> 
> No hard feelings.
> 
> And a happy weekend !
> 
> 
> 
> Sent from my wireless iPhone
> 
>> On 17 Jun 2020, at 01:12, Peter Bishop  wrote:
>> 
>> Hi Carmen,
>> 
>> "there's no such thing as a dumb question" comes to mind.  No need for any 
>> corner for you.  I also learned a bit of history and now know why that site 
>> Kolosu mentioned looks like so much rubbish now...
>> 
>> cheers,
>> Peter
>> 
 On 16/06/2020 10:31 pm, Carmen Vitullo wrote:
>>> Kolusu, reached out to me personally and I replied to the wrong message and 
>>> my response went to this forum, so I need more coffee.
>>> thanks for the kind words and now that my response is 'out there' I have to 
>>> apologize to Mark for naming names. As a novice it's sometimes frustrating 
>>> when the company you support does not pay for Q support from IBM and has 
>>> been so terrible to loose all their MF staff.
>>> I've been lucky to be able to move on and learn more about design and build 
>>> and supporting my environment.
>>> back to my corner
>>> 
>>> 
>>> 
>>> 
>>> - Original Message -
>>> 
>>> From: "Lionel B Dyck" 
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Sent: Tuesday, June 16, 2020 7:24:06 AM
>>> Subject: Re: New Mainframe Community
>>> 
>>> Carmen - never put yourself down. While you may not be 'as smart' as some, 
>>> I'm sure you are 'smarter' than some as well. We each bring to the table 
>>> (forum/life) our own skills and capabilities which complement rather than 
>>> replace those of others.
>>> 
>>> Flames should be reserved for fires and stars, not for shaming others.
>>> 
>>> Lionel B. Dyck <
>>> Website: 
>>> https://secure-web.cisco.com/1yULUSmjcKu0JnI82-5pjv0k_Bny1yocXQ9O03xc8h1NKHop6zLYzmNDxJ6z8LbrWzqNKRE7ptnw5iOhkRQ2c8tlxUmxWlMCHga0Sh61wLJ5v7tIB3FPgl7P0FZbnO2IGRvYoNImo91L3m4-Nh3nMPatReD2DgXqFRZJCuAAK6hvnhfK5RfaTyvdaxOGJO4RNHceQLytnjeMBaKC3SMbn2yACSsavfpWOzE1mSGe1rcML2-AvSd1pjmNwBoxRVhoiZXC_c1-RH3PG1QbOpmEwn9xD8ZhTQaJ1YoOVwo7jPVe_TeQVImE1vLNSIANkZwdjnp353SoqsOUka5CLnJ_BuoPXfoyGBoGe5KoPrn38nbp4M74Ba6OX1BKixY7lwHU1zSwreweMWT2oGDOfwBaNk9UcVYlwTboFQ37Nebqh99zBGO-q35f0ruDBXMtYAayr/https%3A%2F%2Fwww.lbdsoftware.com
>>> 
>>> "Worry more about your character than your reputation. Character is what 
>>> you are, reputation merely what others think you are." - John Wooden
>>> 
>>> -Original Message-
>>> From: IBM Mainframe Discussion List  On Behalf Of 
>>> Carmen Vitullo
>>> Sent: Tuesday, June 16, 2020 7:17 AM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: New Mainframe Community
>>> 
>>> Kolusu, thank you for the history lesson, I personally would never 
>>> 'advertise' (suggest) this site if I knew how low some folks will go to 
>>> sell answers, I know of a couple of industries that do this, ask.com, I 
>>> think was the first site I ever came across that you could ask a question 
>>> and for a nominal price get an answer.
>>> As I mentioned, being a novice myself at one time, I needed help with 

Re: DASD migration -- Re: Hitachi RAID box going out of support

[Ken Bloom]

Hi. 

If you are interested in upgrading your dasd, you may want to consider the 
visara VI-8810.  It’s rack mounted, SSD drives, compatible with all IBM OS and 
processors.   Will certainly work with your Z9  

Contact me offline and you can tell me what you require in terms of channels 
and storage and we can go from there. 

Regards
Ken


Kenneth A. Bloom
Avenir Technologies Inc
/d/b/a Visara International
203-984-2235
bl...@visara.com
www.visara.com


> On Jun 26, 2020, at 11:33 AM, Grant Taylor 
> <023065957af1-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On 6/26/20 9:18 AM, Carmen Vitullo wrote:
>> it's not that difficult and most vendor will provide a migration solution 
>> depending on your requirements .
> 
> Do the vendors support migrating between vendors?  Or is this vendor specific?
> 
>> some provide a tool to replicate the data, flip the switch (figuratively) 
>> and you are now running on the new DASD subsystem. (once DASD is cabled and 
>> new GEN is activated)
> 
> I was naively thinking that there might be a way to do this within z/OS.
> 
> AIX / Linux / Solaris / Windows offer an ability to add new disks to 
> (special) storage volumes, copy / migrate data between them, and remove the 
> old disks, all as part of contemporary OS versions.
> 
> Special meaning that the storage is provisioned with this in mind in the 
> beginning.  Each OS is slightly different in this.
> 
> Note how this is done at the OS level and does not require external vendor 
> support.
> 
> Does z/OS have anything similar?  Or is storage fundamentally different?
> 
>> I've been a part of a couple different migrations at different shops, all 
>> were non disruptive.
> 
> :-)
> 
>> as with any new subsystem, you need to make sure you have the toleration 
>> maint for the subsystem you are installing, and the functions/features you 
>> are going to use, P2PRCfor example
> 
> Prerequisites always exist.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 
> --
> 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: DASD migration -- Re: Hitachi RAID box going out of support

[Jesse 1 Robinson]

We do this fairly frequently because we typically replace DASD at end of 
warranty so that cost is capital expense rather than O It's never trivial 
but has gotten easier over the decades. There two main areas of complexity 
depending on your configuration. 

1. If you share DASD subsystems among LPARs/sysplexes, you have tricky 
maneuvers to execute. 

2. For active volumes, you have to coordinate moves so as not to lose updates 
in the process. 

Our most important tool for this purpose is TDMF. We were early adopters ages 
ago; now owned by IBM. I still think of it as smoke and mirrors magic. It 
dynamically moves a volume from one location to another with no outage. Quite 
remarkable. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Carmen Vitullo
Sent: Friday, June 26, 2020 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: DASD migration -- Re: Hitachi RAID box going out of 
support

CAUTION EXTERNAL EMAIL

Carmen Vitullo

- Original Message -

From: "Grant Taylor" <023065957af1-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Friday, June 26, 2020 10:33:02 AM
Subject: Re: DASD migration -- Re: Hitachi RAID box going out of support

On 6/26/20 9:18 AM, Carmen Vitullo wrote:
> it's not that difficult and most vendor will provide a migration 
> solution depending on your requirements .

Do the vendors support migrating between vendors? Or is this vendor specific?
yes, one vendor I used migrated from DASD from company A to DASD from company B.


we used a third party vendor that is a partner with IBM and we used FDR for one 
migration to migrate the DATA but as others have said, there are a number of 
tools that run on Z that can migrate the data for you seamlessly one vendor 
provided a solution when the box was replicated without the need to run 
anything on Z,

> some provide a tool to replicate the data, flip the switch
> (figuratively) and you are now running on the new DASD subsystem.
> (once DASD is cabled and new GEN is activated)

I was naively thinking that there might be a way to do this within z/OS.


there is, but most resellers provide services and tools to aid in the migration 
or do the migration for you.
very simple to use DFSMS/DSS ADRDSSU to copy and flip the volser if you choose 
to do this yourself

AIX / Linux / Solaris / Windows offer an ability to add new disks to
(special) storage volumes, copy / migrate data between them, and remove the old 
disks, all as part of contemporary OS versions.

Special meaning that the storage is provisioned with this in mind in the 
beginning. Each OS is slightly different in this.

Note how this is done at the OS level and does not require external vendor 
support.

pretty much the same for Z..
Does z/OS have anything similar? Or is storage fundamentally different?


depending on your requirements the storage can be partitioned the way you like, 
most sites I've worked all DASD was used in a production environment containing 
volumes within storage pools, every site is different.
we currently have a # of UCB's available to use and a limit of storage, if I 
need more storage, I add more volumes to a storage pool, simply put.

> I've been a part of a couple different migrations at different shops, 
> all were non disruptive.

:-)

> as with any new subsystem, you need to make sure you have the 
> toleration maint for the subsystem you are installing, and the 
> functions/features you are going to use, P2PRCfor example

Prerequisites always exist.



--
Grant. . . .
unix || die

--
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: New Mainframe Community

[Seymour J Metz]

Not all change is progress, nor does an ad hominem argument bolster your case. 
Neither does constructing straw dummies. "New is bad.  Different is bad." is a 
free construct of your imagination, unrelated to anything that anybody here 
wrote.

Are their objections valid? I don't know, but misrepresenting them won't 
convince anybody that they're wrong.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Henri Kuiper [henrikui...@zdevops.com]
Sent: Friday, June 26, 2020 12:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: New Mainframe Community

Wow. What a lot of pushback.

This is (IMHO) precisely what’s wrong with the (generic average)  mainframe 
community. New is bad.  Different is bad.

Dudes (m/f) : it’s not the 80s anymore.

That being said : here’s a little “why” for the existence of the thing : 
https://secure-web.cisco.com/1XvN1_V6ok1sJNlFaq7Z343XlW_wRn1pLUP1SgDYhckTcNv1FTRNKBGu8BhJjyQFtzWCCdxOEkvQnVbzjpkqyIRWBMVMKO5NSI-_UQmV1T4GP85WyNx0I4tfXKY1GyyBAr7-13umt61eWdwZnJ4bmDSMkvpmk0_byLSjeOa645E40X2BFl2gbfYLVB5tGPd17bav80BvBMpmwbZflaSxkwRKCxNL5XcRfUQPMhpXZWZmUKY1zXMYL7_BESm8M2UUp15dsc7B9m8yYh98BuxkEmTbrJsw_AtpWxwk9--8dv2iecdL4nxNDhXzCt6cDHOu1q85TVJ2MqEpSo446EYbJAKC4r5vEuKvLDlI1DJ2XnTNZopVXqx9eofDzOzd8aDo1iWe_YjyhkhxGMZSC3vWLVdzgWUvbc1ciqLqZXVnjecO_3YH03XnqCv8Bk5um6Tm4/https%3A%2F%2Fzdevops.tumblr.com%2Fpost%2F620908065704853504%2Fmainframe-community-mattermost

That being said I’d say “traditional”  peeps like some of the reactions I read 
here should probably not even try to see what it is.

There’s no punch cards. No bus But an easy, modern, new (young) blood 
friendly environment where about 100 peeps are having some fun discussing 
mainframe things.

No hard feelings.

And a happy weekend !



Sent from my wireless iPhone

> On 17 Jun 2020, at 01:12, Peter Bishop  wrote:
>
> Hi Carmen,
>
> "there's no such thing as a dumb question" comes to mind.  No need for any 
> corner for you.  I also learned a bit of history and now know why that site 
> Kolosu mentioned looks like so much rubbish now...
>
> cheers,
> Peter
>
>> On 16/06/2020 10:31 pm, Carmen Vitullo wrote:
>> Kolusu, reached out to me personally and I replied to the wrong message and 
>> my response went to this forum, so I need more coffee.
>> thanks for the kind words and now that my response is 'out there' I have to 
>> apologize to Mark for naming names. As a novice it's sometimes frustrating 
>> when the company you support does not pay for Q support from IBM and has 
>> been so terrible to loose all their MF staff.
>> I've been lucky to be able to move on and learn more about design and build 
>> and supporting my environment.
>> back to my corner
>>
>>
>>
>>
>> - Original Message -
>>
>> From: "Lionel B Dyck" 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Sent: Tuesday, June 16, 2020 7:24:06 AM
>> Subject: Re: New Mainframe Community
>>
>> Carmen - never put yourself down. While you may not be 'as smart' as some, 
>> I'm sure you are 'smarter' than some as well. We each bring to the table 
>> (forum/life) our own skills and capabilities which complement rather than 
>> replace those of others.
>>
>> Flames should be reserved for fires and stars, not for shaming others.
>>
>> Lionel B. Dyck <
>> Website: 
>> https://secure-web.cisco.com/1yULUSmjcKu0JnI82-5pjv0k_Bny1yocXQ9O03xc8h1NKHop6zLYzmNDxJ6z8LbrWzqNKRE7ptnw5iOhkRQ2c8tlxUmxWlMCHga0Sh61wLJ5v7tIB3FPgl7P0FZbnO2IGRvYoNImo91L3m4-Nh3nMPatReD2DgXqFRZJCuAAK6hvnhfK5RfaTyvdaxOGJO4RNHceQLytnjeMBaKC3SMbn2yACSsavfpWOzE1mSGe1rcML2-AvSd1pjmNwBoxRVhoiZXC_c1-RH3PG1QbOpmEwn9xD8ZhTQaJ1YoOVwo7jPVe_TeQVImE1vLNSIANkZwdjnp353SoqsOUka5CLnJ_BuoPXfoyGBoGe5KoPrn38nbp4M74Ba6OX1BKixY7lwHU1zSwreweMWT2oGDOfwBaNk9UcVYlwTboFQ37Nebqh99zBGO-q35f0ruDBXMtYAayr/https%3A%2F%2Fwww.lbdsoftware.com
>>
>> "Worry more about your character than your reputation. Character is what you 
>> are, reputation merely what others think you are." - John Wooden
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Carmen Vitullo
>> Sent: Tuesday, June 16, 2020 7:17 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: New Mainframe Community
>>
>> Kolusu, thank you for the history lesson, I personally would never 
>> 'advertise' (suggest) this site if I knew how low some folks will go to sell 
>> answers, I know of a couple of industries that do this, ask.com, I think was 
>> the first site I ever came across that you could ask a question and for a 
>> nominal price get an answer.
>> As I mentioned, being a novice myself at one time, I needed help with a 
>> SYSPLEX issue, I asked here, well, IBM-MAIN, and no one paid attention, at 
>> the time the hot topic for MVS folks was Windows related, I pointed that out 
>> that this was a MAINFRAME forum and was immediately shamed and flamed by 
>> Mark Zelden + others , that was the only reason why I came across that other 
>> site .
>> 

Re: New Mainframe Community

[Henri Kuiper]

Wow. What a lot of pushback. 

This is (IMHO) precisely what’s wrong with the (generic average)  mainframe 
community. New is bad.  Different is bad. 

Dudes (m/f) : it’s not the 80s anymore. 

That being said : here’s a little “why” for the existence of the thing : 
https://zdevops.tumblr.com/post/620908065704853504/mainframe-community-mattermost

That being said I’d say “traditional”  peeps like some of the reactions I read 
here should probably not even try to see what it is. 

There’s no punch cards. No bus But an easy, modern, new (young) blood 
friendly environment where about 100 peeps are having some fun discussing 
mainframe things. 

No hard feelings. 

And a happy weekend !



Sent from my wireless iPhone

> On 17 Jun 2020, at 01:12, Peter Bishop  wrote:
> 
> Hi Carmen,
> 
> "there's no such thing as a dumb question" comes to mind.  No need for any 
> corner for you.  I also learned a bit of history and now know why that site 
> Kolosu mentioned looks like so much rubbish now...
> 
> cheers,
> Peter
> 
>> On 16/06/2020 10:31 pm, Carmen Vitullo wrote:
>> Kolusu, reached out to me personally and I replied to the wrong message and 
>> my response went to this forum, so I need more coffee.
>> thanks for the kind words and now that my response is 'out there' I have to 
>> apologize to Mark for naming names. As a novice it's sometimes frustrating 
>> when the company you support does not pay for Q support from IBM and has 
>> been so terrible to loose all their MF staff.
>> I've been lucky to be able to move on and learn more about design and build 
>> and supporting my environment.
>> back to my corner
>> 
>> 
>> 
>> 
>> - Original Message -
>> 
>> From: "Lionel B Dyck" 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Sent: Tuesday, June 16, 2020 7:24:06 AM
>> Subject: Re: New Mainframe Community
>> 
>> Carmen - never put yourself down. While you may not be 'as smart' as some, 
>> I'm sure you are 'smarter' than some as well. We each bring to the table 
>> (forum/life) our own skills and capabilities which complement rather than 
>> replace those of others.
>> 
>> Flames should be reserved for fires and stars, not for shaming others.
>> 
>> Lionel B. Dyck <
>> Website: https://www.lbdsoftware.com
>> 
>> "Worry more about your character than your reputation. Character is what you 
>> are, reputation merely what others think you are." - John Wooden
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf Of 
>> Carmen Vitullo
>> Sent: Tuesday, June 16, 2020 7:17 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: New Mainframe Community
>> 
>> Kolusu, thank you for the history lesson, I personally would never 
>> 'advertise' (suggest) this site if I knew how low some folks will go to sell 
>> answers, I know of a couple of industries that do this, ask.com, I think was 
>> the first site I ever came across that you could ask a question and for a 
>> nominal price get an answer.
>> As I mentioned, being a novice myself at one time, I needed help with a 
>> SYSPLEX issue, I asked here, well, IBM-MAIN, and no one paid attention, at 
>> the time the hot topic for MVS folks was Windows related, I pointed that out 
>> that this was a MAINFRAME forum and was immediately shamed and flamed by 
>> Mark Zelden + others , that was the only reason why I came across that other 
>> site .
>> I've been a SYSPROG since 1993 came up from operations, I'm not as smart as 
>> most here but I do try and provide help when I can, and continue to read the 
>> Q+A here.
>> again thanks for reaching out to me and not shaming me more on the forum
>> 
>> Carmen Vitullo
>> 
>> - Original Message -
>> 
>> From: "Sri h Kolusu" 
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Sent: Monday, June 15, 2020 1:01:41 PM
>> Subject: Re: New Mainframe Community
>> 
>>> well then - they miss out on me, I've got free answers, and I know a
>>> lot of folks - beginners mostly that received good help.
>> I was a member of those sites and provided numerous answers (skolusu) and 
>> quit when they started forcing ads.
>> 
>>> I have much more work to do than research other sites.
>> I only pointed out because you are promoting a sham site. Nothing against 
>> you.
>> 
>> 
>> Thanks,
>> Kolusu
>> 
>> --
>> 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 

Re: SDSF CPU L/Z

[Shaffer, Terri]

I find is odd in my 34 years as a sysprog this has always been true or pretty 
close and now its not.  Not saying I don't believe that you are telling me just 
not what I am seeing..

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 Rob 
Scott
Sent: Friday, June 26, 2020 11:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri,

I think the SDSF doc could be a bit clearer in this area, but the numbers you 
quoted do not mean what you think they mean.

There is some extra help text in the "CPU and SIO fields" section of the help 
for the DA command (at the end of the help for the content of the fields).

Taking the  xx/yy numbers :

(o) xx - This is SRM's native view of CPU% busy of the local system without 
factoring in any LPAR weights from PR/SM.
For example, if over a period of 100 seconds, PR/SM gave this system a grand 
total of 10 CPU seconds (and 90 seconds to other LPARs) and this system was 
busy for 5 seconds then the CPU% would be 50%. Think of this as a SRM being 
blissfully unaware of other LPARs in the CEC and behaving like an old-school 
single MVS system.

(o) yy - This is the CPU% factoring in LPAR weighting.
Using the above trivial example, this would be 5.

SDSF does not perform any calculations in this area - we just report what we 
get back from RMF for these two numbers.

I will look to see if we can improve the help text.

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 3:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Thanks Rob,
So NO to the first 2, as we run with hardly any usermods or customizations.

Number 3 is partially true. The 2 UBS2T* Jobs are running on ACW5, But that is 
reflected by the 45/29 number is my display. 45 is my total across the sysplex 
and 29 is the local lpar.

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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri,

The native SDSF 2.2 code populates the title line from the local system CPU 
usage.

A couple of possibilities exist that could explain what you are seeing :


1. You have an ISFUSER exit that alters the title line (possible - but not 
common) 2. You have a local replacement/modification for ERBSMFI or ERB2XDGS on 
your 2.2 system that is not installed on your 2.4 system (unlikely).
3. Your 2.2 system is getting the lion's share of CPU resources (maybe via LPAR 
definitions), or is naturally a much busier system so that it permanently shows 
a higher local CPU% which does not look out of place when SYSNAME=* is in 
effect and you sort DA by CPU% descending.

If none of the above apply, please feel free to update the PMR and maybe we can 
take a look at some trace options and other diagnostics.

Rob

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Rob,
My question, was does anyone else see this behavior? And yes that was my point 
of sysname=* I think it should total all lpars, like I see in my z/OS 2.2 lpar 
and display.

But you can see in my z/OS 2.4 lpar, I only get an lpar view.

And yes I opened up the SR because it looked like an issue, but from what she 
stated and you said its working as designed, but not what I see.

I can also tell my cut/paste because IBM list doesn't maintain columns you cant 
really tell the CPU column.


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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>>
 On Behalf Of Rob Scott
Sent: Friday, June 26, 2020 8:47 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

External Email


Terri

You have SYSNAME set to "*" - which means the rows are for all address spaces 
on all systems.

The title line only shows CPU% for the local system.

You also state that you are seeing a discrepancy in 2.3, however the 2.3 DA 
code uses the same methods as 2.2.

I see that you 

Re: DASD migration -- Re: Hitachi RAID box going out of support

[Carmen Vitullo]

Carmen Vitullo 

- Original Message -

From: "Grant Taylor" <023065957af1-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, June 26, 2020 10:33:02 AM 
Subject: Re: DASD migration -- Re: Hitachi RAID box going out of support 

On 6/26/20 9:18 AM, Carmen Vitullo wrote: 
> it's not that difficult and most vendor will provide a migration 
> solution depending on your requirements . 

Do the vendors support migrating between vendors? Or is this vendor 
specific? 
yes, one vendor I used migrated from DASD from company A to DASD from company 
B. 


we used a third party vendor that is a partner with IBM and we used FDR for one 
migration to migrate the DATA but as others have said, there are a number of 
tools that run on Z that can migrate the data for you seamlessly 
one vendor provided a solution when the box was replicated without the need to 
run anything on Z, 

> some provide a tool to replicate the data, flip the switch 
> (figuratively) and you are now running on the new DASD subsystem. 
> (once DASD is cabled and new GEN is activated) 

I was naively thinking that there might be a way to do this within z/OS. 


there is, but most resellers provide services and tools to aid in the migration 
or do the migration for you. 
very simple to use DFSMS/DSS ADRDSSU to copy and flip the volser if you choose 
to do this yourself 

AIX / Linux / Solaris / Windows offer an ability to add new disks to 
(special) storage volumes, copy / migrate data between them, and remove 
the old disks, all as part of contemporary OS versions. 

Special meaning that the storage is provisioned with this in mind in the 
beginning. Each OS is slightly different in this. 

Note how this is done at the OS level and does not require external 
vendor support. 

pretty much the same for Z.. 
Does z/OS have anything similar? Or is storage fundamentally different? 


depending on your requirements the storage can be partitioned the way you like, 
most sites I've worked 
all DASD was used in a production environment containing volumes within storage 
pools, every site is different. 
we currently have a # of UCB's available to use and a limit of storage, if I 
need more storage, I add more volumes to a storage pool, simply put. 

> I've been a part of a couple different migrations at different shops, 
> all were non disruptive. 

:-) 

> as with any new subsystem, you need to make sure you have the 
> toleration maint for the subsystem you are installing, and the 
> functions/features you are going to use, P2PRCfor example 

Prerequisites always exist. 



-- 
Grant. . . . 
unix || die 

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


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

Re: [EXTERNAL] DASD migration -- Re: Hitachi RAID box going out of support

[R.S.]

Simply no.
4Gbps can work with 4, 8 and 16Gbps interface on the other end. I think 
even current newest Hitachi DASD boxes may have 16Gbps interfaces, not 
32Gbps as the only choice.


Last, but not least: DIRECTOR. FICON switch allows to connect any to any 
speed. Yes, including 1Gbps to 32Gbps.
More obviously one can connect 4Gbps FICON port to a switch with any 
(2,4,8,16) SFP and this port can connect to a dasd box connected in 
similar way, lets say 32Gbps device port connected to 16Gbps SFP. The 
switch can "transmit" FICON traffic from any to any port, despite of SFP 
speed.


The "window of compatibility" apply to physical fiber optic link and 
transceivers on both ends (SFPs). The window is "n-2", which means 1Gbps 
will talk to 1, 2, 4Gbps. 2Gbps will talk to 2, 4, 8 Gbps. 4Gbps will 
talk to 4, 8, 16 Gbps.


Note, there are other things to consider, but it regards very old CUs 
and microcode - older than z9. AFAIK the change was in z196 machine.


--
Radoslaw Skorupka
Lodz, Poland







W dniu 26.06.2020 o 17:09, Bill Bishop (TMNA) pisze:

One issue that you may encounter with going to a new storage system on a z9 
processor is the speed of the ficon cards and whether the new unit can z9 
cards.  I am not sure the new Hitachi's can work with 4GB ficon.

I would make sure that if you replace it, with whichever vendor, that the new 
unit can work with those old z9 cards.

Thanks

Bill Bishop
Consultant, Mainframe Engineer
Mainframe and Scheduling | Infrastructure Technology Services
Toyota Motor North America
  bill.bis...@toyota.com
Office:  (469) 292-5149
Cell:  (502) 316-4386

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Grant Taylor
Sent: Friday, June 26, 2020 10:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] DASD migration -- Re: Hitachi RAID box going out of support

On 6/26/20 3:16 AM, R.S. wrote:

3. 18 months is close to half of typical service contract for new dasd
array. Still we don't know how sure is 18 months - maybe it would be
36 months? Even 12 months means the dasd array would have some residual value.

n00b questions:

1)  Is it possible to migrate from old DASD to new DASD?

2)  How disruptive would this be to the day-to-day operation of the existing 
mainframe?

3)  What sort of prerequisites exist for this?

I have some experience with this in the Open Systems environment, but I'd like 
to know more about how such a storage migration would be done in the mainframe 
world.





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: DASD migration -- Re: Hitachi RAID box going out of support

[Grant Taylor]

On 6/26/20 9:18 AM, Carmen Vitullo wrote:
it's not that difficult and most vendor will provide a migration 
solution depending on your requirements .


Do the vendors support migrating between vendors?  Or is this vendor 
specific?


some provide a tool to replicate the data, flip the switch 
(figuratively) and you are now running on the new DASD subsystem. 
(once DASD is cabled and new GEN is activated)


I was naively thinking that there might be a way to do this within z/OS.

AIX / Linux / Solaris / Windows offer an ability to add new disks to 
(special) storage volumes, copy / migrate data between them, and remove 
the old disks, all as part of contemporary OS versions.


Special meaning that the storage is provisioned with this in mind in the 
beginning.  Each OS is slightly different in this.


Note how this is done at the OS level and does not require external 
vendor support.


Does z/OS have anything similar?  Or is storage fundamentally different?

I've been a part of a couple different migrations at different shops, 
all were non disruptive.


:-)

as with any new subsystem, you need to make sure you have the 
toleration maint for the subsystem you are installing, and the 
functions/features you are going to use, P2PRCfor example


Prerequisites always exist.



--
Grant. . . .
unix || die

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

Re: DASD migration

[Bill Bishop (TMNA)]

My units are all directed connected, no switches.  

The issue is how far down can the newer storage units go down on the speed 
charts as they are designed to run at 8 and 16 GB.  I don't know that all of 
the newer units can slow do to 4 GB.

Thanks

Bill Bishop
Consultant, Mainframe Engineer
Mainframe and Scheduling | Infrastructure Technology Services 
Toyota Motor North America
 bill.bis...@toyota.com
Office:  (469) 292-5149
Cell:  (502) 316-4386

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Grant Taylor
Sent: Friday, June 26, 2020 10:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DASD migration

On 6/26/20 9:09 AM, Bill Bishop (TMNA) wrote:
> One issue that you may encounter with going to a new storage system on 
> a z9 processor is the speed of the ficon cards and whether the new 
> unit can z9 cards.  I am not sure the new Hitachi's can work with 4GB ficon.

I would naively assume that the FICON switch (director?) would facilitate speed 
conversion.  Is that an incorrect assumption?



-- 
Grant. . . .
unix || die

--
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: DASD migration -- Re: Hitachi RAID box going out of support

[R.S.]

W dniu 26.06.2020 o 17:04, Grant Taylor pisze:

On 6/26/20 3:16 AM, R.S. wrote:
3. 18 months is close to half of typical service contract for new 
dasd array. Still we don't know how sure is 18 months - maybe it 
would be 36 months? Even 12 months means the dasd array would have 
some residual value.


n00b questions:

1)  Is it possible to migrate from old DASD to new DASD?


Obviously YES. And it is quite simple, IMHO simpler than in distributed 
systems world.

I did it many times.


2) How disruptive would this be to the day-to-day operation of the 
existing mainframe?


Do you mean migration? For parallel sysplex it can be non-disruptive. 
However even for the most basic configuration (monoplex, no tools like 
TDMF) it can be single short night outage.




3) What sort of prerequisites exist for this?


Almost nothing except skilled personnel, maybe one or two persons.
In order to connect new DASD you need some FICON ports, but even that is 
not necessary, depending on details.




I have some experience with this in the Open Systems environment, but 
I'd like to know more about how such a storage migration would be done 
in the mainframe world.


I have some comparison to Windows world and IMHO storage migration inn 
mainframe is simple and straightforward.





--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: DASD migration

[Grant Taylor]

On 6/26/20 9:09 AM, Bill Bishop (TMNA) wrote:
One issue that you may encounter with going to a new storage system on 
a z9 processor is the speed of the ficon cards and whether the new unit 
can z9 cards.  I am not sure the new Hitachi's can work with 4GB ficon.


I would naively assume that the FICON switch (director?) would 
facilitate speed conversion.  Is that an incorrect assumption?




--
Grant. . . .
unix || die

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

Re: Hitachi RAID box going out of support

[Tony Thigpen]

You might be better off to look at "Mainframe as a Service" from one of 
the smaller providers that can keep it on the z9 but attach it to newer 
dasd.


The company I work for specializes in such, but you did not give enough 
information to even know if you are candidate for our services.


For example, I currently support one client still on OS/390, but I am 
running him on a z10 attached to a 1 year old DS8880.


(FYI, We only use real z-boxes, this is not some M$ emulated platform.)

If you want to talk, contact me off-list.

Tony Thigpen

Nightwatch RenBand wrote on 6/25/20 3:57 PM:

We have a 10 year old Hitachi RAID box which Hitachi tells us is going out
of support.  Only two applications are left of the old z9 machine but they
are critical.  Latest estimate from programmers is that they will migrate
off in 12 to 18 months.
 So, based on you folks experience, is it reasonable to pay extra for an
extended contract and keep the old box?  I know there are other options,
but this appears to be the lowest cost, and easiest.  The question is about
how older RAID boxes hold up in general.

--
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: SDSF CPU L/Z

[Martin Packer]

Source RMF fields in the help text would be, ahem, helpful. :-) And if 
they derive from MVS control blocks those field names would be useful, 
too. And if MVS gets them from indeed Diagnose 204... :-)

Cheers, Martin

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Rob Scott 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   26/06/2020 16:07
Subject:[EXTERNAL] Re: SDSF CPU L/Z
Sent by:IBM Mainframe Discussion List 



Terri,

I think the SDSF doc could be a bit clearer in this area, but the numbers 
you quoted do not mean what you think they mean.

There is some extra help text in the "CPU and SIO fields" section of the 
help for the DA command (at the end of the help for the content of the 
fields).

Taking the  xx/yy numbers :

(o) xx - This is SRM's native view of CPU% busy of the local system 
without factoring in any LPAR weights from PR/SM.
For example, if over a period of 100 seconds, PR/SM gave this system a 
grand total of 10 CPU seconds (and 90 seconds to other LPARs) and this 
system was busy for 5 seconds then the CPU% would be 50%. Think of this as 
a SRM being blissfully unaware of other LPARs in the CEC and behaving like 
an old-school single MVS system.

(o) yy - This is the CPU% factoring in LPAR weighting.
Using the above trivial example, this would be 5.

SDSF does not perform any calculations in this area - we just report what 
we get back from RMF for these two numbers.

I will look to see if we can improve the help text.

Rob

From: IBM Mainframe Discussion List  On Behalf 
Of Shaffer, Terri
Sent: Friday, June 26, 2020 3:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Thanks Rob,
So NO to the first 2, as we run with hardly any usermods or 
customizations.

Number 3 is partially true. The 2 UBS2T* Jobs are running on ACW5, But 
that is reflected by the 45/29 number is my display. 45 is my total across 
the sysplex and 29 is the local lpar.

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 mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob Scott
Sent: Friday, June 26, 2020 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri,

The native SDSF 2.2 code populates the title line from the local system 
CPU usage.

A couple of possibilities exist that could explain what you are seeing :


1. You have an ISFUSER exit that alters the title line (possible - but not 
common)
2. You have a local replacement/modification for ERBSMFI or ERB2XDGS on 
your 2.2 system that is not installed on your 2.4 system (unlikely).
3. Your 2.2 system is getting the lion's share of CPU resources (maybe via 
LPAR definitions), or is naturally a much busier system so that it 
permanently shows a higher local CPU% which does not look out of place 
when SYSNAME=* is in effect and you sort DA by CPU% descending.

If none of the above apply, please feel free to update the PMR and maybe 
we can take a look at some trace options and other diagnostics.

Rob

From: IBM Mainframe Discussion List mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Shaffer, Terri
Sent: Friday, June 26, 2020 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Rob,
My question, was does anyone else see this behavior? And yes that was my 
point of sysname=* I think it should total all lpars, like I see in my 
z/OS 2.2 lpar and display.

But you can see in my z/OS 2.4 lpar, I only get an lpar view.

And yes I opened up the SR because it looked like an issue, but from what 
she stated and you said its working as designed, but not what I see.

I can also tell my cut/paste because IBM list doesn't maintain columns you 
cant really tell the CPU column.


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 mailto:IBM-MAIN@LISTSERV.UA.EDU<
mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>> On 
Behalf Of Rob Scott
Sent: Friday, June 26, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: 

Re: DASD migration -- Re: Hitachi RAID box going out of support

[Carmen Vitullo]

it's not that difficult and most vendor will provide a migration solution 
depending on your requirements . 


some provide a tool to replicate the data, flip the switch (figuratively) and 
you are now running on the new DASD subsystem. 
(once DASD is cabled and new GEN is activated) 
I've been a part of a couple different migrations at different shops, all were 
non disruptive. 
as with any new subsystem, you need to make sure you have the toleration maint 
for the subsystem you are installing, and the functions/features you are going 
to use, P2PRCfor example 







Carmen Vitullo 

- Original Message -

From: "Grant Taylor" <023065957af1-dmarc-requ...@listserv.ua.edu> 
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, June 26, 2020 10:04:36 AM 
Subject: DASD migration -- Re: Hitachi RAID box going out of support 

On 6/26/20 3:16 AM, R.S. wrote: 
> 3. 18 months is close to half of typical service contract for new dasd 
> array. Still we don't know how sure is 18 months - maybe it would be 36 
> months? Even 12 months means the dasd array would have some residual value. 

n00b questions: 

1) Is it possible to migrate from old DASD to new DASD? 

2) How disruptive would this be to the day-to-day operation of the 
existing mainframe? 

3) What sort of prerequisites exist for this? 

I have some experience with this in the Open Systems environment, but 
I'd like to know more about how such a storage migration would be done 
in the mainframe world. 



-- 
Grant. . . . 
unix || die 

-- 
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: DASD migration -- Re: Hitachi RAID box going out of support

[Nightwatch RenBand]

There are several OEM products such as FDR from Innovation, and CA, which
can speedily migrate between different disk drive architectures.  I think
IBM utilities can do it as well, but my experience has been with the
OEM's.  In general, migration is easily solved.

On Fri, Jun 26, 2020 at 8:04 AM Grant Taylor <
023065957af1-dmarc-requ...@listserv.ua.edu> wrote:

> On 6/26/20 3:16 AM, R.S. wrote:
> > 3. 18 months is close to half of typical service contract for new dasd
> > array. Still we don't know how sure is 18 months - maybe it would be 36
> > months? Even 12 months means the dasd array would have some residual
> value.
>
> n00b questions:
>
> 1)  Is it possible to migrate from old DASD to new DASD?
>
> 2)  How disruptive would this be to the day-to-day operation of the
> existing mainframe?
>
> 3)  What sort of prerequisites exist for this?
>
> I have some experience with this in the Open Systems environment, but
> I'd like to know more about how such a storage migration would be done
> in the mainframe world.
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: [EXTERNAL] DASD migration -- Re: Hitachi RAID box going out of support

[Bill Bishop (TMNA)]

One issue that you may encounter with going to a new storage system on a z9 
processor is the speed of the ficon cards and whether the new unit can z9 
cards.  I am not sure the new Hitachi's can work with 4GB ficon.

I would make sure that if you replace it, with whichever vendor, that the new 
unit can work with those old z9 cards.

Thanks

Bill Bishop
Consultant, Mainframe Engineer
Mainframe and Scheduling | Infrastructure Technology Services 
Toyota Motor North America
 bill.bis...@toyota.com
Office:  (469) 292-5149
Cell:  (502) 316-4386

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Grant Taylor
Sent: Friday, June 26, 2020 10:05 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] DASD migration -- Re: Hitachi RAID box going out of support

On 6/26/20 3:16 AM, R.S. wrote:
> 3. 18 months is close to half of typical service contract for new dasd 
> array. Still we don't know how sure is 18 months - maybe it would be 
> 36 months? Even 12 months means the dasd array would have some residual value.

n00b questions:

1)  Is it possible to migrate from old DASD to new DASD?

2)  How disruptive would this be to the day-to-day operation of the existing 
mainframe?

3)  What sort of prerequisites exist for this?

I have some experience with this in the Open Systems environment, but I'd like 
to know more about how such a storage migration would be done in the mainframe 
world.



--
Grant. . . .
unix || die

--
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: SDSF CPU L/Z

[Rob Scott]

Terri,

I think the SDSF doc could be a bit clearer in this area, but the numbers you 
quoted do not mean what you think they mean.

There is some extra help text in the "CPU and SIO fields" section of the help 
for the DA command (at the end of the help for the content of the fields).

Taking the  xx/yy numbers :

(o) xx - This is SRM's native view of CPU% busy of the local system without 
factoring in any LPAR weights from PR/SM.
For example, if over a period of 100 seconds, PR/SM gave this system a grand 
total of 10 CPU seconds (and 90 seconds to other LPARs) and this system was 
busy for 5 seconds then the CPU% would be 50%. Think of this as a SRM being 
blissfully unaware of other LPARs in the CEC and behaving like an old-school 
single MVS system.

(o) yy - This is the CPU% factoring in LPAR weighting.
Using the above trivial example, this would be 5.

SDSF does not perform any calculations in this area - we just report what we 
get back from RMF for these two numbers.

I will look to see if we can improve the help text.

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 3:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Thanks Rob,
So NO to the first 2, as we run with hardly any usermods or customizations.

Number 3 is partially true. The 2 UBS2T* Jobs are running on ACW5, But that is 
reflected by the 45/29 number is my display. 45 is my total across the sysplex 
and 29 is the local lpar.

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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri,

The native SDSF 2.2 code populates the title line from the local system CPU 
usage.

A couple of possibilities exist that could explain what you are seeing :


1. You have an ISFUSER exit that alters the title line (possible - but not 
common)
2. You have a local replacement/modification for ERBSMFI or ERB2XDGS on your 
2.2 system that is not installed on your 2.4 system (unlikely).
3. Your 2.2 system is getting the lion's share of CPU resources (maybe via LPAR 
definitions), or is naturally a much busier system so that it permanently shows 
a higher local CPU% which does not look out of place when SYSNAME=* is in 
effect and you sort DA by CPU% descending.

If none of the above apply, please feel free to update the PMR and maybe we can 
take a look at some trace options and other diagnostics.

Rob

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Rob,
My question, was does anyone else see this behavior? And yes that was my point 
of sysname=* I think it should total all lpars, like I see in my z/OS 2.2 lpar 
and display.

But you can see in my z/OS 2.4 lpar, I only get an lpar view.

And yes I opened up the SR because it looked like an issue, but from what she 
stated and you said its working as designed, but not what I see.

I can also tell my cut/paste because IBM list doesn't maintain columns you cant 
really tell the CPU column.


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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>>
 On Behalf Of Rob Scott
Sent: Friday, June 26, 2020 8:47 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

External Email


Terri

You have SYSNAME set to "*" - which means the rows are for all address spaces 
on all systems.

The title line only shows CPU% for the local system.

You also state that you are seeing a discrepancy in 2.3, however the 2.3 DA 
code uses the same methods as 2.2.

I see that you have a PMR open for this - can I suggest we discuss this further 
in there rather than IBM-Main?

Rob

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>>
 On Behalf Of Shaffer, Terri
Sent: Friday, June 26, 2020 1:29 PM
To: 
IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Interesting because that's not what I am seeing..

DASD migration -- Re: Hitachi RAID box going out of support

[Grant Taylor]

On 6/26/20 3:16 AM, R.S. wrote:
3. 18 months is close to half of typical service contract for new dasd 
array. Still we don't know how sure is 18 months - maybe it would be 36 
months? Even 12 months means the dasd array would have some residual value.


n00b questions:

1)  Is it possible to migrate from old DASD to new DASD?

2)  How disruptive would this be to the day-to-day operation of the 
existing mainframe?


3)  What sort of prerequisites exist for this?

I have some experience with this in the Open Systems environment, but 
I'd like to know more about how such a storage migration would be done 
in the mainframe world.




--
Grant. . . .
unix || die

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

Re: SDSF CPU L/Z

[Shaffer, Terri]

Thanks Rob,
 So NO to the first 2, as we run with hardly any usermods or customizations.

Number 3 is partially true.   The 2 UBS2T* Jobs are running on ACW5, But that 
is reflected by the 45/29 number is my display.  45 is my total across the 
sysplex and 29 is the local lpar.

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 Rob 
Scott
Sent: Friday, June 26, 2020 9:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri,

The native SDSF 2.2 code populates the title line from the local system CPU 
usage.

A couple of possibilities exist that could explain what you are seeing :


  1.  You have an ISFUSER exit that alters the title line (possible - but not 
common)
  2.  You have a local replacement/modification for ERBSMFI or ERB2XDGS on your 
2.2 system that is not installed on your 2.4 system (unlikely).
  3.  Your 2.2 system is getting the lion's share of CPU resources (maybe via 
LPAR definitions), or is naturally a much busier system so that it permanently 
shows a higher local CPU% which does not look out of place when SYSNAME=* is in 
effect and you sort DA by CPU% descending.

If none of the above apply, please feel free to update the PMR and maybe we can 
take a look at some trace options and other diagnostics.

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Rob,
My question, was does anyone else see this behavior? And yes that was my point 
of sysname=* I think it should total all lpars, like I see in my z/OS 2.2 lpar 
and display.

But you can see in my z/OS 2.4 lpar, I only get an lpar view.

And yes I opened up the SR because it looked like an issue, but from what she 
stated and you said its working as designed, but not what I see.

I can also tell my cut/paste because IBM list doesn't maintain columns you cant 
really tell the CPU column.


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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri

You have SYSNAME set to "*" - which means the rows are for all address spaces 
on all systems.

The title line only shows CPU% for the local system.

You also state that you are seeing a discrepancy in 2.3, however the 2.3 DA 
code uses the same methods as 2.2.

I see that you have a PMR open for this - can I suggest we discuss this further 
in there rather than IBM-Main?

Rob

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Interesting because that's not what I am seeing..

SDSF DA ACWA (ALL) PAG 0 CPU/L 4/ 1 LINE 815-826 (826)z/OS 2.4 LPAR COMMAND 
INPUT ===>, ,SCROLL ===>,C
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=* NP ,JOBNAME ,DP,Real,Paging, 
SIO, CPU%,ASID,ASIDX, EXCP-Cnt, CPU-Time ,

TCPIP , FE 14T 0.00 0.001.01 78 004E 12918 9250.83 , ZFS , FE 634T 0.00 1.75 
1.07 49 0031 22602696 5441.27 , NFSC , FE 72T 0.00 0.00 1.13 66 0042 289157 
29189.68 , QZ77EVTL, F2 572 0.00 342.50 1.30 130 0082 4688161 454.80 , 
C8QBMSTR, FE 29T 0.00 863.00 1.40 41 0029 117138340 6337.83 , UBS2EVTA, F0 55T 
0.00 269.00 2.60 264 0108 12993387 2005.01 , NFSC , FE 1M 0.00 0.00 2.93 39 
0027 71333 17037.59 ,T SPAXAA6, F4 54T 0.00 0.00 3.46214 00D6 58211 4888.83 , 
TSPQEBA6, F0 39T 0.00 4113.5 4.65 157 009D 248680399 6875.79 , TSOJXSA5, F4 37T 
0.00 0.00 6.86 350 015E 2123259 3352.63 , UBS2TDAL, E6 10T 0.00 15177 13.86 320 
0140 534324805 7649.91 , UBS2TDAL, E6 10T 0.00 16494 14.73 259 0103 537388749 
7603.17


SDSF DA ACW5 (ALL) PAG 0 CPU/L 45/ 29 LINE 813-825Z/OS 2.2 COMMAND INPUT ===>, 
,SCROLL
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=* NP ,JOBNAME 
,Pos,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt

TCPIP NS FE 14T 0.00 0.00 1.27 78 004E 12918
BBOS010 NS F0 75T 0.00 338.53 1.52 141 008D 7705735 , QZ77EVTL IN F2 572 0.00 
372.08 1.58 130 0082 4682243 , C8QBMSTR NS FE 29T 0.00 937.32 1.70 41 0029 
117123444
EYUCAS31 NS EE 2106 0.00 0.00 2.06 87 0057 909 , UBS2EVTA IN F2 55T 0.00 335.48 
2.59 264 0108 12988064
TSPAXAA6 IN F2 54T 0.00 0.00 3.16 214 00D6 58211 , NFSC NS FE 1M 0.00 0.00 3.58 
39 0027 71333
TSPQEBA6 IN F0 39T 0.00 4469.0 5.59 157 009D 248609323
TSOJXSA5 IN F2 37T 0.00 0.00 6.46 350 015E 2123259 , UBS2TDAL IN E6 10T 0.00 
15428 12.91 259 0103 537122733 , UBS2TDAL IN 

Re: SDSF CPU L/Z

[Rob Scott]

Terri,

The native SDSF 2.2 code populates the title line from the local system CPU 
usage.

A couple of possibilities exist that could explain what you are seeing :


  1.  You have an ISFUSER exit that alters the title line (possible - but not 
common)
  2.  You have a local replacement/modification for ERBSMFI or ERB2XDGS on your 
2.2 system that is not installed on your 2.4 system (unlikely).
  3.  Your 2.2 system is getting the lion's share of CPU resources (maybe via 
LPAR definitions), or is naturally a much busier system so that it permanently 
shows a higher local CPU% which does not look out of place when SYSNAME=* is in 
effect and you sort DA by CPU% descending.

If none of the above apply, please feel free to update the PMR and maybe we can 
take a look at some trace options and other diagnostics.

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 2:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Rob,
My question, was does anyone else see this behavior? And yes that was my point 
of sysname=* I think it should total all lpars, like I see in my z/OS 2.2 lpar 
and display.

But you can see in my z/OS 2.4 lpar, I only get an lpar view.

And yes I opened up the SR because it looked like an issue, but from what she 
stated and you said its working as designed, but not what I see.

I can also tell my cut/paste because IBM list doesn't maintain columns you cant 
really tell the CPU column.


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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri

You have SYSNAME set to "*" - which means the rows are for all address spaces 
on all systems.

The title line only shows CPU% for the local system.

You also state that you are seeing a discrepancy in 2.3, however the 2.3 DA 
code uses the same methods as 2.2.

I see that you have a PMR open for this - can I suggest we discuss this further 
in there rather than IBM-Main?

Rob

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Interesting because that's not what I am seeing..

SDSF DA ACWA (ALL) PAG 0 CPU/L 4/ 1 LINE 815-826 (826)z/OS 2.4 LPAR
COMMAND INPUT ===>, ,SCROLL ===>,C
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt, CPU-Time ,

TCPIP , FE 14T 0.00 0.001.01 78 004E 12918 9250.83 ,
ZFS , FE 634T 0.00 1.75 1.07 49 0031 22602696 5441.27 ,
NFSC , FE 72T 0.00 0.00 1.13 66 0042 289157 29189.68 ,
QZ77EVTL, F2 572 0.00 342.50 1.30 130 0082 4688161 454.80 ,
C8QBMSTR, FE 29T 0.00 863.00 1.40 41 0029 117138340 6337.83 ,
UBS2EVTA, F0 55T 0.00 269.00 2.60 264 0108 12993387 2005.01 ,
NFSC , FE 1M 0.00 0.00 2.93 39 0027 71333 17037.59 ,T
SPAXAA6, F4 54T 0.00 0.00 3.46214 00D6 58211 4888.83 ,
TSPQEBA6, F0 39T 0.00 4113.5 4.65 157 009D 248680399 6875.79 ,
TSOJXSA5, F4 37T 0.00 0.00 6.86 350 015E 2123259 3352.63 ,
UBS2TDAL, E6 10T 0.00 15177 13.86 320 0140 534324805 7649.91 ,
UBS2TDAL, E6 10T 0.00 16494 14.73 259 0103 537388749 7603.17


SDSF DA ACW5 (ALL) PAG 0 CPU/L 45/ 29 LINE 813-825Z/OS 2.2
COMMAND INPUT ===>, ,SCROLL
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,Pos,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt

TCPIP NS FE 14T 0.00 0.00 1.27 78 004E 12918
BBOS010 NS F0 75T 0.00 338.53 1.52 141 008D 7705735 ,
QZ77EVTL IN F2 572 0.00 372.08 1.58 130 0082 4682243 ,
C8QBMSTR NS FE 29T 0.00 937.32 1.70 41 0029 117123444
EYUCAS31 NS EE 2106 0.00 0.00 2.06 87 0057 909 ,
UBS2EVTA IN F2 55T 0.00 335.48 2.59 264 0108 12988064
TSPAXAA6 IN F2 54T 0.00 0.00 3.16 214 00D6 58211 ,
NFSC NS FE 1M 0.00 0.00 3.58 39 0027 71333
TSPQEBA6 IN F0 39T 0.00 4469.0 5.59 157 009D 248609323
TSOJXSA5 IN F2 37T 0.00 0.00 6.46 350 015E 2123259 ,
UBS2TDAL IN E6 10T 0.00 15428 12.91 259 0103 537122733 ,
UBS2TDAL IN E6 10T 0.00 16673 14.37 320 0140 534062332

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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>>
 On Behalf Of Rob Scott
Sent: Friday, June 26, 2020 8:01 AM
To: 

Re: SDSF CPU L/Z

[Shaffer, Terri]

Rob,
 My question,  was does anyone else see this behavior?  And yes that was my 
point of sysname=* I think it should total all lpars, like I see in my z/OS 2.2 
lpar and display.

But you can see in my z/OS 2.4 lpar, I only get an lpar view.

And yes I opened up the SR because it looked like an issue, but from what she 
stated and you said its working as designed, but not what I see.

I can also tell my cut/paste because IBM list doesn't maintain columns you cant 
really tell the CPU column.


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 Rob 
Scott
Sent: Friday, June 26, 2020 8:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri

You have SYSNAME set to "*" - which means the rows are for all address spaces 
on all systems.

The title line only shows CPU% for the local system.

You also state that you are seeing a discrepancy in 2.3, however the 2.3 DA 
code uses the same methods as 2.2.

I see that you have a PMR open for this - can I suggest we discuss this further 
in there rather than IBM-Main?

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Interesting because that's not what I am seeing..

SDSF DA ACWA (ALL) PAG 0 CPU/L 4/ 1 LINE 815-826 (826)z/OS 2.4 LPAR
COMMAND INPUT ===>, ,SCROLL ===>,C
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt, CPU-Time ,

TCPIP , FE 14T 0.00 0.001.01 78 004E 12918 9250.83 ,
ZFS , FE 634T 0.00 1.75 1.07 49 0031 22602696 5441.27 ,
NFSC , FE 72T 0.00 0.00 1.13 66 0042 289157 29189.68 ,
QZ77EVTL, F2 572 0.00 342.50 1.30 130 0082 4688161 454.80 ,
C8QBMSTR, FE 29T 0.00 863.00 1.40 41 0029 117138340 6337.83 ,
UBS2EVTA, F0 55T 0.00 269.00 2.60 264 0108 12993387 2005.01 ,
NFSC , FE 1M 0.00 0.00 2.93 39 0027 71333 17037.59 ,T
SPAXAA6, F4 54T 0.00 0.00 3.46214 00D6 58211 4888.83 ,
TSPQEBA6, F0 39T 0.00 4113.5 4.65 157 009D 248680399 6875.79 ,
TSOJXSA5, F4 37T 0.00 0.00 6.86 350 015E 2123259 3352.63 ,
UBS2TDAL, E6 10T 0.00 15177 13.86 320 0140 534324805 7649.91 ,
UBS2TDAL, E6 10T 0.00 16494 14.73 259 0103 537388749 7603.17


SDSF DA ACW5 (ALL) PAG 0 CPU/L 45/ 29 LINE 813-825Z/OS 2.2
COMMAND INPUT ===>, ,SCROLL
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,Pos,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt

TCPIP NS FE 14T 0.00 0.00 1.27 78 004E 12918
BBOS010 NS F0 75T 0.00 338.53 1.52 141 008D 7705735 ,
QZ77EVTL IN F2 572 0.00 372.08 1.58 130 0082 4682243 ,
C8QBMSTR NS FE 29T 0.00 937.32 1.70 41 0029 117123444
EYUCAS31 NS EE 2106 0.00 0.00 2.06 87 0057 909 ,
UBS2EVTA IN F2 55T 0.00 335.48 2.59 264 0108 12988064
TSPAXAA6 IN F2 54T 0.00 0.00 3.16 214 00D6 58211 ,
NFSC NS FE 1M 0.00 0.00 3.58 39 0027 71333
TSPQEBA6 IN F0 39T 0.00 4469.0 5.59 157 009D 248609323
TSOJXSA5 IN F2 37T 0.00 0.00 6.46 350 015E 2123259 ,
UBS2TDAL IN E6 10T 0.00 15428 12.91 259 0103 537122733 ,
UBS2TDAL IN E6 10T 0.00 16673 14.37 320 0140 534062332

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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri,



The CPU% in the title line is always for the local system, regardless of the 
SYSNAME setting - this has always been the case.

You might be noticing the difference more because the DA data in 2.4 is 
collected centrally by the data gathering task in SDSFAUX, whereas in previous 
releases (including 2.3) the data was gathered by the client code. In both 
cases, however, the RMF sample that calculates the CPU% for the title line is 
different to the SDSF sample and variations will occur, especially on low to 
medium activity systems where the CPU consumption is not constantly high.

CPU% for both the system and for a specific address space can vary greatly over 
sub-second intervals.

The data gathering task in SDSFAUX still calls RMF for the underlying address 
space information.

Rob Scott

Rocket Software


From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF CPU L/Z

EXTERNAL EMAIL



Does anyone else have this issue with the SDSF CPU Title CPU L/Z fields on 
reflecting the LPAR usage and not a SYSPLEX total now with z/OS 2.4?

On my z/OS 2.2 lpar, if I sort on CPU% the numbers match pretty closely to the 
Title bar numbers, This 

Re: SDSF CPU L/Z

[Rob Scott]

Terri

You have SYSNAME set to "*" - which means the rows are for all address spaces 
on all systems.

The title line only shows CPU% for the local system.

You also state that you are seeing a discrepancy in 2.3, however the 2.3 DA 
code uses the same methods as 2.2.

I see that you have a PMR open for this - can I suggest we discuss this further 
in there rather than IBM-Main?

Rob

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 1:29 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

EXTERNAL EMAIL



Interesting because that's not what I am seeing..

SDSF DA ACWA (ALL) PAG 0 CPU/L 4/ 1 LINE 815-826 (826)z/OS 2.4 LPAR
COMMAND INPUT ===>, ,SCROLL ===>,C
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt, CPU-Time
,TCPIP , FE 14T 0.00 0.001.01 78 004E 12918 9250.83
,ZFS , FE 634T 0.00 1.75 1.07 49 0031 22602696 5441.27
,NFSC , FE 72T 0.00 0.00 1.13 66 0042 289157 29189.68
,QZ77EVTL, F2 572 0.00 342.50 1.30 130 0082 4688161 454.80
,C8QBMSTR, FE 29T 0.00 863.00 1.40 41 0029 117138340 6337.83
,UBS2EVTA, F0 55T 0.00 269.00 2.60 264 0108 12993387 2005.01
,NFSC , FE 1M 0.00 0.00 2.93 39 0027 71333 17037.59
,TSPAXAA6, F4 54T 0.00 0.00 3.46 214 00D6 58211 4888.83
,TSPQEBA6, F0 39T 0.00 4113.5 4.65 157 009D 248680399 6875.79
,TSOJXSA5, F4 37T 0.00 0.00 6.86 350 015E 2123259 3352.63
,UBS2TDAL, E6 10T 0.00 15177 13.86 320 0140 534324805 7649.91
,UBS2TDAL, E6 10T 0.00 16494 14.73 259 0103 537388749 7603.17


SDSF DA ACW5 (ALL) PAG 0 CPU/L 45/ 29 LINE 813-825Z/OS 2.2
COMMAND INPUT ===>, ,SCROLL
PREFIX=* DEST=(ALL) OWNER=* SORT=CPU%/A SYSNAME=*
NP ,JOBNAME ,Pos,DP,Real,Paging, SIO, CPU%,ASID,ASIDX, EXCP-Cnt
,JES2 NS FE 9940 0.00 6.10 1.12 36 0024 594743
,TCPIP NS FE 14T 0.00 0.00 1.27 78 004E 12918
,BBOS010 NS F0 75T 0.00 338.53 1.52 141 008D 7705735
,QZ77EVTL IN F2 572 0.00 372.08 1.58 130 0082 4682243
,C8QBMSTR NS FE 29T 0.00 937.32 1.70 41 0029 117123444
,EYUCAS31 NS EE 2106 0.00 0.00 2.06 87 0057 909
,UBS2EVTA IN F2 55T 0.00 335.48 2.59 264 0108 12988064
,TSPAXAA6 IN F2 54T 0.00 0.00 3.16 214 00D6 58211
,NFSC NS FE 1M 0.00 0.00 3.58 39 0027 71333
,TSPQEBA6 IN F0 39T 0.00 4469.0 5.59 157 009D 248609323
,TSOJXSA5 IN F2 37T 0.00 0.00 6.46 350 015E 2123259
,UBS2TDAL IN E6 10T 0.00 15428 12.91 259 0103 537122733
,UBS2TDAL IN E6 10T 0.00 16673 14.37 320 0140 534062332

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 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Rob 
Scott
Sent: Friday, June 26, 2020 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri,



The CPU% in the title line is always for the local system, regardless of the 
SYSNAME setting - this has always been the case.

You might be noticing the difference more because the DA data in 2.4 is 
collected centrally by the data gathering task in SDSFAUX, whereas in previous 
releases (including 2.3) the data was gathered by the client code. In both 
cases, however, the RMF sample that calculates the CPU% for the title line is 
different to the SDSF sample and variations will occur, especially on low to 
medium activity systems where the CPU consumption is not constantly high.

CPU% for both the system and for a specific address space can vary greatly over 
sub-second intervals.

The data gathering task in SDSFAUX still calls RMF for the underlying address 
space information.

Rob Scott

Rocket Software


From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF CPU L/Z

EXTERNAL EMAIL



Does anyone else have this issue with the SDSF CPU Title CPU L/Z fields on 
reflecting the LPAR usage and not a SYSPLEX total now with z/OS 2.4?

On my z/OS 2.2 lpar, if I sort on CPU% the numbers match pretty closely to the 
Title bar numbers, This isn't the case on my z/OS 2.3 and z/OS 2.4 lpars.

I have checked my SYSTEM NAME and Filters and it seems internally its always 
using the lpar specific CPU %.

I know in SDSF 2.4 and I think also 2.3, they gather these number thru SDSFAUX 
instead of I think it was RMF.

Trying to figure out if this is a setup issue in my shop or a bigger issue?

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

Re: SDSF CPU L/Z

[Shaffer, Terri]

Interesting because that's not what I am seeing..

SDSF DA ACWA (ALL)PAG  0  CPU/L 4/  1  LINE 815-826 (826)z/OS 
2.4 LPAR
COMMAND INPUT ===>,  ,SCROLL ===>,C
PREFIX=*  DEST=(ALL)  OWNER=*  SORT=CPU%/A  SYSNAME=*
NP  ,JOBNAME  ,DP,Real,Paging,   SIO,  CPU%,ASID,ASIDX, EXCP-Cnt,  CPU-Time
,TCPIP   , FE  14T   0.00   0.001.01   78 004E  129189250.83
,ZFS , FE 634T   0.00   1.75  1.07   49 0031   22602696
5441.27
,NFSC, FE  72T   0.00   0.00 1.13  66 0042 289157   
29189.68
,QZ77EVTL, F2  572   0.00 342.50 1.30  130 00824688161 454.80
,C8QBMSTR, FE  29T   0.00 863.00   1.40   41 0029  1171383406337.83
,UBS2EVTA, F0  55T   0.00 269.00   2.60  264 0108   129933872005.01
,NFSC, FE   1M   0.00   0.00   2.93   39 0027  71333   
17037.59
,TSPAXAA6, F4  54T   0.00   0.00  3.46  214 00D6  582114888.83
,TSPQEBA6, F0  39T   0.00 4113.5   4.65  157 009D  2486803996875.79
,TSOJXSA5, F4  37T   0.00   0.00   6.86  350 015E21232593352.63
,UBS2TDAL, E6  10T   0.00  15177  13.86  320 0140  5343248057649.91
,UBS2TDAL, E6  10T   0.00  16494  14.73  259 0103  5373887497603.17


SDSF DA ACW5 (ALL)PAG  0  CPU/L45/ 29  LINE 813-825Z/OS 2.2
COMMAND INPUT ===>,  ,SCROLL
PREFIX=*  DEST=(ALL)  OWNER=*  SORT=CPU%/A  SYSNAME=*
NP  ,JOBNAME  ,Pos,DP,Real,Paging,   SIO,  CPU%,ASID,ASIDX, EXCP-Cnt
,JES2  NS  FE 9940   0.00   6.10   1.12   36 0024 594743
,TCPIP NS  FE  14T   0.00   0.00   1.27   78 004E  12918
,BBOS010   NS  F0  75T   0.00 338.53   1.52  141 008D7705735
,QZ77EVTL  IN  F2  572   0.00 372.08   1.58  130 00824682243
,C8QBMSTR  NS  FE  29T   0.00 937.32  1.70   41 0029  117123444
,EYUCAS31  NS  EE 2106   0.00   0.00   2.06   87 0057909
,UBS2EVTA  IN  F2  55T   0.00 335.48   2.59  264 0108   12988064
,TSPAXAA6  IN  F2  54T   0.00   0.00   3.16  214 00D6  58211
,NFSC  NS  FE   1M   0.00   0.00   3.58   39 0027  71333
,TSPQEBA6  IN  F0  39T   0.00 4469.0   5.59  157 009D  248609323
,TSOJXSA5  IN  F2  37T   0.00   0.00   6.46  350 015E2123259
,UBS2TDAL  IN  E6  10T   0.00  15428  12.91  259 0103  537122733
,UBS2TDAL  IN  E6  10T   0.00  16673  14.37  320 0140  534062332

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 Rob 
Scott
Sent: Friday, June 26, 2020 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SDSF CPU L/Z

External Email


Terri,



The CPU% in the title line is always for the local system, regardless of the 
SYSNAME setting - this has always been the case.

You might be noticing the difference more because the DA data in 2.4 is 
collected centrally by the data gathering task in SDSFAUX, whereas in previous 
releases (including 2.3) the data was gathered by the client code. In both 
cases, however, the RMF sample that calculates the CPU% for the title line is 
different to the SDSF sample and variations will occur, especially on low to 
medium activity systems where the CPU consumption is not constantly high.

CPU% for both the system and for a specific address space can vary greatly over 
sub-second intervals.

The data gathering task in SDSFAUX still calls RMF for the underlying address 
space information.

Rob Scott

Rocket Software


From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF CPU L/Z

EXTERNAL EMAIL



Does anyone else have this issue with the SDSF CPU Title CPU L/Z fields on 
reflecting the LPAR usage and not a SYSPLEX total now with z/OS 2.4?

On my z/OS 2.2 lpar, if I sort on CPU% the numbers match pretty closely to the 
Title bar numbers, This isn't the case on my z/OS 2.3 and z/OS 2.4 lpars.

I have checked my SYSTEM NAME and Filters and it seems internally its always 
using the lpar specific CPU %.

I know in SDSF 2.4 and I think also 2.3, they gather these number thru SDSFAUX 
instead of I think it was RMF.

Trying to figure out if this is a setup issue in my shop or a bigger issue?

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


[https://www.aciworldwide.com/-/media/aci-footer]
 >
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 

Re: SDSF CPU L/Z

[Rob Scott]

Terri,



The CPU% in the title line is always for the local system, regardless of the 
SYSNAME setting - this has always been the case.

You might be noticing the difference more because the DA data in 2.4 is 
collected centrally by the data gathering task in SDSFAUX, whereas in previous 
releases (including 2.3) the data was gathered by the client code. In both 
cases, however, the RMF sample that calculates the CPU% for the title line is 
different to the SDSF sample and variations will occur, especially on low to 
medium activity systems where the CPU consumption is not constantly high.

CPU% for both the system and for a specific address space can vary greatly over 
sub-second intervals.

The data gathering task in SDSFAUX still calls RMF for the underlying address 
space information.

Rob Scott

Rocket Software


From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Friday, June 26, 2020 12:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SDSF CPU L/Z

EXTERNAL EMAIL



Does anyone else have this issue with the SDSF CPU Title CPU L/Z fields on 
reflecting the LPAR usage and not a SYSPLEX total now with z/OS 2.4?

On my z/OS 2.2 lpar, if I sort on CPU% the numbers match pretty closely to the 
Title bar numbers, This isn't the case on my z/OS 2.3 and z/OS 2.4 lpars.

I have checked my SYSTEM NAME and Filters and it seems internally its always 
using the lpar specific CPU %.

I know in SDSF 2.4 and I think also 2.3, they gather these number thru SDSFAUX 
instead of I think it was RMF.

Trying to figure out if this is a setup issue in my shop or a bigger issue?

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


[https://www.aciworldwide.com/-/media/aci-footer]
 >
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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

SDSF CPU L/Z

[Shaffer, Terri]

Does anyone else have this issue with the SDSF CPU Title CPU L/Z fields on 
reflecting the LPAR usage and not a SYSPLEX total now with z/OS 2.4?

On my z/OS 2.2 lpar, if I sort on CPU% the numbers match pretty closely to the 
Title bar numbers, This isn't the case on my z/OS 2.3 and z/OS 2.4 lpars.

I have checked my SYSTEM NAME and Filters and it seems internally its always 
using the lpar specific CPU %.

I know in SDSF 2.4 and I think also 2.3, they gather these number thru SDSFAUX 
instead of I think it was RMF.

Trying to figure out if this is a setup issue in my shop or a bigger issue?

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


 [https://www.aciworldwide.com/-/media/aci-footer] 
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: Does adding real storage require an IPL?

[R.S.]

Proper Planning Prevents Poor Performance.

Let's start from scratch or from CPC Activate process.
Now it is good moment to properly define LPARs. First, give reserved 
memory to each one. It is just a definition, it is clause like "I expect 
I will add memory in the future".
And when your system is running the LPAR memory is able to grow up. Your 
z/OS is also able to get more memory without reIPL. Just use system 
command. Of course some free (unasssigned) memory must exist in the CPC 
- that's quite obvious: you cannot add and use nonexistend memory.

Sources of free memory?
Examples:
1. Planning. Assuming you have 1024GB memory and you assigned 768GB to 
LPARs. So you have 256GB unassigned memory. Available for use.
2. Deactivated LPAR. You deactivated LPAR A - and now the memory from 
this LPAR is free now. You can add it to another LPAR.
3. Microcode upgrade. You purchased and "unblocked" existing physical 
memory within ypur CPC.
4. Hardware physical upgrade - possible for some multi-BOOK or 
multi-DRAWER configurations. Or just another book/drawer is added to CPC.


Regarding to the question, I repeat: in order to add memory to the LPAR 
without deac/act you have to define the LPAR with reserved memory.


--
Radoslaw Skorupka
Lodz, Poland







W dniu 26.06.2020 o 12:57, Michael Babcock pisze:

You are right.   We added it to the LPAR image profile And that took an
act/deact to add.  We had no other memory allocated to that LPAR (reserved
or otherwise).   How else could we have added the additional memory without
act/deact?

On Fri, Jun 26, 2020 at 3:54 AM R.S.  wrote:


No, you did not that way.
Probably you added some memory to LPAR profile, but this is not an LPAR
itself. It is LPAR definition which is used during LPAR activation. For
active LPAR it has no meaning. To compare: it is like change in JES2PARM
member after JES2 is started.

BTW: LPAR definition may contain more memory that is actually available.
For example you may have 1024GB memory, define 10 LPARs and "assign"
256GB to each LPAR. It will be accepted by the system with no error or
warning msg. However durin system activation (IML) only few of defined
LPAR will be activated correctly. Remaining LPARs will not be activated
due to lack of memory which is described in messages.

Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 25.06.2020 o 15:11, Michael Babcock pisze:

We recently added some unassigned memory to our production LPAR and

IPL’d.

The memory did not show.  We had to deactivate the LPAR and reactivate it
to add the memory.This was on a z14-ZR1 with z/OS 2.3.


On Thu, Jun 25, 2020 at 5:31 AM R.S. 

wrote:

W dniu 23.06.2020 o 02:07, Charles Mills pisze:

Today is real storage day. Sorry for the elementary questions.

The folks that own the box as a whole have added memory to our LPAR. Do

we

need to IPL to pick that up in z/OS, or is there a command or similar
process? I thought I heard at a SHARE presentation that it could be

done

dynamically, but the box owners are telling us an IPL is required.

PR/SM, not VM, if that matters.


I don't understand details, so my answer is rather general:
1. LPAR can be defined with memory and "reserved" memory. That means it
is possible to get more memory than assingned during LPAR activation
(usually IML process).
2. OS may or may not support dynamic memory change. z/OS does support
it. So, it is possible to dynamically add memory to the system.
Assumpions are: LPAR definition as described above *and* free
(unassigned) storage in CPC. Free storage may come from deactivated
(other) LPAR.
3. It is also possible to buy memory without physical deactivation of
CPC. It is memory which is already inside the CPC, but microcode will
enable it for user. It can be done dynamically, and new memory will
appear as unassigned to any LPAR. Then you can add it do a system as
described above.
4. Amount of "memory for sale" within CPC depend on many factors. As far
as I know IBM want to disable this option ("preplanned memory"), however
AFAIK it is still possible to get a little bit more than ordered and the
gap can be bought and enabled.

Personally I always define LPARs with reserved memory just to have
option to for future unknown need. And I had cases when I really needed
additional memory.


HTH

--
Radoslaw Skorupka
Lodz, Poland



==




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 

Re: Does adding real storage require an IPL?

[Michael Babcock]

You are right.   We added it to the LPAR image profile And that took an
act/deact to add.  We had no other memory allocated to that LPAR (reserved
or otherwise).   How else could we have added the additional memory without
act/deact?

On Fri, Jun 26, 2020 at 3:54 AM R.S.  wrote:

> No, you did not that way.
> Probably you added some memory to LPAR profile, but this is not an LPAR
> itself. It is LPAR definition which is used during LPAR activation. For
> active LPAR it has no meaning. To compare: it is like change in JES2PARM
> member after JES2 is started.
>
> BTW: LPAR definition may contain more memory that is actually available.
> For example you may have 1024GB memory, define 10 LPARs and "assign"
> 256GB to each LPAR. It will be accepted by the system with no error or
> warning msg. However durin system activation (IML) only few of defined
> LPAR will be activated correctly. Remaining LPARs will not be activated
> due to lack of memory which is described in messages.
>
> Regards
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> W dniu 25.06.2020 o 15:11, Michael Babcock pisze:
> > We recently added some unassigned memory to our production LPAR and
> IPL’d.
> > The memory did not show.  We had to deactivate the LPAR and reactivate it
> > to add the memory.This was on a z14-ZR1 with z/OS 2.3.
> >
> >
> > On Thu, Jun 25, 2020 at 5:31 AM R.S. 
> wrote:
> >
> >> W dniu 23.06.2020 o 02:07, Charles Mills pisze:
> >>> Today is real storage day. Sorry for the elementary questions.
> >>>
> >>> The folks that own the box as a whole have added memory to our LPAR. Do
> >> we
> >>> need to IPL to pick that up in z/OS, or is there a command or similar
> >>> process? I thought I heard at a SHARE presentation that it could be
> done
> >>> dynamically, but the box owners are telling us an IPL is required.
> >>>
> >>> PR/SM, not VM, if that matters.
> >>>
> >> I don't understand details, so my answer is rather general:
> >> 1. LPAR can be defined with memory and "reserved" memory. That means it
> >> is possible to get more memory than assingned during LPAR activation
> >> (usually IML process).
> >> 2. OS may or may not support dynamic memory change. z/OS does support
> >> it. So, it is possible to dynamically add memory to the system.
> >> Assumpions are: LPAR definition as described above *and* free
> >> (unassigned) storage in CPC. Free storage may come from deactivated
> >> (other) LPAR.
> >> 3. It is also possible to buy memory without physical deactivation of
> >> CPC. It is memory which is already inside the CPC, but microcode will
> >> enable it for user. It can be done dynamically, and new memory will
> >> appear as unassigned to any LPAR. Then you can add it do a system as
> >> described above.
> >> 4. Amount of "memory for sale" within CPC depend on many factors. As far
> >> as I know IBM want to disable this option ("preplanned memory"), however
> >> AFAIK it is still possible to get a little bit more than ordered and the
> >> gap can be bought and enabled.
> >>
> >> Personally I always define LPARs with reserved memory just to have
> >> option to for future unknown need. And I had cases when I really needed
> >> additional memory.
> >>
> >>
> >> HTH
> >>
> >> --
> >> Radoslaw Skorupka
> >> Lodz, Poland
> >>
>
>
> ==
>
> Jeśli nie jesteś adresatem tej wiadomości:
>
> - powiadom nas o tym w mailu zwrotnym (dziękujemy!),
> - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub
> zapisałeś na dysku).
> Wiadomość ta może zawierać chronione prawem informacje, które może
> wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia
> (kopiuje, rozprowadza) tę wiadomość lub podejmuje po
> dobne
> działania, narusza prawo i może podlegać karze.
>
> mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
> www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy
> XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP:
> 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
> 01.01.2020 r. wynosi 169.401.468 złotych.
>
> If you are not the addressee of this message:
>
> - let us know by replying to this e-mail (thank you!),
> - delete this message permanently (including all the copies which you have
> printed out or saved).
> This message may contain legally protected information, which may be used
> exclusively by the addressee.Please be reminded that anyone who
> disseminates (copies, distributes) this message or takes any similar act
> ion,
> violates the law and may be penalised.
>
> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the
> Capital City of Warsaw, 12th Commercial Division of the National Court
> Register, KRS 

Re: ISPW Question

[R.S.]

W dniu 17.06.2020 o 22:35, Steely.Mark pisze:

Anyone on this list have experience upgrading Compuware ISPW from v17 to v18?

Is there a  listserv for Compuware and / or ISPW ?


What problem do you have?

--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: Good FTP client for MVS data set access

[R.S.]

W dniu 17.06.2020 o 20:09, Frank Swarbrick pisze:

What FTP client do you use to access MVS data sets?  Do you like it?

I personally use the FTP Client that is part of Micro Focus (formerly 
Attachmate) Reflection Desktop for IBM (Reflection Workspace).  Being an 
application suite dedicated to mainframe access (the application is primarily a 
TN3270 client), the FTP Client that goes along with it seems to truly 
understand the idiosyncrasies of MVS and works quite well with it.

On the other hand, only a limited number of users in our shop are "authorized" 
to use Reflection, so they cannot use its FTP client.  They are stuck (currently) with an 
MVS hostile (IMO) application called CuteFTP.

Are there any good "freestanding" FTP GUI applications that are "MVS friendly"?



Actually I use regular "default" ftp client embedded in any Windows 
system for years.

And have no problems with that.
Real problems occur when mainframe is client and your PC is ftp server. 
However the most tricky issue I found was with z/VM, not z/OS. In this 
case filezilla server helped me, AFAIR.
I also used old 3Com server, mostly because I've got it with FOS (Fabric 
OS - firmware for FICON switches). Brocade attached it to FOS (but they 
stopped). This server is still working on x64 Windows 10.

Things get more complex when considering FTPS and/or sftp.


--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: Hitachi RAID box going out of support

[R.S.]

W dniu 25.06.2020 o 21:57, Nightwatch RenBand pisze:

We have a 10 year old Hitachi RAID box which Hitachi tells us is going out
of support.  Only two applications are left of the old z9 machine but they
are critical.  Latest estimate from programmers is that they will migrate
off in 12 to 18 months.
 So, based on you folks experience, is it reasonable to pay extra for an
extended contract and keep the old box?  I know there are other options,
but this appears to be the lowest cost, and easiest.  The question is about
how older RAID boxes hold up in general.


It is not technical issue, it is managment issue.
1. How much do you believe in "latest estimation"? What would you do 
when after 24 months you will hear "new estimation"? Note: you array 
will be 12 years old then. Assuming it will work. The same for z9 and 
other stuff.


2. Two applications left but they are critical. How much critical? 
"Critical" should be translated into $$$. My daughters homework is 
critical for her, but it is kept on regular PC HDD ...and on USB stick 
(because dad said so). No disk array involved, no backup system with 
tape library, no secondary datacenter. Your house is critical for you, 
so likely you purchased insurance policy. You PAID for "critical".

And now - how much they would pay for critical applications?

3. 18 months is close to half of typical service contract for new dasd 
array. Still we don't know how sure is 18 months - maybe it would be 36 
months? Even 12 months means the dasd array would have some residual value.


4. There are many options to consider:
a) do nothing and live with unsupported equipment.
b) look for third party service.
c) replace old failing equipment with new or second hand one.
d) talk to vendor about extendind service contract behind end of service.

5. Last, but not least: It is not about DASD and nothing else. It is 
still whole mainframe environment serving critical applications. Besides 
dasd you should think about ooold z9, backup system, FICON SAN 
(switches), and last, but not least: software. Old z9 means old z/OS, 
means out of support, means no patches (PTFs). And that could mean rule 
violation. Not only your internal rules, but also official rules 
demanded but law and checked by some financial supervision (like BaFin 
in Germany, KNF in Poland, SEC and NFA in US).


--
Radoslaw Skorupka
Lodz, Poland





==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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

Re: Does adding real storage require an IPL?

[R.S.]

No, you did not that way.
Probably you added some memory to LPAR profile, but this is not an LPAR 
itself. It is LPAR definition which is used during LPAR activation. For 
active LPAR it has no meaning. To compare: it is like change in JES2PARM 
member after JES2 is started.


BTW: LPAR definition may contain more memory that is actually available. 
For example you may have 1024GB memory, define 10 LPARs and "assign" 
256GB to each LPAR. It will be accepted by the system with no error or 
warning msg. However durin system activation (IML) only few of defined 
LPAR will be activated correctly. Remaining LPARs will not be activated 
due to lack of memory which is described in messages.


Regards
--
Radoslaw Skorupka
Lodz, Poland






W dniu 25.06.2020 o 15:11, Michael Babcock pisze:

We recently added some unassigned memory to our production LPAR and IPL’d.
The memory did not show.  We had to deactivate the LPAR and reactivate it
to add the memory.This was on a z14-ZR1 with z/OS 2.3.


On Thu, Jun 25, 2020 at 5:31 AM R.S.  wrote:


W dniu 23.06.2020 o 02:07, Charles Mills pisze:

Today is real storage day. Sorry for the elementary questions.

The folks that own the box as a whole have added memory to our LPAR. Do

we

need to IPL to pick that up in z/OS, or is there a command or similar
process? I thought I heard at a SHARE presentation that it could be done
dynamically, but the box owners are telling us an IPL is required.

PR/SM, not VM, if that matters.


I don't understand details, so my answer is rather general:
1. LPAR can be defined with memory and "reserved" memory. That means it
is possible to get more memory than assingned during LPAR activation
(usually IML process).
2. OS may or may not support dynamic memory change. z/OS does support
it. So, it is possible to dynamically add memory to the system.
Assumpions are: LPAR definition as described above *and* free
(unassigned) storage in CPC. Free storage may come from deactivated
(other) LPAR.
3. It is also possible to buy memory without physical deactivation of
CPC. It is memory which is already inside the CPC, but microcode will
enable it for user. It can be done dynamically, and new memory will
appear as unassigned to any LPAR. Then you can add it do a system as
described above.
4. Amount of "memory for sale" within CPC depend on many factors. As far
as I know IBM want to disable this option ("preplanned memory"), however
AFAIK it is still possible to get a little bit more than ordered and the
gap can be bought and enabled.

Personally I always define LPARs with reserved memory just to have
option to for future unknown need. And I had cases when I really needed
additional memory.


HTH

--
Radoslaw Skorupka
Lodz, Poland




==

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś 
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać 
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) 
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać 
karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. 
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, 
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 
01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have 
printed out or saved).
This message may contain legally protected information, which may be used 
exclusively by the addressee.Please be reminded that anyone who disseminates 
(copies, distributes) this message or takes any similar action, violates the 
law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital 
City of Warsaw, 12th Commercial Division of the National Court Register, KRS 
025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 
169.401.468 as at 1 January 2020.

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