Re: Accessing 65536 devices

[Seymour J Metz]

It used to be that SE's  were free and, like SHARE, offered IBM valuable market 
research. The SE generally saw his job as making it easier for the customer to 
use IBM products and forestalling temptation to look at other vendors.


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Edward Gould <edgould1...@comcast.net>
Sent: Tuesday, January 9, 2018 10:51 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Accessing 65536 devices

> On Jan 9, 2018, at 6:05 AM, John Eells <ee...@us.ibm.com> wrote:
>
> Of course they do.  But, with the Storage and Replication teams spread as 
> they are across several IBM sites and no fewer than 8 timezones, it's usually 
> faster (both in real time and my time) to deal with people who are available 
> in the moment to find the right one or ones to answer a particular question.
>
> And, all appearances to the contrary, I do have a day job.  ;-)
>
> --
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com <mailto:ee...@us.ibm.com>

John,

I don’t expect you to answer this, but here it goes. IBM seems to have gotten 
out of the answering questions mode and seemingly wants to charge for answering 
questions. Isn’t this extremely shortsighted on IBM?
IBM SE’s used to field these questions and gave answers back to the customer 
same day or less.
IBM dropped SE’s so now the customer is left trying to decide what to do. This 
seems to be not only stupid but bad for sales. We now have companies that 
compete with IBM and the only person that management talks to is sales reps. We 
know sales reps aren’t all that reputable (I won’t repeat the half truths and 
quarter lies I have heard from them). To top it off they have the customer 
calling a 1-800 number who knows ZERO about the customer.
If I walked into a car showroom and if I had a question to ask about a car and 
were told that for every question I had I had rot pay say $100, I would walk 
out of the showroom and avoid that car type again. I see no difference than an 
SE being a sales rep that a car dealer.
Ed


--
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: Accessing 65536 devices

[Tom Brennan]

... and now back to watching Star Trek.  It's the one with "The world is 
hollow, and I have touched the sky".


P.S. Thanks to all the IBMer's who help people as best they can every day.

Edward Gould wrote:


John,

I don’t expect you to answer this, but here it goes. IBM seems to have gotten 
out of the answering questions mode and seemingly wants to charge for answering 
questions. Isn’t this extremely shortsighted on IBM?
IBM SE’s used to field these questions and gave answers back to the customer 
same day or less.
IBM dropped SE’s so now the customer is left trying to decide what to do. This 
seems to be not only stupid but bad for sales. We now have companies that 
compete with IBM and the only person that management talks to is sales reps. We 
know sales reps aren’t all that reputable (I won’t repeat the half truths and 
quarter lies I have heard from them). To top it off they have the customer 
calling a 1-800 number who knows ZERO about the customer.
If I walked into a car showroom and if I had a question to ask about a car and 
were told that for every question I had I had rot pay say $100, I would walk 
out of the showroom and avoid that car type again. I see no difference than an 
SE being a sales rep that a car dealer.
Ed


--
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: Accessing 65536 devices

[Edward Gould]

> On Jan 9, 2018, at 6:05 AM, John Eells  wrote:
> 
> Of course they do.  But, with the Storage and Replication teams spread as 
> they are across several IBM sites and no fewer than 8 timezones, it's usually 
> faster (both in real time and my time) to deal with people who are available 
> in the moment to find the right one or ones to answer a particular question.
> 
> And, all appearances to the contrary, I do have a day job.  ;-)
> 
> -- 
> John Eells
> IBM Poughkeepsie
> ee...@us.ibm.com 

John,

I don’t expect you to answer this, but here it goes. IBM seems to have gotten 
out of the answering questions mode and seemingly wants to charge for answering 
questions. Isn’t this extremely shortsighted on IBM?
IBM SE’s used to field these questions and gave answers back to the customer 
same day or less.
IBM dropped SE’s so now the customer is left trying to decide what to do. This 
seems to be not only stupid but bad for sales. We now have companies that 
compete with IBM and the only person that management talks to is sales reps. We 
know sales reps aren’t all that reputable (I won’t repeat the half truths and 
quarter lies I have heard from them). To top it off they have the customer 
calling a 1-800 number who knows ZERO about the customer.
If I walked into a car showroom and if I had a question to ask about a car and 
were told that for every question I had I had rot pay say $100, I would walk 
out of the showroom and avoid that car type again. I see no difference than an 
SE being a sales rep that a car dealer.
Ed


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

Re: Accessing 65536 devices

[Tom Marchant]

On Mon, 8 Jan 2018 22:32:22 +, Jesse 1 Robinson wrote:

>Just to clarify a few points here. The old DASD we're moving off 
>of is not crusty ancient tired iron: it's DS8800 (2424). The new 
>DASD is DS8886 (2834). The motivation for moving is primarily 
>business (fiscal), not technical.

Are you using Exended Address Volumes? EAV volumes can hold a 
terabyte of data, and most data sets can go in the cylinder-managed 
space on an EAV.

>We have millions of customers who are being convertedoto 
>paperless billing, so more and more of them access the system 
>more and more often at all hours of every day. There is virtually 
>no time when all data bases happen to be closed. Closing them 
>is not impossible, but it constitutes a 'total outage' to Customer 
>Service.

