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 <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN
