Re: Converting programs to accommodate 8-character userids and prefixes

[Edward Gould]

> On Dec 19, 2017, at 11:38 PM, Sam Golob  wrote:
> 
> Hi Ed,
> 
> Ah, nostalgia!!!
> 
> Funny thing is, UADS was studied in depth by Jim Marshall in the early 
> 90's.  And although it's not too wise to use it (via the ACCOUNT command) to 
> define working userids in a production system, but on a development system 
> the knowledge of SYS1.UADS can come in very handy.  See Jim's files:  CBT 
> Files 300 and 316.  Very neat stuff.  Jim also got me involved in studying 
> SYS1.BRODCAST at that time, and that knowledge from him, helped get me 
> started to develop my SYS1.BRODCAST package (free version on CBT File 247).  
> Of course I didn't do it just for fun.  Our installation was (effectively) a 
> service bureau, in which we had to preserve one of our subsidiary data 
> center's BRODCAST messages, and we couldn't just wipe BRODCAST with the SYNC 
> command the way IBM "requires".  We had to do it intelligently--not just burn 
> down the barn and rebuild it, every time it got dirty.  So I wrote programs 
> to back SYS1.BRODCAST up, print messages from the backup copy, and do all 
> kinds of other things to it, with the help of Vinh Vu.

Good gravy, its been ages like you said. Jim Marshall rings a bell for some 
reason. Was he a project manager at Guide? I am at a loss because the name is 
someone that might have been involved in the 3850 MSS. I could be wrong. I 
can’t think of anything TSO related though. The *ONLY* remotely possible was he 
responsible for writing the Program called COPYCAT (Bell Labs?). That program 
saved my ass as one of the first items that I ran into in my new job was the 
people had not allocated enough space for their production CVOL. what a 
lifesaver. We were down for about 1 hour and if I had had to use IEHMOVE it 
would have been all night or more.
> 
> So for me the UADS (and BRODCAST) experience is more recent than the 
> 1970's.  But MAN..!!!  Do I enjoy listening to people who have EXPERIENCE..!  
> Thanks, Ed.  I remember those days too.  Had some real fun, (adventures, and 
> all-night IPL's).

As I have gotten older and the more senior people do not have to come in in the 
middle of the night for just any emergency, The 0300 calls have dropped to 
zero. The 0400 call to take the dog out for walks is a pain but you know bed is 
coming soon.

Ed



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

Converting programs to accommodate 8-character userids and prefixes

[Sam Golob]

Hi Ed,

    Ah, nostalgia!!!

    Funny thing is, UADS was studied in depth by Jim Marshall in the 
early 90's.  And although it's not too wise to use it (via the ACCOUNT 
command) to define working userids in a production system, but on a 
development system the knowledge of SYS1.UADS can come in very handy.  
See Jim's files:  CBT Files 300 and 316.  Very neat stuff.  Jim also got 
me involved in studying SYS1.BRODCAST at that time, and that knowledge 
from him, helped get me started to develop my SYS1.BRODCAST package 
(free version on CBT File 247).  Of course I didn't do it just for fun.  
Our installation was (effectively) a service bureau, in which we had to 
preserve one of our subsidiary data center's BRODCAST messages, and we 
couldn't just wipe BRODCAST with the SYNC command the way IBM 
"requires".  We had to do it intelligently--not just burn down the barn 
and rebuild it, every time it got dirty.  So I wrote programs to back 
SYS1.BRODCAST up, print messages from the backup copy, and do all kinds 
of other things to it, with the help of Vinh Vu.


    So for me the UADS (and BRODCAST) experience is more recent than 
the 1970's.  But MAN..!!!  Do I enjoy listening to people who have 
EXPERIENCE..!  Thanks, Ed.  I remember those days too.  Had some real 
fun, (adventures, and all-night IPL's).


    All the best of everything to all of you...

Sincerely,    Sam

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

Re: Converting programs to accommodate 8-character userids and prefixes

[Edward Gould]

Sam,

Thanks for improving on my entry. To be honest I did this from memory and one 
thing I have learned is that memory doesn’t have a check digit so bytes can be 
lost.

> On Dec 15, 2017, at 12:09 AM, Sam Golob  wrote:
> 
> Hi Folks,
> 
> I'm commenting on Ed Gould's comments.  Thanks Ed.  Much obliged.
> 
> I've used MVT in the old days, but I'm not an expert from then.  A few 
> years ago, I was experimenting with the ACCOUNT command to create new userids 
> in SYS1.UADS (on z/OS), and I noticed that the size of each member was 
> dependent on the BLKSIZE of the SYS1.UADS dataset.  For example, if your 
> SYS1.UADS had a block size of 800, each member could be only one block, and 
> therefore it had to be limited to 10 records.  But when I blocked SYS1.UADS 
> at 8000, each member was 100 records.
I will bow to your entry as it sound right, but I never tried reblocking it as 
we never had the real test time to do so. Although I worked many an odd hour, 
this was not even on my radar. I don’t recall any block size restrictions and 
never dug that deeply into uads except one time and I was trying to figure out 
why an ID that I had created wasn’t working. At that time we actually had fiche 
and IBM did give out the fiche and almost all (all?) of there fiche we had was 
PLS, which wasn’t to difficult to decipher as long as you had the assembly 
output. This was in the early 70’s before we had converted to VS2, after the 
conversion we were extremely busy with all the stand alone dumps that at time 
were 8 foot high (multiple dumps). The IBM PSR had dumps that were 9 feet high 
and multiple piles. We actually had to get a ladder from Building maintenance 
to pile up and take down the dumps, so my excursion into UADS was a light at 
the end of the tunnel.  
> 
> In the old days, it was customary to block SYS1.UADS at 800 bytes.  So 
> those userid members, being only 10 records long, sometimes needed several 
> members to accommodate the information from several accounts, or logon 
> procedures, or passwords, connected with a single userid.  Hence the USERID0, 
> USERID1, USERID2 members, etc.
> 
> In any case, it was quite a restrictive system, and the 7-character 
> limitation has lasted, in TSO, for a very long time.  Until now.
   We weren’t into writing code except for a few places like the TSO pre 
prompt exit (or was it the logon exit?) and we had a started task that was 
written by our resident IBM SE. Occasionally I will find the one listing I had 
that he wrote and it was pretty damn good code. IIRC at that time we had a mvs 
accounting system that was written in COBOL except for SMF exits (command ?? 
accounting). I stayed away from it and it was given to a Jr sysprog to handle. 
He was fair and never got me involved except odd events. The one program was to 
me (at that time) as large COBOL program and the first time I got involved was 
when the program abended with one of the type 4 records that had over 1000 dd’s 
(90 percent of them were local CRT’s) and the programs was never designed to 
handle that many. My conversation to the support people went something like 
this: I have a type 4 SMF record counting 1200 dd statements and the program 
isn’t working. The guy at the other end of the phone sort of gasped and asked  
1200 hundred  REALLY I said yes he said he wasn’t sure that the program 
could handle it and I said no it can’t that is why I am calling. The 
conversation went down hill after that. Looking back at the report programs 
adding a few characters would have been simple and the minor change would be to 
the assembler exits as space was hard to come by in the flower box.
> 
> Now, hundreds of programs have to be updated.  We are working on it.  If 
> any of you has fixed something related to this (or NOT related to this), 
> please send it to me for inclusion on the CBT Tape, in order to benefit 
> everyone else. Thanks much  We appreciate all the help we can get.

Good luck I don’t envy the chore as I am guessing from seeing some of the code 
on the CBTTAPE its not going to be easy.
> 
> One way of getting around it is not to turn on the 8-character id 
> support.  But people in IBM have told me that they want to eventually make 
> 8-character id support the default, so we've got to get there sooner or later.
> 
> All the best of everything to all of you...
> 
> Sincerely,   Sam


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

Re: Converting programs to accommodate 8-character userids and prefixes

[Anne & Lynn Wheeler]

john.archie.mck...@gmail.com (John McKown) writes:
> ​TSO seems to be about as important to IBM as VSPC was.
> https://en.wikipedia.org/wiki/Virtual_Storage_Personal_Computing​

VSPC was to be low-end non-vm370/cms online. They had a performance
"model" which predicted benchmark performance ... and required VM370/CMS
to run equivalent benchmarks taking major part of the VM370/CMS group
resources (and the predicted VSPC performance was always significantly
better then the equivalent VM370/CMS benchmarks). Finally when VSPC was
actually operational, it turns out that VSPC actual performance was much
worse than their model predictions (as well as actual VM370/CMS
performance)

afterwards, Endicott tried to get corporate approval to ship vm370/cms
as part of every machine they made (sort of like LPARS today
implementing a virtual machine subset).  however, this was in the period
after Future System imploding ...  past posts
http://www.garlic.com/~lynn/submain.html#futuresys

and POK was convincing corporate to kill VM370/CMS product and move the
group to POK for MVS/XA or otherwise MVS/XA wouldn't ship on time (some
7-8yrs later). Endicott eventually managed to acquire the VM370/CMS
product mission, but they had to reconstitute a development group from
scratch ... some customer comments about code quality during this period
show up in the vmshare archives (TYMSHARE provided their CMS-based
online computer conferencing free to share starting in August 1976).
http://vm.marist.edu/~vmshare

Later still, endicott was selling so many vm/4300 machines that it got
corporate to declare vm370/cms the corporate strategic online
interactive platform (which really drove POK crazy, small payback for
POK earlier getting vm370/cms product killed) ... even tho they still
couldn't get corporate approval to ship vm370/cms as part of every
machine sold.

large customers were ordering hundreds of vm/4300s at a time for placing
out in departmental areas, sort of precursor to the coming distributed
computing tsunami.

also, vm/4300 clusters were severely threatening high-end POK mainframes
(better price/performance, smaller footprint, less environmentals)
... at one point POK managed to get allocation of critical 4300
manufacturing component cut it half. Before first 4341 shipped, I had
got conned into doing benchmarks on engineering machines for LLNL
(national lab) that was looking at getting 70 4341s for compute farm
... leading edge of the coming cluster supercomputing tsunami (grid
computing which has huge technology overlap with the cloud
megadatacenters, running hundreds of thousand of systems).

Part of the POK plan to kill vm370/cms was to not tell the group about
their move to POK until the very last minute ... to minimize the number
that could escape. However the news leaked early and lots managed to
escape in local Boston/Cambridge area ... many to DEC (there is joke
that head of POK was one of the largest contributors to the DEC VMS
product).  In the wake of the leak, there was witchhunt for the source
... fortuantely for me nobody gave up the source.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Converting programs to accommodate 8-character userids and prefixes

[Jesse 1 Robinson]

Friday history lesson. A shop I used to work at had an (overly) elaborate 
charge back system that required users to logon with an account number 
associated with the task(s) they were performing at the time. So most every 
application programmer had several account numbers in the ACCOUNT tree. Each of 
those took up space in UADS, so it was common for a user to have several UADS 
members userid-0, userid-1, and so one. I never saw anyone exhaust the 
available slots, but as Sam says, increasing UADS blocksize reduced the number 
of members required to hold the same amount of data. BTW that is documented 
somewhere in TFM. All of this goes away with TSOE RACF segments, but only if 
you actually convert. ;-)

