I'm not sure I buy this highly speculative explanation.
There's a big difference between not allowing multiple blocks per member and
not considering second blocks to be necessary. Furthermore, to "solve" the
problem by introducing multiple members per userid, rather than multiple blocks
per member, defies credibility.
At best, this is a non sequitur. The OP's question was, "Why are TSO IDs
limited to 7 characters?" The explanation given relies on the fact that the
userid was already defined as less than eight characters.
I used TSO under MVT in the early '70s on 2741s (and SPF, but not on 2741s) and
the notion that the seven character userid plus one byte length was
specifically to make it fit in a doubleword seems a stretch. Sitting at a
2741, the response time was such that the thought that the code had been
optimized in such detail never entered one's head.
I agree that TSO still works extremely well today, so I'm not knocking its
design. However, if IBM were to increase the maximum userid length, a lot of
40 year old software would stop working.
> Date: Sat, 6 Nov 2010 08:01:46 -0600
> From: rfocht...@ync.net
> Subject: Re: Why are TSO IDs limited to 7 characters
> To: IBM-MAIN@bama.ua.edu
>
> The original UADS dataset blksize was dictated by the DASD devices of
> the time, which sometimes included track sizes of 2000 bytes (2321, for
> example). The design of UADS and the code that used it would not allow
> multiple blocks per member, because no second block was ever considered
> necessary. Later, when the information content increased, the solution
> implemented was multiple members, based on the seven-character (or less)
> user id, suffixed with a numeric digit. The sequence always started with
> zero and went up from there.
>
> Also, some of the TSO control blocks contained the USERID length in the
> first character, followed by up to a seven-character userid. Alignment
> sensitivies required that this information all fit into a double-word,
> so that succeeding fields in the block could be kept aligned and still
> minimize the space required. Recall that the S/360, where TSO was
> originally designed, was very sensitive to alignment issues and there
> was no virtual storage to expand blocks, etc. S0C5 abends were quite
> common, whereas they are almost unheard-of today.
>
> Considering how old TSO really is, I'm surprised that it still works as
> well as it does today, while still maintaining backward compatability. :-)
>
> Rick
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