I think that FDRPAS and FDRMOVE can handle the migration without 
downtime, while consolidating to fewer, larger volumes. And I think 
that there are other tools that can also be used. I don't know how 
well these tools work in a parallel Sysplex environment.

-- 
Tom Marchant

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

AW: Re: Accessing 65536 devices

[Peter Hunkeler]

>And you do a great job! Seriously, I think that you contribute greatly to the 
>list and you do respond to issues that are relevant to you in an extremely 
>short amount of time, with real answers.
Thank you for all of your hard work.


+1 vote (assuming I only have got one :-)


--
Peter Hunkeler







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

Re: Accessing 65536 devices

[Edward Gould]

> On Jan 9, 2018, at 6:05 AM, John Eells  wrote:
> 
> Edward Finnell wrote:
>> Ain't they gots no eMail?
> 
> Of course they do.  But, with the Storage and Replication teams spread as 
> they are across several IBM sites and no fewer than 8 timezones, it's usually 
> faster (both in real time and my time) to deal with people who are available 
> in the moment to find the right one or ones to answer a particular question.
> 
> And, all appearances to the contrary, I do have a day job.  ;-)

John,

And you do a great job! Seriously, I think that you contribute greatly to the 
list and you do respond to issues that are relevant to you in an extremely 
short amount of time, with real answers.
Thank you for all of your hard work.

Ed 


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

Re: Accessing 65536 devices

[Edward Finnell]

Guess I could envision something like a virtual BRICK for hot topics leading to 
potential sales or upgrades.


In a message dated 1/9/2018 6:05:35 AM Central Standard Time, ee...@us.ibm.com 
writes:

 
to deal with people who 

are available in the moment to find the right one or ones to answer a 
particular question.

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

Re: Accessing 65536 devices

[John Eells]

Edward Finnell wrote:

Ain't they gots no eMail?


Of course they do.  But, with the Storage and Replication teams spread 
as they are across several IBM sites and no fewer than 8 timezones, it's 
usually faster (both in real time and my time) to deal with people who 
are available in the moment to find the right one or ones to answer a 
particular question.


And, all appearances to the contrary, I do have a day job.  ;-)

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Accessing 65536 devices

[John Eells]

I am told that TDMF provides access to devices via SCS0 only.

John Eells wrote:

Ward, Mike S wrote:

Innovation has a product called FDRPAS that can be rented that does
the copies while the system is up and running. We have used it several
times and it works great.



I have no experience with FDRPAS or its IBM counterparts (like TDMF, if
I recall correctly).  However, unless they are able to talk to devices
in subchannel sets other than SCS0, none would solve Skip's problem.

I'm afraid I don't know whether any of them talk to devices outside
SCS0, and nobody I know who might be able to answer that question seems
to be around this afternoon.

I am not really a Storage guy, so I don't know whether it fits the bill
from an ease-of-use (or cost) point of view, but as PPRC secondaries and
FlashCopy targets *can* be defined in SCSs other than zero, one could
for example potentially establish (for example) the needed PPRC pairs,
let PPRC do the copies, and then take the primaries offline.  Whether
this would work, and whether it could even be done with HyperSwap so
there was no required outage, is another question I'd need those same
people for...the ones that aren't around today, I mean.



--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Accessing 65536 devices

[Jesse 1 Robinson]

Just to clarify a few points here. The old DASD we're moving off of is not 
crusty ancient tired iron: it's DS8800 (2424). The new DASD is DS8886 (2834). 
The motivation for moving is primarily business (fiscal), not technical.

We have millions of customers who are being converted to paperless billing, so 
more and more of them access the system more and more often at all hours of 
every day. There is virtually no time when all data bases happen to be closed. 
Closing them is not impossible, but it constitutes a 'total outage' to Customer 
Service. 

Besides striving to provide continuous availability for our customers' sake, we 
are also mandated by the California Public Utilities Commission to service 
customers' issues in a timely way that gets translated to dollars and cents. An 
extra incentive to minimize total outages.

We maintain three sets of DASD volumes: primary (production), secondary (XRC 
mirror), and tertiary (flash copy from secondary to run DR). These add up to a 
lot of UCBs in addition to lots of virtual tapes and lots of FICON CTCs. 

We're looking at ways to move PAVs to SCS1. Maybe even also the tertiary DR 
volumes. The goal is free up enough SCS0 addresses to put old and new boxes 
online. Meanwhile the new DASD is on the floor, and we need to utilize it. 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Sunday, January 07, 2018 8:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Accessing 65536 devices

On 1/6/2018 12:27 PM, Mike Schwab wrote:
> If your new dasd allows dynamic growing a volume, you can grow a 
> non-EAV to the maximum EAV volume size, but no bigger.

That was my favorite feature of our old DS8100! We lost that feature when we 
upgraded to DS8870, but so far it hasn't been a problem because we planned 
fairly well.

Having said that, we're running a bit short on mod-216 volumes. I was thinking 
about removing eight of our mod-27s to make room for one more of these bad 
boys! Of course, that kind of re-allocation can be done with the DS8870, just 
not quite as easily as with the DS8100 because you can't grow a device in place.

The downside to in-place growth is varying levels of support from, and 
different procedures for, Linux for Z (we use RHEL), z/VM, z/VSE, and older 
releases of z/OS. You need to be careful or things can go FUBAR in a hurry! 
(Volume backups are a wonderful thing...)

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


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