.
.
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 Sam Golob
Sent: Thursday, December 14, 2017 10:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Converting programs to accommodate 8-character userids and 
prefixes

Hi Folks,

     I'm commenting on Ed Gould's comments.  Thanks Ed.  Much obliged.

     I've used MVT in the old days, but I'm not an expert from then.  A few 
years ago, I was experimenting with the ACCOUNT command to create new userids 
in SYS1.UADS (on z/OS), and I noticed that the size of each member was 
dependent on the BLKSIZE of the SYS1.UADS dataset.  For example, if your 
SYS1.UADS had a block size of 800, each member could be only one block, and 
therefore it had to be limited to 10 records.  But when I blocked SYS1.UADS at 
8000, each member was 100 records.

     In the old days, it was customary to block SYS1.UADS at 800 bytes. So 
those userid members, being only 10 records long, sometimes needed several 
members to accommodate the information from several accounts, or logon 
procedures, or passwords, connected with a single userid.  Hence the USERID0, 
USERID1, USERID2 members, etc.

     In any case, it was quite a restrictive system, and the 7-character 
limitation has lasted, in TSO, for a very long time.  Until now.

     Now, hundreds of programs have to be updated.  We are working on it.  If 
any of you has fixed something related to this (or NOT related to this), please 
send it to me for inclusion on the CBT Tape, in order to benefit everyone else. 
Thanks much  We appreciate all the help we can get.

     One way of getting around it is not to turn on the 8-character id support. 
 But people in IBM have told me that they want to eventually make 8-character 
