Presumably he used his trusty 129 terminal. Did you say 024? La, la, la, I can't hear you!
If you know what it is, that's one thing, but if you've used one, ... -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Lennie Dymoke-Bradshaw [[email protected]] Sent: Wednesday, April 22, 2020 7:19 PM To: [email protected] Subject: Re: Here we go again; How did you delete the files if you were not allowed to logon? Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: http://secure-web.cisco.com/18tBviL-OkjzraA7hV3_wo0zZVW2NN_DCxRJZEtFgxL_wHj4X641s0XEXyvzSNP4a03x19UZYR6_Jx7nhDHamIxu7XMQbXvlSC3Vh8f-3S5r5Kw9FtN9APVWYjlWztchLnQk0Y6_942Pkjo28WNhQIfhRnqZ3zPF4acEIP1C78m5QsdYdoeL4dI4Di7daFI59CI8pXwdr9c25KiotDloJya1ybyCH537Z1aHvBg0YPOH6lqrQ4TVV0gvcJyQogJ4f661KUlMOgdVJg2h-9e0G7RN5pEMjcf9WNiBUmxYxHs5_zPSRtyBtXT0g3w3hynTkytpziiHr6sSYVu7pQu8Y4bvGnWsV8ghlds1uwb0DDXz-xHka3OPvRNKBrkNlpSC3oUM3_peFXjq395FpSUn1gaF9n8PECvw6HYL_RGqdCNrn9twFLL1jHW1AGbx7reCR/http%3A%2F%2Fwww.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Wayne Bickerdike Sent: 22 April 2020 21:18 To: [email protected] Subject: Re: [IBM-MAIN] Here we go again; We had constraints at IBM when I worked there in 1978. The TSO logon procedure checked your personal space allocation. If you had more then 150 tracks allocated you had to delete some files to log on. At the time we were limited to 30 minutes a session to allow other programmers to get some "time sharing". Space saving isn't wasted effort. I had to fit applications on Z80 kit onto 2 110k floppy disks. As a kid, we sliced up a MARS bar. On Thu, Apr 23, 2020, 06:00 scott Ford <[email protected]> wrote: > David, > > I laugh at these comments/observations. Early days 70-80s System > Programmers like myself helped programmers determine blocksize and > dataset location, etc. and then DBAs were born or made and then the > system optimized. > > Evolution > > Scott > > On Wed, Apr 22, 2020 at 3:44 PM Seymour J Metz <[email protected]> wrote: > > > My first computer had a 2,000 word drum, a 60 word core memory, a > > 600,000 word disk drive and two tape drives. I may have been a tad > > more > constrained > > than you were when you started. I agree with Mr. Adam; people would > > have saved far more DASD space with intelligent choice of block size > > than the miniscule amount they saved by truncating the year. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > ________________________________________ > > From: IBM Mainframe Discussion List [[email protected]] on > > behalf of Joel C. Ewing [[email protected]] > > Sent: Wednesday, April 22, 2020 3:12 PM > > To: [email protected] > > Subject: Re: Here we go again; > > > > Should we presume you didn't work on mainframes prior to the advent > > of cheap memory and cheap RAID DASD in TB chunks? > > > > Even after advent of 3380, 3390, and even native 3390-3, drives our > > company didn't lease DASD drives without doing cost analysis. In > > late 1970's and early 1980's we were on 3330's and later 3350's, > > where physical constraints were also an issue -- when I started as > > SysProg in 1978, the computer room was maxed out space-wise at 29 > > 3330 drives, or only 2.9GB total DASD space. We didn't have DASD > > sitting around that wasn't 95% or more utilized. Batch jobs > > typically got one dedicated > > 3330 DASD work volume that they could allocate only for the duration > > of the job stream, staging data from/to tape as necessary to fit and > > to preserve for next job-stream run. It wasn't until 1995 and > > beyond, that it finally made economic sense for us to acquire DASD > > capacity a year or two before we might actually be able to justify a need. > > > > Our company believed in investing more money in people to retain > > good IT personnel rather than throwing money at hardware. That > > mind-set was one of the reasons why of the 50 some-odd companies in > > that line of business in 1950, of the 3 still in business in 2000, one was > > ours. > > > > Saving one or two bytes per date field in that kind of environment > > was not "marketing nonsense". By performance tuning and efficient > > application design we consistently delayed the need for a DASD or > > processor upgrades, resulting in *considerable* monetary savings > > over decades. You don't "waste" DASD or memory space just because > > it's available at the time without first considering the long-term > > impact on future upgrades. A "good" programmer/analyst was trained > > to err on the side of conserving resources. > > > > You can't judge decisions of the past without first understanding > > the cost, physical space, memory, and I/O configuration constraints > > under which those decisions were made. Unlike now where where easy > > incremental upgrades are possible, back then every upgrade, assuming > > one was possible, involved a substantial cost increase. > > JC Ewing > > > > On 4/22/20 12:05 PM, Gerhard adam wrote: > > > > > > > > > > > > > > > The notion of “savings” was marketing nonsense. The DASD > > > was > paid > > for regardless of whether it held a production database or someone’s > > golf handicap. > > > It cost the same whether it was empty or full. The notion of “saving” > > was nonsense and even under the best of circumstances could only be > > deferred expenses > > > > > > > > > > > > Get Outlook for iOS > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" < > > [email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It was also the physical size of the dataset. > > > > > > On 2020-04-22 12:55, Gibney, Dave wrote: > > >> In the 80's a byte of DASD savings could be thousands of dollars. > > >> > > >>> -----Original Message----- > > >>> From: IBM Mainframe Discussion List On Behalf Of Phil Smith III > > >>> Sent: Wednesday, April 22, 2020 9:12 AM > > >>> To: [email protected] > > >>> Subject: Re: Here we go again; > > >>> > > >>> As others have suggested, many companies do still have SSNs > > >>> stored as packed decimal. So sure, a namespace expansion is > > >>> possible, but it's > a > > bigger > > >>> change than one might think, however it's done. I've even seen > > >>> at > > least one > > >>> company who stored them as binary! I sure hope someone got a big > bonus > > >>> for saving that byte... > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> Peter Farley wrote: > > >>> > > >>>> There are also many non-human entities like corporations that > > >>>> use > the > > >>> same SSN value space. > > >>> > > >>> > > >>> > > >>>> There are a LOT of those . . . and they spring up and fade away > > >>>> at a > > rate far > > >>> higher than human births and deaths. > > >>> > > >>> > > >>> > > >>> They use the same namespace--that is, if your SSN is > > >>> 123-45-6789, an > > estate > > >>> or business could also have that number. Since they're uses for > > different > > >>> things, it's more that they happened (!) to choose the same > > >>> format > > than that > > >>> they're "the same". (And actually they're theoretically > > >>> formatted > > differently: > > >>> an EIN is xx-xxxxxxx vs. the SSN xxx-xx-xxxx, not that most > > >>> folks > > store them > > >>> with the hyphens.) > > >>> > > >>> > > >>> > > >>> ...phsiii > > >>> > > >>> > > >>> ... > > > > > > -- > > Joel C. Ewing > > > > -------------------------------------------------------------------- > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO > > IBM-MAIN > > > > -------------------------------------------------------------------- > > -- For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to [email protected] with the message: INFO > > IBM-MAIN > > > -- > Scott Ford > IDMWORKS > z/OS Development > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