Re: Accessing 65536 devices

[Ed Jaffe]

On 1/6/2018 12:27 PM, Mike Schwab wrote:

If your new dasd allows dynamic growing a volume, you can grow a
non-EAV to the maximum EAV volume size, but no bigger.


That was my favorite feature of our old DS8100! We lost that feature 
when we upgraded to DS8870, but so far it hasn't been a problem because 
we planned fairly well.


Having said that, we're running a bit short on mod-216 volumes. I was 
thinking about removing eight of our mod-27s to make room for one more 
of these bad boys! Of course, that kind of re-allocation can be done 
with the DS8870, just not quite as easily as with the DS8100 because you 
can't grow a device in place.


The downside to in-place growth is varying levels of support from, and 
different procedures for, Linux for Z (we use RHEL), z/VM, z/VSE, and 
older releases of z/OS. You need to be careful or things can go FUBAR in 
a hurry! (Volume backups are a wonderful thing...)


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Accessing 65536 devices

[Ron hawkins]

Mike,

The 2nd part of your reply will require 3390-A to support  DVE.

Hopefully, that is all that used for new DASD subsystems, for a few years now.


Ron

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: Saturday, January 6, 2018 12:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Accessing 65536 devices

TDMF does include a logical data mover.  When a database is closed it will swap 
over.  During shutdown for an IPL it should get the remaining datasets.
If your new dasd allows dynamic growing a volume, you can grow a non-EAV to the 
maximum EAV volume size, but no bigger.

On Sat, Jan 6, 2018 at 1:43 PM, Feller, Paul <paul.fel...@transamerica.com> 
wrote:
> Using FDRPAS or TDMF to go from smaller volumes to larger volumes will take 
> you only so far.  You can move one MOD3 to one MOD9 (or MOD whatever).  After 
> that you have to move datasets.  I know there is another FDR product that 
> will help move datasets, but even that has limitations.  Naturally you could 
> use SMS to help by disabling new allocations to the MOD3 and over time things 
> may move as datasets are reallocated.  At some point you will have to have 
> subsystems down (or lpars down) to move datasets.
>
> As we have swapped out DASD subsystems we have gone through the pain of 
> eliminating as many MOD3 volumes as we could.  There came a point when we had 
> to get business unit approval to take things like CICS or DB2 or IMS or MQ or 
> even whole lpars down to move datasets.
>
> Thanks..
>
> Paul Feller
> AGT Mainframe Technical Support
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Ed Jaffe
> Sent: Friday, January 05, 2018 21:39
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Accessing 65536 devices
>
> On 1/5/2018 12:06 PM, John Eells wrote:
>> Ward, Mike S wrote:
>>> Innovation has a product called FDRPAS that can be rented that does 
>>> the copies while the system is up and running. We have used it 
>>> several times and it works great.
>> 
>>
>> I have no experience with FDRPAS or its IBM counterparts (like TDMF, 
>> if I recall correctly).  However, unless they are able to talk to 
>> devices in subchannel sets other than SCS0, none would solve Skip's 
>> problem.
>
> Yes, they would! What Skip should do is upgrade from whatever ancient 
> DASD configuration has been carried forward at SCE for decades to 
> modern, 21st-century DASD geometries. FDRPAS and similar products will 
> help him do that seamlessly. Even being past the half-way point on UCB 
> count won't be an issue if he consolidates his mod-3 DASD pools to 
> mod-27s, which are nine times larger. Even an extremely-conservative 
> conversion to (still quite ancient) mod-9s can cut the device address 
> footprint by 2/3!
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.phoenixsoftwar
> ecom_=DwIDaQ=9g4MJkl2VjLjS6R4ei18BA=eUhu3PeeWy6RTndlJVKembFjFsvw
> Ca8eeU_gm45NyOc=7YFFfIHl6r7-leHPbtq0ChsKfyZLk4xwNbMMmmj3wVo=DVbod8
> a0Hfy-mVgiikk-AOW5mJut8kVcuXk8CMZ5T_8=
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

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

Re: Accessing 65536 devices

[Mike Schwab]

TDMF does include a logical data mover.  When a database is closed it
will swap over.  During shutdown for an IPL it should get the
remaining datasets.
If your new dasd allows dynamic growing a volume, you can grow a
non-EAV to the maximum EAV volume size, but no bigger.