id support the default, so we've got to get there sooner or later.

     All the best of everything to all of you...

Sincerely,   Sam


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

Re: Converting programs to accommodate 8-character userids and prefixes

[John McKown]

On Fri, Dec 15, 2017 at 11:20 AM, Ed Jaffe 
wrote:

> On 12/15/2017 7:43 AM, Paul Gilmartin wrote:
>
>> On Fri, 15 Dec 2017 01:09:58 -0500, Sam Golob wrote:
>>
>>>  One way of getting around it is not to turn on the 8-character id
>>> support.  But people in IBM have told me that they want to eventually
>>> make 8-character id support the default, so we've got to get there
>>> sooner or later.
>>>
>>> Underreaching.  8 is the minimum accepted by many organizations.  But
>> many OSes support much longer.  As long as an incompatible change is
>> being made, they should have gone to much longer than 8.  At the very
>> least, the new fields could have been made larger than 8 to accommodate
>> possible future enhancements.
>>
>
> Not underreaching, nor did they make an incompatible change. They made a
> *compatible* one!
>
> MVS added support for 8-character userids back in 1995. It's been
> supported ever since in every subsystem and middleware component (JES,
> CICS, DB2, RACF, etc) with one exception: TSO/E.
>
> Now, 22 years later, TSO/E has finally caught up to the rest of the
> operating system -- and they did it an a way that is extensible to any
> length that can can be expressed in a single byte.


