On 10/17/2018 6:44 PM, Jesse 1 Robinson wrote:
In hindsight I rue the decision to set aside both 4xxx and 5xxx addresses. In 
practice, the low order digit is severely underused. In the beginning I thought 
that we would need several different 'devices' for each LPAR. Never actually 
found a need for more than four, 0 - 3. I like Rob Jackson's idea of assigning 
even/odd numbers for gazinta and gazouta, or ranges like 0 - 7 and 8 - F. 
Eliminating 5xxx, for example, would free up 4096 addresses for DASD.

It wasn't your fault. It was IBM's recommendation.

The fact is that all but one bit of position 'w' is wasted and position 'x' is nearly always underutilized in the scheme below. However, it's not uncommon at all to have more than 16 LPARs per processor making position 'y' too small in today's world.

It works great for small configurations, but should be reworked for larger environments -- perhaps by combining 'w' and 'x' to a single nybble and expanding 'y' to two nybbles.

CTC 4-DIGIT NAMING SCHEME: wxyz
w - one nibble to distinguish gazinta from gazouta
x - one nibble that uniquely represents a processor; assigned by you arbitrarily y - one nibble that represents an LPAR on processor w, such as LPAR id from HCD
z - one nibble to complete device address, assigned from 0 up to F

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


--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to