On Sat, Jan 6, 2018 at 1:43 PM, Feller, Paul
<paul.fel...@transamerica.com> wrote:
> Using FDRPAS or TDMF to go from smaller volumes to larger volumes will take 
> you only so far.  You can move one MOD3 to one MOD9 (or MOD whatever).  After 
> that you have to move datasets.  I know there is another FDR product that 
> will help move datasets, but even that has limitations.  Naturally you could 
> use SMS to help by disabling new allocations to the MOD3 and over time things 
> may move as datasets are reallocated.  At some point you will have to have 
> subsystems down (or lpars down) to move datasets.
>
> As we have swapped out DASD subsystems we have gone through the pain of 
> eliminating as many MOD3 volumes as we could.  There came a point when we had 
> to get business unit approval to take things like CICS or DB2 or IMS or MQ or 
> even whole lpars down to move datasets.
>
> Thanks..
>
> Paul Feller
> AGT Mainframe Technical Support
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Ed Jaffe
> Sent: Friday, January 05, 2018 21:39
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Accessing 65536 devices
>
> On 1/5/2018 12:06 PM, John Eells wrote:
>> Ward, Mike S wrote:
>>> Innovation has a product called FDRPAS that can be rented that does
>>> the copies while the system is up and running. We have used it
>>> several times and it works great.
>> 
>>
>> I have no experience with FDRPAS or its IBM counterparts (like TDMF,
>> if I recall correctly).  However, unless they are able to talk to
>> devices in subchannel sets other than SCS0, none would solve Skip's
>> problem.
>
> Yes, they would! What Skip should do is upgrade from whatever ancient
> DASD configuration has been carried forward at SCE for decades to
> modern, 21st-century DASD geometries. FDRPAS and similar products will
> help him do that seamlessly. Even being past the half-way point on UCB
> count won't be an issue if he consolidates his mod-3 DASD pools to
> mod-27s, which are nine times larger. Even an extremely-conservative
> conversion to (still quite ancient) mod-9s can cut the device address
> footprint by 2/3!
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.phoenixsoftware.com_=DwIDaQ=9g4MJkl2VjLjS6R4ei18BA=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc=7YFFfIHl6r7-leHPbtq0ChsKfyZLk4xwNbMMmmj3wVo=DVbod8a0Hfy-mVgiikk-AOW5mJut8kVcuXk8CMZ5T_8=
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Accessing 65536 devices

[Feller, Paul]

Using FDRPAS or TDMF to go from smaller volumes to larger volumes will take you 
only so far.  You can move one MOD3 to one MOD9 (or MOD whatever).  After that 
you have to move datasets.  I know there is another FDR product that will help 
move datasets, but even that has limitations.  Naturally you could use SMS to 
help by disabling new allocations to the MOD3 and over time things may move as 
datasets are reallocated.  At some point you will have to have subsystems down 
(or lpars down) to move datasets.

As we have swapped out DASD subsystems we have gone through the pain of 
eliminating as many MOD3 volumes as we could.  There came a point when we had 
to get business unit approval to take things like CICS or DB2 or IMS or MQ or 
even whole lpars down to move datasets.

Thanks..

Paul Feller
AGT Mainframe Technical Support


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Friday, January 05, 2018 21:39
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Accessing 65536 devices

On 1/5/2018 12:06 PM, John Eells wrote:
> Ward, Mike S wrote:
>> Innovation has a product called FDRPAS that can be rented that does 
>> the copies while the system is up and running. We have used it 
>> several times and it works great.
> 
>
> I have no experience with FDRPAS or its IBM counterparts (like TDMF, 
> if I recall correctly).  However, unless they are able to talk to 
> devices in subchannel sets other than SCS0, none would solve Skip's 
> problem.

Yes, they would! What Skip should do is upgrade from whatever ancient 
DASD configuration has been carried forward at SCE for decades to 
modern, 21st-century DASD geometries. FDRPAS and similar products will 
help him do that seamlessly. Even being past the half-way point on UCB 
count won't be an issue if he consolidates his mod-3 DASD pools to 
mod-27s, which are nine times larger. Even an extremely-conservative 
conversion to (still quite ancient) mod-9s can cut the device address 
footprint by 2/3!

-- 
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.phoenixsoftware.com_=DwIDaQ=9g4MJkl2VjLjS6R4ei18BA=eUhu3PeeWy6RTndlJVKembFjFsvwCa8eeU_gm45NyOc=7YFFfIHl6r7-leHPbtq0ChsKfyZLk4xwNbMMmmj3wVo=DVbod8a0Hfy-mVgiikk-AOW5mJut8kVcuXk8CMZ5T_8=

--
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: Accessing 65536 devices

[Ed Jaffe]

On 1/5/2018 12:06 PM, John Eells wrote:

Ward, Mike S wrote:
Innovation has a product called FDRPAS that can be rented that does 
the copies while the system is up and running. We have used it 
several times and it works great.



I have no experience with FDRPAS or its IBM counterparts (like TDMF, 
if I recall correctly).  However, unless they are able to talk to 
devices in subchannel sets other than SCS0, none would solve Skip's 
problem.


Yes, they would! What Skip should do is upgrade from whatever ancient 
DASD configuration has been carried forward at SCE for decades to 
modern, 21st-century DASD geometries. FDRPAS and similar products will 
help him do that seamlessly. Even being past the half-way point on UCB 
count won't be an issue if he consolidates his mod-3 DASD pools to 
mod-27s, which are nine times larger. Even an extremely-conservative 
conversion to (still quite ancient) mod-9s can cut the device address 
footprint by 2/3!


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Accessing 65536 devices

[Ron hawkins]

FDRMOVE anyone.



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Friday, January 5, 2018 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Accessing 65536 devices

We have device count reduction on our wish list. Unfortunately we know of no 
way to accomplish that without taking (multiple) application outages to 
consolidate data on fewer larger volumes. High impact and high risk with the 
benefit going mainly to infrastructure care-and-feeders. Our stated goal of 
rolling-IPLs whenever possible would be severely compromised. 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Friday, January 05, 2018 2:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Accessing 65536 devices