​TSO seems to be about as important to IBM as VSPC was.
https://en.wikipedia.org/wiki/Virtual_Storage_Personal_Computing​



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



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: Converting programs to accommodate 8-character userids and prefixes

[Ed Jaffe]

On 12/15/2017 7:43 AM, Paul Gilmartin wrote:

On Fri, 15 Dec 2017 01:09:58 -0500, Sam Golob wrote:

     One way of getting around it is not to turn on the 8-character id
support.  But people in IBM have told me that they want to eventually
make 8-character id support the default, so we've got to get there
sooner or later.


Underreaching.  8 is the minimum accepted by many organizations.  But
many OSes support much longer.  As long as an incompatible change is
being made, they should have gone to much longer than 8.  At the very
least, the new fields could have been made larger than 8 to accommodate
possible future enhancements.


Not underreaching, nor did they make an incompatible change. They made a 
*compatible* one!


MVS added support for 8-character userids back in 1995. It's been 
supported ever since in every subsystem and middleware component (JES, 
CICS, DB2, RACF, etc) with one exception: TSO/E.


Now, 22 years later, TSO/E has finally caught up to the rest of the 
operating system -- and they did it an a way that is extensible to any 
length that can can be expressed in a single byte.


--
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: Converting programs to accommodate 8-character userids and prefixes

[Paul Gilmartin]

On Fri, 15 Dec 2017 01:09:58 -0500, Sam Golob wrote:
>
>     One way of getting around it is not to turn on the 8-character id
>support.  But people in IBM have told me that they want to eventually
>make 8-character id support the default, so we've got to get there
>sooner or later.
> 
Underreaching.  8 is the minimum accepted by many organizations.  But
many OSes support much longer.  As long as an incompatible change is
being made, they should have gone to much longer than 8.  At the very
least, the new fields could have been made larger than 8 to accommodate
possible future enhancements.

-- gil

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

Converting programs to accommodate 8-character userids and prefixes

[Sam Golob]

Hi Folks,

    I'm commenting on Ed Gould's comments.  Thanks Ed.  Much obliged.

    I've used MVT in the old days, but I'm not an expert from then.  A 
few years ago, I was experimenting with the ACCOUNT command to create 
new userids in SYS1.UADS (on z/OS), and I noticed that the size of each 
member was dependent on the BLKSIZE of the SYS1.UADS dataset.  For 
example, if your SYS1.UADS had a block size of 800, each member could be 
only one block, and therefore it had to be limited to 10 records.  But 
when I blocked SYS1.UADS at 8000, each member was 100 records.


    In the old days, it was customary to block SYS1.UADS at 800 bytes.  
So those userid members, being only 10 records long, sometimes needed 
several members to accommodate the information from several accounts, or 
logon procedures, or passwords, connected with a single userid.  Hence 
the USERID0, USERID1, USERID2 members, etc.


    In any case, it was quite a restrictive system, and the 7-character 
limitation has lasted, in TSO, for a very long time.  Until now.


    Now, hundreds of programs have to be updated.  We are working on 
it.  If any of you has fixed something related to this (or NOT related 
to this), please send it to me for inclusion on the CBT Tape, in order 
to benefit everyone else. Thanks much  We appreciate all the 
help we can get.


    One way of getting around it is not to turn on the 8-character id 
