*Lennie Dymoke-Bradshaw lenni...@rsmpartners.com <lenni...@rsmpartners.com> via <https://support.google.com/mail/answer/1311182?hl=en> ua.edu <http://ua.edu> * *9:19 AM (2 hours ago)* *to IBM-MAIN* *How did you delete the files if you were not allowed to logon? *Asked..
You were in the LOGON PROCEDURE. It ran a CLIST that listed all your personal dataset allocations. At that point you could delete datasets. So although you were in the TSO environment, you couldn't do much. Somebody actually worked out a way to break the CLIST. I guess it was a WRITE command that received a response. If you typed in &STR( the CLIST would break. Then you could go SPF (before the days of ISPF). I should try it, for posterity, now that you asked. On Thu, Apr 23, 2020 at 9:49 AM Bob Bridges <robhbrid...@gmail.com> wrote: > I think Mr Morris is right. I'm reminded of an update I had to handle > during the '80s. Volvo had bought White Motors, and I went to work for > Volvo-White Truck (now Volvo Truck North America) in 1982. As some of you > know, those tractor rigs cost about as much as a house, and some time in > the '80s the base price of some models (before options) rose above $100 000 > for the first time. That meant an extra byte in a packed-decimal field > that in many programs was part of a larger REPEAT-6 array. > > I worked my way through about 150 programs, finding the ones that had to > be changed, enlarging the field and in many cases moving the entire array > to different places in various records as I found room. I don't remember > how many programs, two or three score at least. At the very end I > encountered a data-input form (this was before on-line data entry) that > involved three 80-byte cards - and every card had every single byte > filled. There was no room on any of the forms for an additional byte. > > The new on-line data-entry system was expected to be ready in about six > months. Do I create a new form for just that? The Marketing manager said > no. So I wrote a DYL-280II program, checked it thrice, and for the next > six months, whenever a change to a base price had to go into production, > Jack walked down to my desk, we put the change in the program, checked it > three times, squinched our eyes tight and pushed the button. Happened four > or five times in that six months, and it scared me every time, but it never > blew up on us. That was before change control, of course; we could never > do that now. > > Anyway, I understand your point, Gil, but in the light of that experience > I have to say that the input form ~is~ storage, in some way - or at least > it isn't merely presentation. > > --- > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > > /* There are only two kinds of people in the end: those who say to God > "Thy will be done", and those to whom God says, in the end, "THY will be > done". -from _The Great Divorce_ by C S Lewis */ > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Wednesday, April 22, 2020 17:12 > > But that concerns presentation, not storage. You could as well store > TOD clock values and let the output formatting routine display > 4, 2, or even single digit years. > > --- On Wed, 22 Apr 2020 17:35:01 -0300, Clark Morris wrote: > >In reviewing this discussion, I suddenly realized that the saving by > >using 2 digit years was not just disk and tape space but also on > >forms, printer lines, punched cards, data entry screens and data entry > >key strokes. I know that in many cases I was scrambling for space on > >print lines. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