On 1/5/2018 3:52 AM, John Eells wrote:
> Jesse 1 Robinson wrote:
>> We would like to be able to access >65535 device addresses (UCBs) 
>> from a single LPAR via a single IODF. The need is for bringing a new 
>> DASD subsystem online while retaining the old subsystem until all 
>> volumes can be copied across. We currently have spare UCBs available, 
>> but not enough to have all old and new devices online at the same 
>> time. Is this possible?
>
> You can have a maximum of 65,280* devices (not quite 64K) in 
> Subchannel Set 0.  There are some things that can be accessed via 
> other SCSs, but IIRC the exceptions don't allow you to have more than
> 65,280 primary devices online concurrently.  That includes all 
> devices, of course, including networking, tape, consoles, and such.

Skip, you might consider standardizing on larger capacity devices where it 
makes sense to do so. We were *very* constrained on the total number of UCBs we 
could have, based on architectural point-to-point (no switch) FICON limits, and 
so we eliminated ALL of our mod-3 3390s a couple of years ago. We now have only 
mod-9, mod-27 and mod-216 devices. (FWIW, the most popular -- and most numerous 
-- ended up being the mod-27s.)

It's like a breath of fresh air!

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


--
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: Accessing 65536 devices

[Ed Jaffe]

On 1/5/2018 2:27 PM, Jesse 1 Robinson wrote:

We have device count reduction on our wish list. Unfortunately we know of no 
way to accomplish that without taking (multiple) application outages to 
consolidate data on fewer larger volumes. High impact and high risk with the 
benefit going mainly to infrastructure care-and-feeders. Our stated goal of 
rolling-IPLs whenever possible would be severely compromised.


All of the popular z/OS "disk migration" ISV tools allow you to do this 
without taking down applications. Track by track migration of extents 
that are not currently "open" is child's play. The sophistication is in 
the handling of the "in use" tracks on the old volumes. I/Os against 
them are intercepted and transparently redirected to the new volumes 
until such time as those extents are eventually closed. After that, it's 
BAU.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Accessing 65536 devices

[Jesse 1 Robinson]

We have device count reduction on our wish list. Unfortunately we know of no 
way to accomplish that without taking (multiple) application outages to 
consolidate data on fewer larger volumes. High impact and high risk with the 
benefit going mainly to infrastructure care-and-feeders. Our stated goal of 
rolling-IPLs whenever possible would be severely compromised. 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Friday, January 05, 2018 2:12 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Accessing 65536 devices

On 1/5/2018 3:52 AM, John Eells wrote:
> Jesse 1 Robinson wrote:
>> We would like to be able to access >65535 device addresses (UCBs) 
>> from a single LPAR via a single IODF. The need is for bringing a new 
>> DASD subsystem online while retaining the old subsystem until all 
>> volumes can be copied across. We currently have spare UCBs available, 
>> but not enough to have all old and new devices online at the same 
>> time. Is this possible?
>
> You can have a maximum of 65,280* devices (not quite 64K) in 
> Subchannel Set 0.  There are some things that can be accessed via 
> other SCSs, but IIRC the exceptions don't allow you to have more than
> 65,280 primary devices online concurrently.  That includes all 
> devices, of course, including networking, tape, consoles, and such.

Skip, you might consider standardizing on larger capacity devices where it 
makes sense to do so. We were *very* constrained on the total number of UCBs we 
could have, based on architectural point-to-point (no switch) FICON limits, and 
so we eliminated ALL of our mod-3 3390s a couple of years ago. We now have only 
mod-9, mod-27 and mod-216 devices. (FWIW, the most popular -- and most numerous 
-- ended up being the mod-27s.)

It's like a breath of fresh air!

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


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

Re: Accessing 65536 devices

[Ed Jaffe]

On 1/5/2018 3:52 AM, John Eells wrote:

Jesse 1 Robinson wrote:
We would like to be able to access >65535 device addresses (UCBs) 
from a single LPAR via a single IODF. The need is for bringing a new 
DASD subsystem online while retaining the old subsystem until all 
volumes can be copied across. We currently have spare UCBs available, 
but not enough to have all old and new devices online at the same 
time. Is this possible?


You can have a maximum of 65,280* devices (not quite 64K) in 
Subchannel Set 0.  There are some things that can be accessed via 
other SCSs, but IIRC the exceptions don't allow you to have more than 
65,280 primary devices online concurrently.  That includes all 
devices, of course, including networking, tape, consoles, and such.


Skip, you might consider standardizing on larger capacity devices where 
it makes sense to do so. We were *very* constrained on the total number 
of UCBs we could have, based on architectural point-to-point (no switch) 
FICON limits, and so we eliminated ALL of our mod-3 3390s a couple of 
years ago. We now have only mod-9, mod-27 and mod-216 devices. (FWIW, 
the most popular -- and most numerous -- ended up being the mod-27s.)


It's like a breath of fresh air!

--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Accessing 65536 devices

[Edward Finnell]

Ain't they gots no eMail?


In a message dated 1/5/2018 2:07:03 PM Central Standard Time, ee...@us.ibm.com 
writes:

 
there was no required outage, is another question I'd need those same 

people for...the ones that aren't around today, I mean.

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

Re: Accessing 65536 devices

[Seymour J Metz]