support.  But people in IBM have told me that they want to eventually 
make 8-character id support the default, so we've got to get there 
sooner or later.


    All the best of everything to all of you...

Sincerely,   Sam

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

Re: Converting programs to accommodate 8-character userids and prefixes

[Edward Gould]

> On Dec 14, 2017, at 2:21 PM, Sam Golob  wrote:
> 
>As you probably know by now, z/OS 2.3 has introduced the possibility of 
> having 8-character TSO userids and 8-character TSO prefixes.  These name 
> fields were previously limited to 7 characters, ever since TSO came into 
> existence.  (I think the reason for the limitation was that the SYS1.UADS 
> members, representing the definition of TSO userids before RACF, ACF2, Top 
> Secret etc. had to have a number at the end of them, i.e. IBMUSER0, IBMUSER1, 
> etc.  So the id itself was limited to 7 characters in length.)

Sam,

Almost…..  in the beginning there was sys1.uads 7 character ID . Then if you 
wanted to have a special accounting info etc and there was only so much space 
(IIRC 800 bytes) if you needed multiple accounts and accounting info etc the ID 
was extended until (I think 800 bytes) then in order to allow additional 
accounting info etc another “id” was created so instead of pepper an extension 
(new member) was created called pepper1 and so on and so forth until pepper9 
so, if memory serves me everybody had a pepper0 then depending on accounting 
info etc the next “id” was pepper1 etc etc pepper9.

Its been a while so that first ID ended with hex zero then the second was 1 
(this part here I am iffy on) as we only had 1 or 2 that had the added 
character. I just don’t remember of it was hex 00 then hex 01 or if it was a 
character 1 then 2 etc,,

ED


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

Converting programs to accommodate 8-character userids and prefixes

[Sam Golob]

Hi Folks, (I'm sorry that my previous post was sent incomplete--pressed 
the wrong key)


   As you probably know by now, z/OS 2.3 has introduced the possibility 
of having 8-character TSO userids and 8-character TSO prefixes.  These 
name fields were previously limited to 7 characters, ever since TSO came 
into existence.  (I think the reason for the limitation was that the 
SYS1.UADS members, representing the definition of TSO userids before 
RACF, ACF2, Top Secret etc. had to have a number at the end of them, 
e.g. IBMUSER0, IBMUSER1, etc.  So the id itself was limited to 7 
characters in length.)


   Many programs, especially TSO commands, look to find the TSO userid 
in the PSCBUSER field (7 characters long) of the PSCB control block 
(mapped by macro IKJPSCB).  Also, the TSO prefix for your session is 
usually found in the UPTPREFX field (also 7 characters) of the UPT 
control block (mapped by macro IKJUPT).


   General 8-character userid support, in z/OS 2.3 (and presumably 
above) is turned on or off by a switch.  It was explained to me, that 
the support is quite complicated, so the installation has to be able to 
decide whether to turn it on, or not.  The installation's control is in 
PARMLIB member IKJTSOxx, in the LOGON parameter: LOGON USERIDMAX(8) . 
The place where this switch is located, is +6 bytes off the beginning of 
the TSVT (TSO Vector Table) mapped by macro IKJTSVT.  The setting is 
x'00' for pre z/OS 2.3, x'07' for z/OS 2.3 with support OFF, and x'08' 
for z/OS 2.3 with support ON.


   With the switch on, and if you have defined an 8-character userid, 
then the PSCBUSER field and the UPTPREFX field cannot contain the userid 
or the prefix, since they are only 7 characters long. So there are 2 new 
fields, at 2 new locations in the PSCB and UPT control blocks, 
respectively.  The display below shows where they are.  Also, the length 
fields in the PSCB and UPT are both new, when you have an 8-character 
userid.


   The displays below will show the location and content of all the 
relevant fields.  They were produced by the LPSCB program (parameter U) 
from CBT File 300, and by the ALLIDS program (CBT File 731) both on the 
UPDATES page of www.cbttape.org .


   So without further ado, here are the displays.  You should be able 
to use this information to do almost any conversion that you'll need to 
do.  There's more of course, but this is the basic layout.  If there is 
an 8-character userid defined, then the old fields (PSCBUSER and 
UPTPREFX) will contan the characters '>7BYTES' with a length of 7.   
Thanks for listening.


Output of LPSCB U , TSO command from CBT File 300