UCBs are not devices. There is no way for a single z/OS system to access more 
than 64Ki minus 256 devices, although you can add additional exposures to 
existing devices.


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


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Jesse 1 Robinson <jesse1.robin...@sce.com>
Sent: Thursday, January 4, 2018 5:35 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Accessing 65536 devices

We would like to be able to access >65535 device addresses (UCBs) from a single 
LPAR via a single IODF. The need is for bringing a new DASD subsystem online 
while retaining the old subsystem until all volumes can be copied across. We 
currently have spare UCBs available, but not enough to have all old and new 
devices online at the same time. Is this possible?

.
.
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<mailto:robin...@sce.com>


--
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: Accessing 65536 devices

[John Eells]

Ward, Mike S wrote:

Innovation has a product called FDRPAS that can be rented that does the copies 
while the system is up and running. We have used it several times and it works 
great.



I have no experience with FDRPAS or its IBM counterparts (like TDMF, if 
I recall correctly).  However, unless they are able to talk to devices 
in subchannel sets other than SCS0, none would solve Skip's problem.


I'm afraid I don't know whether any of them talk to devices outside 
SCS0, and nobody I know who might be able to answer that question seems 
to be around this afternoon.


I am not really a Storage guy, so I don't know whether it fits the bill 
from an ease-of-use (or cost) point of view, but as PPRC secondaries and 
FlashCopy targets *can* be defined in SCSs other than zero, one could 
for example potentially establish (for example) the needed PPRC pairs, 
let PPRC do the copies, and then take the primaries offline.  Whether 
this would work, and whether it could even be done with HyperSwap so 
there was no required outage, is another question I'd need those same 
people for...the ones that aren't around today, I mean.


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Accessing 65536 devices

[Feller, Paul]

We started putting PAV aliases into SS1 to save on UCBs.  It does make for an 
interesting IODF.  The only issue was with z/VM.  We have several z/VM lpars 
along with our z/OS lpars.  z/VM currently can't handle PAV aliases in SS1, 
they have to be in SS0.

Thanks..

Paul Feller
AGT Mainframe Technical Support

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Friday, January 05, 2018 05:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Accessing 65536 devices

Jesse 1 Robinson wrote:
> We would like to be able to access >65535 device addresses (UCBs) from a 
> single LPAR via a single IODF. The need is for bringing a new DASD subsystem 
> online while retaining the old subsystem until all volumes can be copied 
> across. We currently have spare UCBs available, but not enough to have all 
> old and new devices online at the same time. Is this possible?

You can have a maximum of 65,280* devices (not quite 64K) in Subchannel 
Set 0.  There are some things that can be accessed via other SCSs, but 
IIRC the exceptions don't allow you to have more than 65,280 primary 
devices online concurrently.  That includes all devices, of course, 
including networking, tape, consoles, and such.

If replication and PAVs are eating into SCS0, you can move the 
secondaries to another SCS to "make room" in SCS0 for additional primary 
devices.  When last I looked, these could be defined in other SCSs:

- PPRC secondary devices
- PAV aliases
- FlashCopy target devices

Perhaps that would free up enough slots in SCS0 for you.  (It seems to 
work for almost everyone.)

There is a very narrow exception to the above for IPLing from nonzero 
subchannel sets for a small number of volumes.  (I don't have that list 
handy, but IIRC it includes at least the IPL and IODF volumes but not 
many more than that.)

* We reserve 256 subchannels in SCS0 for future use.

-- 
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
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: Accessing 65536 devices

[Ward, Mike S]

Innovation has a product called FDRPAS that can be rented that does the copies 
while the system is up and running. We have used it several times and it works 
great.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, January 04, 2018 5:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Accessing 65536 devices

I think I out-clevered myself. x'' is the highest numbered device, but 
since x'' is also a valid device number, the total number is 65,536 UCBs. 
In any case, we need to go beyond that limit in a single LPAR. It's only 
temporary, but the alternative is drawn out and laborious. 

1. Identify some subset of the new subsystem that can be accommodated in the 
current IODF.
2. Activate a new IODF with that subset defined.
3. Copy old volumes to new within that range.
4. Activate a new IODF that deletes the old volumes already copied.
5. Rinse and repeat until the last of the old volumes have been copied.
6. Activate a new IODF that deletes the old subsystem entirely. 

We've been through this house of mirrors many times in the past. It takes 
months. I'm hoping for a linear approach that allows us to copy all volumes in 
a single exercise. 


.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, January 04, 2018 3:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Accessing 65536 devices

Yes. 65,535 is the maximum number of devices that can be represented with four 
hex digits. If you add one more device, you need an extra hex digit. I 
understand that channel sets can allow for more than 64K UCBs in an IODF, but I 
thought that no single LPAR could address all of them at the same time. In 
order to copy old volumes to new, we have to have all of them online 
concurrently. 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Thursday, January 04, 2018 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Accessing 65536 devices

Ah, UCB's are HEX, so x'' = 65535, correct?

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, January 04, 2018 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Accessing 65536 devices

So this would involve 5-digit UCBs? We could probably manage that as long as 
all devices are concurrently accessible. Aren't commands like VARY limited to 
four digits?

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Thursday, January 04, 2018 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Fw: Accessing 65536 devices

 By using the CSSID/SS*  in the  IODF you can get way more than the  basic 
number

 Example from a z13

   CSS Devices in SS0Devices in SS1Devices in SS2Devices
 in SS3
 / ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum  + Actual
 _ 0   65280 12384   65535 0   65535 0   65535   0
 _ 1   65280 0   65535 0   65535 0   65535   0
 _ 2   65280 0   65535 0   65535 0   65535   0
 _ 3   65280 0   65535 0   65535 0   65535   0
 _ 4   65280 0   65535 0   65535 0   65535   0
 _ 5   65280 0   65535 0   65535 0   65535   0


 --
 Jerry Whitteridge

 IBM Global Services
 Delivery Manager
 e-Mail: jerry.whitteri...@ibm.com
 Cell: 602 527 4871 < Note New Phone Number


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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-m

Re: Accessing 65536 devices

[John Eells]

Jesse 1 Robinson wrote:

We would like to be able to access >65535 device addresses (UCBs) from a single 
LPAR via a single IODF. The need is for bringing a new DASD subsystem online while 
retaining the old subsystem until all volumes can be copied across. We currently 
have spare UCBs available, but not enough to have all old and new devices online 
at the same time. Is this possible?


You can have a maximum of 65,280* devices (not quite 64K) in Subchannel 
Set 0.  There are some things that can be accessed via other SCSs, but 
IIRC the exceptions don't allow you to have more than 65,280 primary 
devices online concurrently.  That includes all devices, of course, 
including networking, tape, consoles, and such.


If replication and PAVs are eating into SCS0, you can move the 
secondaries to another SCS to "make room" in SCS0 for additional primary 
devices.  When last I looked, these could be defined in other SCSs:


- PPRC secondary devices
- PAV aliases
- FlashCopy target devices

Perhaps that would free up enough slots in SCS0 for you.  (It seems to 
work for almost everyone.)


There is a very narrow exception to the above for IPLing from nonzero 
subchannel sets for a small number of volumes.  (I don't have that list 
handy, but IIRC it includes at least the IPL and IODF volumes but not 
many more than that.)


* We reserve 256 subchannels in SCS0 for future use.

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Accessing 65536 devices

[Ravi Gaur]

Why can't you define the CSS id more than 1 and then have partition access to 
that as well so example as below 

  CSS Devices in SS0Devices in SS1Devices in SS2Devices in SS3 
/ ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum + Actual   
_ 0   65280 10684   65535 0   65535 0   65535 0
_ 1   65280 0   65535 0   65535 0   65535 0
_ 2   65280 364 65535 0   65535 0   65535 0
_ 3   65280 321865535 0   65535 0   65535 0
_ 4   65280 0   65535 0   65535 0   65535 0
_ 5   65280 0   65535 0   65535 0   65535 0  

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

Re: Accessing 65536 devices

[Jesse 1 Robinson]

I think I out-clevered myself. x'' is the highest numbered device, but 
since x'' is also a valid device number, the total number is 65,536 UCBs. 
In any case, we need to go beyond that limit in a single LPAR. It's only 
temporary, but the alternative is drawn out and laborious. 

1. Identify some subset of the new subsystem that can be accommodated in the 
current IODF.
2. Activate a new IODF with that subset defined.
3. Copy old volumes to new within that range.
4. Activate a new IODF that deletes the old volumes already copied.
5. Rinse and repeat until the last of the old volumes have been copied.
6. Activate a new IODF that deletes the old subsystem entirely. 

We've been through this house of mirrors many times in the past. It takes 
months. I'm hoping for a linear approach that allows us to copy all volumes in 
a single exercise. 


.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, January 04, 2018 3:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Accessing 65536 devices

Yes. 65,535 is the maximum number of devices that can be represented with four 
hex digits. If you add one more device, you need an extra hex digit. I 
understand that channel sets can allow for more than 64K UCBs in an IODF, but I 
thought that no single LPAR could address all of them at the same time. In 
order to copy old volumes to new, we have to have all of them online 
concurrently. 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Thursday, January 04, 2018 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Accessing 65536 devices

Ah, UCB's are HEX, so x'' = 65535, correct?

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, January 04, 2018 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Accessing 65536 devices

So this would involve 5-digit UCBs? We could probably manage that as long as 
all devices are concurrently accessible. Aren't commands like VARY limited to 
four digits?

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Thursday, January 04, 2018 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Fw: Accessing 65536 devices

 By using the CSSID/SS*  in the  IODF you can get way more than the  basic 
number

 Example from a z13

   CSS Devices in SS0Devices in SS1Devices in SS2Devices
 in SS3
 / ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum  + Actual
 _ 0   65280 12384   65535 0   65535 0   65535   0
 _ 1   65280 0   65535 0   65535 0   65535   0
 _ 2   65280 0   65535 0   65535 0   65535   0
 _ 3   65280 0   65535 0   65535 0   65535   0
 _ 4   65280 0   65535 0   65535 0   65535   0
 _ 5   65280 0   65535 0   65535 0   65535   0


 --
 Jerry Whitteridge

 IBM Global Services
 Delivery Manager
 e-Mail: jerry.whitteri...@ibm.com
 Cell: 602 527 4871 < Note New Phone Number


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

Re: Accessing 65536 devices

[Jesse 1 Robinson]