This program shows field layouts for PSCB and UPT.

8-CHARACTER USERID SUPPORT IS: ON
6F80 PSCB ADDRESS
    +0  PSCBUSER 6EF7C2E8E3C5E2   >7BYTES
    +7  PSCBUSRL 07
    +8  PSCBGPNM E2E8E2C1D3D3C4C1 SYSALLDA
   +10  PSCBATR1 E100 OPER ACCT JCL CONS
   +12  PSCBATR2 
   +14  PSCBLTIM D395E64338C46389 2017.348  09:57.47.143238
   +1C  PSCBSUBH 00
   +1D  PSCBSUBC 00
   +1E  PSCBSUBM 00
   +1F  PSCBSOUT 00
   +20  PSCBU8L  08
   +21  PSCBDRBA 00
   +24  RESERVED 
   +28  PSCBDEST 
   +30  PSCBRLGB 7EF8
   +34  PSCBUPT  8FC8
   +38  PSCBUPTL 0038
   +3A  PSCBCHAR 00
   +3B  PSCBLINE 00
   +3C  PSCBRSZ  000F4240
   +40  PSCBU    
   +48  PSCBEXWD
   +48  PSCBEXK  
   +4C  PSCBEXL  0004
   +50  PSCBEXD  
   +54  PSCBUID8 C9C2D4E4E2C5D9C3 IBMUSERC
   +5C  RESERVED 
8FC8 UPT FROM PSCB
8FC8 UPT FROM CPPL
    +0  UPTLEN   0038
    +2  UPTUSER  
    +C  UPTSWS   00
    +D  UPTCDEL  00
    +E  UPTLDEL  00
    +F  UPTVERS  01
   +10  UPTPREFX 6EF7C2E8E3C5E2   >7BYTES
   +17  UPTPREFL 07
   +18  UPTPLANG C5D5E4   ENU
   +1B  UPTSLANG C5D5E4   ENU
   +1E  UPTLNGFL 
   +20  UPTSWS2  00
   +21  UPTPREF8 C9C2D4E4E2C5D9C3 IBMUSERC
   +29  UPTPRF8L 08
   +2A  RESERVED 


Output of my ALLIDS TSO command - CBT File 731

ALLIDS - SHOW TSO USERID OCCURRENCES - V1.2
--    --- -- ---   
   old    len   new   len
  field   gth  field  gth

My PSCB Userid is >7BYTES  07 IBMUSERC 08
My UPT  Prefix is >7BYTES  07 IBMUSERC 08
My JCT  Userid is IBMUSERC
My JMR  Userid is IBMUSERC
My TIOT Userid is IBMUSERC
My ASCB Userid is IBMUSERC
My ASXB Userid is IBMUSERC
My ACEE Userid is IBMUSERC 08
My LWA  Userid is  08 IBMUSERC
My TSBX Userid is IBMUSERC
My CSCB Userid is IBMUSERC
My CSCX Userid is IBMUSERC
My OUCB Userid is IBMUSERC
My JSAB Userid is IBMUSERC Jobname IBMUSERC
My CAUB Userid is IBMUSERC
8-CHARACTER USERID SUPPORT IS: ON

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

Converting programs to accommodate 8-character userids and prefixes

[Sam Golob]

Hi Folks,

   As you probably know by now, z/OS 2.3 has introduced the possibility 
of having 8-character TSO userids and 8-character TSO prefixes.  These 
name fields were previously limited to 7 characters, ever since TSO came 
into existence.  (I think the reason for the limitation was that the 
SYS1.UADS members, representing the definition of TSO userids before 
RACF, ACF2, Top Secret etc. had to have a number at the end of them, 
i.e. IBMUSER0, IBMUSER1, etc.  So the id itself was limited to 7 
characters in length.)


   Many programs, especially TSO commands, look to find the TSO userid 
in the PSCBUSER field (7 characters long) of the PSCB control block 
(mapped by macro IKJPSCB).  Also, the TSO prefix for your session is 
usually found in the UPTPREFX field (also 7 characters) of the UPT 
control block (mapped by macro IKJUPT).


   General 8-character userid support, in z/OS 2.3 (and presumably 
above) is turned on or off by a switch.  It was explained to me, that 
the support is quite complicated, so the installation has to be able to 
decide whether to turn it on, or not.  The installation's control is in 
PARMLIB member IKJTSOxx, in the LOGON parameter:


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