Yes. 65,535 is the maximum number of devices that can be represented with four 
hex digits. If you add one more device, you need an extra hex digit. I 
understand that channel sets can allow for more than 64K UCBs in an IODF, but I 
thought that no single LPAR could address all of them at the same time. In 
order to copy old volumes to new, we have to have all of them online 
concurrently. 

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Nims,Alva John (Al)
Sent: Thursday, January 04, 2018 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Accessing 65536 devices

Ah, UCB's are HEX, so x'' = 65535, correct?

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, January 04, 2018 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Accessing 65536 devices

So this would involve 5-digit UCBs? We could probably manage that as long as 
all devices are concurrently accessible. Aren't commands like VARY limited to 
four digits?

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Thursday, January 04, 2018 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Fw: Accessing 65536 devices

 By using the CSSID/SS*  in the  IODF you can get way more than the  basic 
number

 Example from a z13

   CSS Devices in SS0Devices in SS1Devices in SS2Devices
 in SS3
 / ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum  + Actual
 _ 0   65280 12384   65535 0   65535 0   65535   0
 _ 1   65280 0   65535 0   65535 0   65535   0
 _ 2   65280 0   65535 0   65535 0   65535   0
 _ 3   65280 0   65535 0   65535 0   65535   0
 _ 4   65280 0   65535 0   65535 0   65535   0
 _ 5   65280 0   65535 0   65535 0   65535   0


 --
 Jerry Whitteridge

 IBM Global Services
 Delivery Manager
 e-Mail: jerry.whitteri...@ibm.com
 Cell: 602 527 4871 < Note New Phone Number


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

Re: Accessing 65536 devices

[Nims,Alva John (Al)]

Ah, UCB's are HEX, so x'' = 65535, correct?

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Thursday, January 04, 2018 6:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Accessing 65536 devices

So this would involve 5-digit UCBs? We could probably manage that as long as 
all devices are concurrently accessible. Aren't commands like VARY limited to 
four digits?

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Thursday, January 04, 2018 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Fw: Accessing 65536 devices

 By using the CSSID/SS*  in the  IODF you can get way more than the  basic 
number

 Example from a z13

   CSS Devices in SS0Devices in SS1Devices in SS2Devices
 in SS3
 / ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum  + Actual
 _ 0   65280 12384   65535 0   65535 0   65535   0
 _ 1   65280 0   65535 0   65535 0   65535   0
 _ 2   65280 0   65535 0   65535 0   65535   0
 _ 3   65280 0   65535 0   65535 0   65535   0
 _ 4   65280 0   65535 0   65535 0   65535   0
 _ 5   65280 0   65535 0   65535 0   65535   0


 --
 Jerry Whitteridge

 IBM Global Services
 Delivery Manager
 e-Mail: jerry.whitteri...@ibm.com
 Cell: 602 527 4871 < Note New Phone Number

--
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: Accessing 65536 devices

[Jesse 1 Robinson]

So this would involve 5-digit UCBs? We could probably manage that as long as 
all devices are concurrently accessible. Aren't commands like VARY limited to 
four digits?

.
.
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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jerry Whitteridge
Sent: Thursday, January 04, 2018 3:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Fw: Accessing 65536 devices

 By using the CSSID/SS*  in the  IODF you can get way more than the  basic 
number

 Example from a z13

   CSS Devices in SS0Devices in SS1Devices in SS2Devices
 in SS3
 / ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum  + Actual
 _ 0   65280 12384   65535 0   65535 0   65535   0
 _ 1   65280 0   65535 0   65535 0   65535   0
 _ 2   65280 0   65535 0   65535 0   65535   0
 _ 3   65280 0   65535 0   65535 0   65535   0
 _ 4   65280 0   65535 0   65535 0   65535   0
 _ 5   65280 0   65535 0   65535 0   65535   0


 --
 Jerry Whitteridge

 IBM Global Services
 Delivery Manager
 e-Mail: jerry.whitteri...@ibm.com
 Cell: 602 527 4871 < Note New Phone Number

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

Fw: Accessing 65536 devices

[Jerry Whitteridge]

 By using the CSSID/SS*  in the  IODF you can get way more than the
 basic number

 Example from a z13

   CSS Devices in SS0Devices in SS1Devices in SS2Devices
 in SS3
 / ID  Maximum + Actual  Maximum + Actual  Maximum + Actual  Maximum
 + Actual
 _ 0   65280 12384   65535 0   65535 0   65535   0
 _ 1   65280 0   65535 0   65535 0   65535   0
 _ 2   65280 0   65535 0   65535 0   65535   0
 _ 3   65280 0   65535 0   65535 0   65535   0
 _ 4   65280 0   65535 0   65535 0   65535   0
 _ 5   65280 0   65535 0   65535 0   65535   0


 --
 Jerry Whitteridge

 IBM Global Services
 Delivery Manager
 e-Mail: jerry.whitteri...@ibm.com
 Cell: 602 527 4871 < Note New Phone Number

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

Accessing 65536 devices

[Jesse 1 Robinson]

We would like to be able to access >65535 device addresses (UCBs) from a single 
LPAR via a single IODF. The need is for bringing a new DASD subsystem online 
while retaining the old subsystem until all volumes can be copied across. We 
currently have spare UCBs available, but not enough to have all old and new 
devices online at the same time. Is this possible?

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


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