Re: History of Hard-coded Offsets (Was: TSSO problems)
Ted MacNEIL started this latest sub-discussion within this thread with: I was one of the ones, in Canada, complaining about the constant changes in geometry. 3330-3350-3380-3390 (and don't forget 'compatability' mode. Seymour J. Metz responded to Ted: Because you didn't use system services to insulate yourself from changes. Rick Fochtman interjected: Most of those geometry-related System Services didn't exist! Paul Gilmartin then asked Rick: Not even by the advent of the 3390, the last ever conversion? Seymour J. Metz responded to Paul: Not even close. Those services came in decades earlier. Seymour J. Metz then asked Rick: What year are you talking about? To which Rick Fochtman responded: Just about the time the 3390 first hit the street. Don't remember the exact year. And then Mike Schwab interjected: Late 1980s with SMS and the 3380 - 3390 transition. BLKSIZE=0. Seymour J. Metz rebutted with this: Those services were long in the tooth by then. Shmuel is correct (although that is, of course, not unusual). The TRKCALC routine, at least [I do not remember if the TRKCALC _macro_ appeared this early or not] -- or (as we knew it then) the STAR (System Track Algorithm Routine) service -- was first introduced with DF/DS (concurrently with DF/EF) for MVS/SP R1 [what would eventually come to be called MVS/SP V1 R1, or SP1.1] and was available in January 1981, although 3380 ESP sites had all three long before then (but that's another story). It was claimed (but I never bothered to verify) that this routine was actually available pre-MVS/SP1.1, but was not documented; regardless, POK hid it neatly inside of the existing, well-known 3330/3350 RPS sector calculation routine pointed to by the CVT using a non-obvious entry linkage, which survives to this day. There were other, somewhat ad-hoc sector and/or track balance calculations spread all over MVS and JES2 [and I'm sure JES3]. TRKCALC was, no doubt, an attempt to eliminate most of those, so that every component didn't need to RYO. The advent of the cellular DASD devices, which gave SAS so much trouble (as has been mentioned in previous posts in this thread), necessitated significant changes to the sometimes-simplistic (albeit working for 3330 3350 devices) algorithms used in these disparate ad-hoc routines inside of MVS and other IBM products. In fact, many attempted to continue to RYO (i.e., not use TRKCALC) and they got it wrong in some corner cases. I suspect they got their hands slapped. -- WB -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
In 4c584ed4.8030...@ync.net, on 08/03/2010 at 12:16 PM, Rick Fochtman rfocht...@ync.net said: Shmuel Metz (Seymour J.) wrote: In 4c56d535.9020...@ync.net, on 08/02/2010 at 09:24 AM, Rick Fochtman rfocht...@ync.net said: Most of those geometry-related System Services didn't exist! :-) What year are you talking about? Just about the time the 3390 first hit the street. Those services were long in the tooth by then. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
In 4c584e96.3080...@ync.net, on 08/03/2010 at 12:15 PM, Rick Fochtman rfocht...@ync.net said: I can remember that a OS/360 Stage-1 assembly took just over 2 hours on a 256K 360/44 with a DSO and reader present. The 2044 didn't have SS instructions, so you got a performance hit simulating them. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
In 4c5706d7.9050...@ync.net, on 08/02/2010 at 12:56 PM, Rick Fochtman rfocht...@ync.net said: ---snip--- On Mon, 2 Aug 2010 09:24:53 -0500, Rick Fochtman wrote: ---snip-- Because you didn't use system services to insulate yourself from changes. ---unsnip Most of those geometry-related System Services didn't exist! :-) Not even by the advent of the 3390, the last ever conversion? --unsnip--- That's right Not even close. Those services came in decades earlier. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
In 4c56d535.9020...@ync.net, on 08/02/2010 at 09:24 AM, Rick Fochtman rfocht...@ync.net said: Most of those geometry-related System Services didn't exist! :-) What year are you talking about? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
In 4c56c44e.6000...@acm.org, on 08/02/2010 at 08:12 AM, Joel C. Ewing jcew...@acm.org said: I dealt with assemblers on other platforms in those early days and didn't have to deal with Assembler on the S/360 platform until it had over a decade to mature, but my impression from the remarks (and code) of one of my predecessors is that over-liberal usage of Assembler symbols in the early days gave you problems on machines with small physical memory or greatly increased the assembly time. I had acceptable S/360 times in 1966, and on even smaller older systems before then. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
Shmuel Metz (Seymour J.) wrote: In 4c56c44e.6000...@acm.org, on 08/02/2010 at 08:12 AM, Joel C. Ewing jcew...@acm.org said: I dealt with assemblers on other platforms in those early days and didn't have to deal with Assembler on the S/360 platform until it had over a decade to mature, but my impression from the remarks (and code) of one of my predecessors is that over-liberal usage of Assembler symbols in the early days gave you problems on machines with small physical memory or greatly increased the assembly time. I had acceptable S/360 times in 1966, and on even smaller older systems before then. I can remember that a OS/360 Stage-1 assembly took just over 2 hours on a 256K 360/44 with a DSO and reader present. The Assembler had about 200K of storage to work with. 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
Shmuel Metz (Seymour J.) wrote: In 4c56d535.9020...@ync.net, on 08/02/2010 at 09:24 AM, Rick Fochtman rfocht...@ync.net said: Most of those geometry-related System Services didn't exist! :-) What year are you talking about? Just about the time the 3390 first hit the street. Don't remember the exact year. 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
On Tue, Aug 3, 2010 at 12:16 PM, Rick Fochtman rfocht...@ync.net wrote: Shmuel Metz (Seymour J.) wrote: In 4c56d535.9020...@ync.net, on 08/02/2010 at 09:24 AM, Rick Fochtman rfocht...@ync.net said: Most of those geometry-related System Services didn't exist! :-) What year are you talking about? Just about the time the 3390 first hit the street. Don't remember the exact year. Rick Late 1980s with SMS and the 3380 - 3390 transition. BLKSIZE=0. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
This is somewhat off of what you did Rick but it is similar (IMO). We had 4 computers 2 mod 30's that ran DOS and 2 mod 50's that ran MFT (this was in the early 70's).between the 30's we had (one) 2311 for a res pack.In order to do a sysgen on the DOS system I created a macro library from the DOS system and used the MFT assembler to create the stage 2 (long story if you want me to go into it).The sysgen really flew on MFT and the stage 1 was done probably 20 minutes. I took the punched output and read it in on DOS and sit back and let it run. I was working 12 hour shifts at the time and the damn stage 2 was still running when I went home. It continued to run for a total of 36 hours(!). I do not think the 30's ever saw so much cpu activity as they were basically used for printing tapes. Ed --- On Tue, 8/3/10, Rick Fochtman rfocht...@ync.net wrote: ---SNIP--- I can remember that a OS/360 Stage-1 assembly took just over 2 hours on a 256K 360/44 with a DSO and reader present. The Assembler had about 200K of storage to work with. 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 -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
In 232244336-1280529724-cardhu_decombobulator_blackberry.rim.net-1948933...@bda026.bisx.prod.on.blackberry, on 07/30/2010 at 10:42 PM, Ted MacNEIL eamacn...@yahoo.ca said: I think that was a good thing. Of course. I was one of the ones, in Canada, complaining about the constant changes in geometry. 3330-3350-3380-3390 (and don't forget 'compatability' mode. Because you didn't use system services to insulate yourself from changes. They hard-coded because it was there. Yes, cowboy programming. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
In 77142d37c0c3c34da0d7b1da7d7ca343c49...@nwt-s-mbx1.rocketsoftware.com, on 07/20/2010 at 03:31 PM, Bill Fairchild bi...@mainstar.com said: The Assembler I used in 1966 ran in 8K under BPS/360 Ah, so you're one of the few people on this list that actually did use BAL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
In 027f01cb283c$5a3431f0$0e9c95...@net, on 07/20/2010 at 01:49 PM, William H. Blair wmhbl...@comcast.net said: 7. Already long-established, bad Assembler language coding Habits. Assembler F was light years ahead of anything else available at the time. IBMAP. Even HLA doesn't have everything that it had. 9. IBM and IBM contractors had to find huge numbers of programmers for OS/360. Many of them were extremely inexperienced, and they set bad cultural norms that their successors followed. Note 1: I remember POK IBMers showing up at GUIDE and SHARE asking us to look at the source for some element involved in processing the START command. Nobody in POK could determine what, exactly, it did -- but they were afraid to touch it or take it out. IEFZGST1 and IEFZGST2 anyone? They were Allocation rather than STC, but I'll match them against any other horror show that anyone cares to nominate. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
On 08/01/2010 06:50 AM, Shmuel Metz (Seymour J.) wrote: In 027f01cb283c$5a3431f0$0e9c95...@net, on 07/20/2010 at 01:49 PM, William H. Blair wmhbl...@comcast.net said: 7. Already long-established, bad Assembler language coding Habits. Assembler F was light years ahead of anything else available at the time. IBMAP. Even HLA doesn't have everything that it had. 9. IBM and IBM contractors had to find huge numbers of programmers for OS/360. Many of them were extremely inexperienced, and they set bad cultural norms that their successors followed. I dealt with assemblers on other platforms in those early days and didn't have to deal with Assembler on the S/360 platform until it had over a decade to mature, but my impression from the remarks (and code) of one of my predecessors is that over-liberal usage of Assembler symbols in the early days gave you problems on machines with small physical memory or greatly increased the assembly time. Either of these could be a good and just motivation for using coding practices that now seem inappropriate in our unconstrained environments. These may have been lessons learned on even more constrained platforms (like IBM 1401) and carried over to S/360 inappropriately, but I suspect they also applied to the early 360's. Note 1: I remember POK IBMers showing up at GUIDE and SHARE asking us to look at the source for some element involved in processing the START command. Nobody in POK could determine what, exactly, it did -- but they were afraid to touch it or take it out. IEFZGST1 and IEFZGST2 anyone? They were Allocation rather than STC, but I'll match them against any other horror show that anyone cares to nominate. -- Joel C. Ewing, Fort Smith, ARjcew...@acm.org -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
---snip-- Because you didn't use system services to insulate yourself from changes. ---unsnip Most of those geometry-related System Services didn't exist! :-) 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
The BPS supervisor took 2K, which left 6K for the application program. I never ran this way on an 8K model 30, but you were supposedly able to configure a model 30 with only 8K. The one I used had 16K. This left me with a whopping 14K for my application, which Dave Freeman once described to me as oceans of core, so why was I having so much trouble getting all my logic in 14K, he wanted to know. :-) And I used BAL, the Basic Assembler Language, which had many restrictions that the TOS and DOS assemblers did not. E.g., statement labels were limited to 6 characters. In those days I had to pay close attention to instruction lengths (not the same as path lengths). I was so relieved when we upgraded to a 64K machine with DOS/360. Then all I had to care about was instruction timings. Now that was OCEANS of core compared to the 16K machine. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, August 01, 2010 6:52 AM To: IBM-MAIN@bama.ua.edu Subject: Re: History of Hard-coded Offsets (Was: TSSO problems) In 77142d37c0c3c34da0d7b1da7d7ca343c49...@nwt-s-mbx1.rocketsoftware.com, on 07/20/2010 at 03:31 PM, Bill Fairchild bi...@mainstar.com said: The Assembler I used in 1966 ran in 8K under BPS/360 Ah, so you're one of the few people on this list that actually did use BAL. -- 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 -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
On Mon, 2 Aug 2010 09:24:53 -0500, Rick Fochtman wrote: ---snip-- Because you didn't use system services to insulate yourself from changes. ---unsnip Most of those geometry-related System Services didn't exist! :-) Not even by the advent of the 3390, the last ever conversion? -- gil -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
I didn't mean to imply that the self-loader itself was 6K in size. It was only 5 or 6 object deck cards, I think. The supervisor was 6K. First the self-loader read itself in from the card reader after you IPLed from the card reader. Then it read in the supervisor from the SYSRES tape, then it went back to the card reader to read the JCL for the first and only job, which specified executing the assembler program. Then the supervisor forward-spaced the SYSRES tape to where the object modules were for the assembler, read them into the upper 10K of storage, and transferred control to the assembler. Or something like that. It was over 43 years ago, and now I can just barely remember how to spell low core. Bill Fairchild Rocket Software -Original Message- From: Bill Fairchild Sent: Monday, August 02, 2010 9:07 AM To: 'IBM Mainframe Discussion List' Subject: RE: History of Hard-coded Offsets (Was: TSSO problems) ... 10K, which was all that was left after the approximately 6K self-loader loaded in the supervisor from tape and then loaded the assembler from tape. -- 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 -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
I ran TOS/360 assemblies on a S/360 model 30 with 16K of storage, so the whole assembler fit in 16K. In fact, it had to fit in about 10K, which was all that was left after the approximately 6K self-loader loaded in the supervisor from tape and then loaded the assembler from tape. TOS/360 and DOS/360 both made extensive use of transient routines, which was TOS/DOS terminology for overlays. A really scary phenomenon was when the TOS (Tape Operating System) assembler had been assembling for a while and then it encountered a temporary read or write error on one of its temporary work files which, of course, were allocated on tape. The SYSRES tape would rewind to find the $$A transient that processed I/O errors, then the tape would forward space back to where the error block was, retry the I/O a few times, and then resume normal processing after the tape block had finally been read or written without a temporary error. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, August 01, 2010 6:31 AM To: IBM-MAIN@bama.ua.edu Subject: Re: History of Hard-coded Offsets (Was: TSSO problems) In 8924.40203...@web82202.mail.mud.yahoo.com, on 07/20/2010 at 08:08 AM, Lloyd Fuller leful...@sbcglobal.net said: Remember: there used to be several levels of assembler: D, E, and F as well as H. D and E in particular had lots of restrictions on what MACROs and COPYs could do because of lack of memory. I believe D would run in a 64K real machine and E required 96K machine. The DOS/360 and TOS/360 Assembler (D) had a 16 KiB design level and, while it exceeded that, I don't believe that it exceeded it by that much. Similarly, the OS/360 Assembler (E) and (F) had 32KiB and 64KiB design points; again, they didn't exceed those sizes by that much. Perhaps you meant that Assembler (F) required a 96 KiB machine. I believe HLASM is based on the H level assembler with lots of changes. Soem of which had been developed at SLAC. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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 -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
On Mon, 2 Aug 2010 14:27:40 +, Bill Fairchild wrote: The BPS supervisor took 2K, which left 6K for the application program. I never ran this way on an 8K model 30, but you were supposedly able to configure a model 30 with only 8K. The one I used had 16K. This left me with a whopping 14K for my application, which Dave Freeman once described to me as oceans of core, so why was I having so much trouble getting all my logic in 14K, he wanted to know. :-) Gulp. BLKSIZE=??? Or, perhaps, BLKSIZE=?? Or was it all UR? And I used BAL, the Basic Assembler Language, which had many restrictions that the TOS and DOS assemblers did not. E.g., statement labels were limited to 6 characters. If it's enough for FORTRAN it should be enough for you! -- gil -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
TOS/360 came with a macro library that had I/O macros for various kinds of access methods. Obviously, one had to design one's block size with the entire machine's storage capacity in mind. I was probably using 2K or 3K for a block length, which would have allowed me to start reading the next block of data while processing the one just read, and still had 8K or so for my massive application program. I vaguely remember using DOS transient modules that I coded myself just to get around the storage limitations. Dave Freeman, who had managed the development of the DOS/360 supervisor for IBM, told me that its design point was 6K so that there would be 10K for application programs on a 16K machine. TOS/360 also fit in the same design limits. At least the versions that I worked with in the late 1960s were this small. Later versions may have exceeded these limits, but by then I had moved way on up to working with MVT on a truly monstrous system with 256K. Bill Fairchild Rocket Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Monday, August 02, 2010 9:38 AM To: IBM-MAIN@bama.ua.edu Subject: Re: History of Hard-coded Offsets (Was: TSSO problems) On Mon, 2 Aug 2010 14:27:40 +, Bill Fairchild wrote: The BPS supervisor took 2K, which left 6K for the application program. I never ran this way on an 8K model 30, but you were supposedly able to configure a model 30 with only 8K. The one I used had 16K. This left me with a whopping 14K for my application, which Dave Freeman once described to me as oceans of core, so why was I having so much trouble getting all my logic in 14K, he wanted to know. :-) Gulp. BLKSIZE=??? Or, perhaps, BLKSIZE=?? Or was it all UR? And I used BAL, the Basic Assembler Language, which had many restrictions that the TOS and DOS assemblers did not. E.g., statement labels were limited to 6 characters. If it's enough for FORTRAN it should be enough for you! -- gil -- 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 -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
Old Man (like me) Bill Fairchild noted: you were supposedly able to configure a model 30 with only 8K. True, and IBM took a boatload of first-day orders for 8KB 360/30 boxes. Before any of them shipped, it was clear that nothing at all useful could be done with them. I don't know if any machines actually shipped with 8KB, but I do know that by the time I took a look at the green book (the IBM Sales Manual) -- while we were still using a 64KB 360/30 -- it was not possible to order such a core configuration: D [16KB] was the smallest one then available. I have read that expectant 8KB IBM 360/30 customers for the most part did not bat an eye at the requirement to order a bigger box. I can believe that, but what I still don't know is what the sales droids had to do/offer to make that be the case. Regardless, with OS/360 obviously coming in at twice its design point (effectively needing 64KB minimum) the world soon divided itself into small (DOS/360) and large (OS/360) customers -- and boxes. Dave Freeman, who had managed the development of the DOS/360 supervisor for IBM, told me that its design point was 6K so that there would be 10K for application programs on a 16K machine. That 16KB design point got set after it was clear (and precisely because it became clear) that that nothing could effectively get done in any 8KB Model 360/30 that lots of customers had ordered. DOS/360 __HAD__ to run in a 16KB machine, period. That was what was going to save the System/360. If IBM now had to go back to the customers and tell them they needed 32KB machines, the sales droids felt that customers would cancel orders in droves. But things would work out differently than anybody, including those in IBM, expected. The same factors that bloated the supervisors (including DOS/360) also bloated customer applications. Thus, larger core memories became the norm, not the exception. Another consequence of this was that the original manufacturing estimate of the amount of core that needed to be built was now realized to be way low, so IBM had to quickly retool some existing sites and build (two, I believe) new memory plants to be able to have enough for surprising large number of existing expected orders. Finally, another consequence of this was that it focused IBM's attention on the royalties they had to pay for every byte of core memory BUILT to a specific patent holder. This inflamed the effort to find a low-cost memory technology -- other than ferrite cores and the very expensive monolithic memory that IBM already (then) had plans to use. An IBM Fellow told me in 1971 that that patent holder had seen the handwriting on the wall and offered to reduce the royalty. But by then it was too late: it would be clear later that the 370/145 design had been set in stone by then. -- WB -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
Shmuel Metz (Seymour J.) offered: IEFZGST1 and IEFZGST2 anyone? Nah ... both of those at least had comments (line AND block). -- WB -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
---snip--- On Mon, 2 Aug 2010 09:24:53 -0500, Rick Fochtman wrote: ---snip-- Because you didn't use system services to insulate yourself from changes. ---unsnip Most of those geometry-related System Services didn't exist! :-) Not even by the advent of the 3390, the last ever conversion? --unsnip--- That's right 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
On 3/08/2010 00:38 AM, Paul Gilmartin wrote: On Mon, 2 Aug 2010 14:27:40 +, Bill Fairchild wrote: The BPS supervisor took 2K, which left 6K for the application program. I never ran this way on an 8K model 30, but you were supposedly able to configure a model 30 with only 8K. The one I used had 16K. This left me with a whopping 14K for my application, which Dave Freeman once described to me as oceans of core, so why was I having so much trouble getting all my logic in 14K, he wanted to know. :-) Gulp. BLKSIZE=??? Or, perhaps, BLKSIZE=?? Or was it all UR? In the late 60's we were running on a 16KB 360/20 and tried to make the main tape files have as large a blocksize as possible. From memory running BPS this was 4KB. Not infrequently additional function would be added to a program and it would exceed the approximately 15.4 KB memory we had available, Then the blocksize would get reduced and every program using that file would have to be re-assembled. In another response on this Bill Fairchild was talking about using TOS to assemble decks. We used TPS and added an additional phase (load image to all non DOS people) with a name like ZASSEM as the invoking program because all the overlay phases had names beginning Zxxx to the SYSRES tape. Occasionally they needed to reload the invoking program by name picked up from somewhere in memory and this trick saved the tape backspace to the begimning and then subsequent forward space back to the Zxx named phases. Another trick to eliminate SYSRES tape movement was hardcoding the macro expansion to eliminate tape movement to the macro library on the SYSRES tape Ken -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
In of2e79944d.48a16ac6-on85257766.00544229-85257766.0054b...@uscmail.uscourts.gov, on 07/20/2010 at 11:25 AM, John Kelly john_j_ke...@ao.uscourts.gov said: The assemble didn't take labels for lengths and displacement Of course it did, even in DOS/360. going thru fiche, to find displacement and lengths They were available in System Control Blocks and there were optional source tapes for the mapping macros that weren't in MACLIB or AMODGEN. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
In 8924.40203...@web82202.mail.mud.yahoo.com, on 07/20/2010 at 08:08 AM, Lloyd Fuller leful...@sbcglobal.net said: Remember: there used to be several levels of assembler: D, E, and F as well as H. D and E in particular had lots of restrictions on what MACROs and COPYs could do because of lack of memory. I believe D would run in a 64K real machine and E required 96K machine. The DOS/360 and TOS/360 Assembler (D) had a 16 KiB design level and, while it exceeded that, I don't believe that it exceeded it by that much. Similarly, the OS/360 Assembler (E) and (F) had 32KiB and 64KiB design points; again, they didn't exceed those sizes by that much. Perhaps you meant that Assembler (F) required a 96 KiB machine. I believe HLASM is based on the H level assembler with lots of changes. Soem of which had been developed at SLAC. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
Shmuel Metz (Seymour J.) wrote: I believe HLASM is based on the H level assembler with lots of changes. Soem of which had been developed at SLAC. Yep. I was one of the ones that helped develop the business case for them so that John could get the HLASM written after he moved to IBM. We spent lots of time at SHARE and at home documenting which we wanted and why. Lloyd -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lloyd Fuller Sent: Sunday, August 01, 2010 8:36 PM To: IBM-MAIN@bama.ua.edu Subject: Re: History of Hard-coded Offsets (Was: TSSO problems) Shmuel Metz (Seymour J.) wrote: I believe HLASM is based on the H level assembler with lots of changes. Soem of which had been developed at SLAC. Yep. I was one of the ones that helped develop the business case for them so that John could get the HLASM written after he moved to IBM. We spent lots of time at SHARE and at home documenting which we wanted and why. Lloyd SNIP I really wish you all had seen the benefits of the MACRO/conditional assembly diagnostics that the F Assembler had. Regards, Steve Thompson -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
W dniu 2010-07-31 00:30, Paul Gilmartin pisze: On Tue, 20 Jul 2010 08:01:09 -0700, Edward Jaffe wrote: I've seen other old programs with many hard-coded offsets and lengths and always wondered why this was such common practice back then. Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? But this reminds me of the current struggle to extend DASD volume sizes beyond 54GB, largely because IBM apparently at the introduction of the 3390 made a committment to support forever programmers with the unconscionable habit of hard- coding device geometry parameters rather than fetching them dynamically from system services. If no programmers had hard-coded 15 tracks per cylinder, IBM could easily have supported HH values up to 65535. It's all virtual, anyway, nowadays. Agreed. However times are a changing. It's been looong time since integrated drive electronics virtualized cylinders, tracks and heads. It's been looong time since number of bytes on tracks isn't constant. LBA mode of addressing is the only reasonable nowadays, especially when consider SSDs. If we (IBM) decide for some incompatibility then maybe it's better to make bigger step and forget about CKD? IMHO that's better than changing CKD limits. Joel C. Ewing wrote: Figuring out what TRK and CYL allocations would need to be changed, and how, to accomodate a change in device geometry would be a non trivial exercise. IMHO it's quite trivial (but time consuming). However it would be much more trivial to leave the values unchanged! Let the TRK and CYL *values* remain unchanged, let's make their physical definition meaningless. In my JCL job I specify 1000 CYL just to describe amount of space, approx. 850MB. I don't care how many physical tracks or cylinders are taken, not to mention everything is emulated. I need some space on disk, that's all. Wouldn't it be nice, to allocated 1000 CYL dataset on USB stick attached to mainframe? g -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
---snip But this reminds me of the current struggle to extend DASD volume sizes beyond 54GB, largely because IBM apparently at the introduction of the 3390 made a committment to support forever programmers with the unconscionable habit of hard-coding device geometry parameters rather than fetching them dynamically from system services. If no programmers had hard-coded 15 tracks per cylinder, IBM could easily have supported HH values up to 65535. It's all virtual, anyway, nowadays. ---unsnip- One of the biggest problems in upgrading DASD was upgrading millions of lines of JCL to account for altered geometry. Please remember that updating JCL, or dynamic allocation parms, isn't productive in the same way as implementing a new inventory management system, for example. Most management types don't see any value in updating JCL and thus aren't willing to commit manpower resources for this sort of thing. Long ago, before the advent of SMS, IBM made a commitment to not change device geometry after the 3390 was introduced. I, for one, salute IBM for living up to that commitment. 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
On Sat, 2010-07-31 at 10:36 -0500, Rick Fochtman wrote: snip Long ago, before the advent of SMS, IBM made a commitment to not change device geometry after the 3390 was introduced. I, for one, salute IBM for living up to that commitment. Rick In many ways, I agree with that sentiment. However, it does saddle us with obsolete ways of doing things. Reference the entire thread on PDSes and their problems. And DASD allocation. I would prefer if SMS storage pools could act a bit more like a UNIX filesystem - allow a dataset to grow as needed without limit other than the size of the storage pool. No more maximun number of extents per volume and 59 volumes. No more specifying SPACE in JCL at all - make it obsolete and ignore it. Granted the super large DASD volumes of today reduce some of this. That is, for those of you (not us) who can adopt them. We have (own) an old 2105 and won't upgrade (no money, literally). Speaking of which, any jobs in DFW area of TX? -- John McKown Maranatha! -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
In 4c45ba35.8000...@phoenixsoftware.com, on 07/20/2010 at 08:01 AM, Edward Jaffe edja...@phoenixsoftware.com said: I've seen other old programs with many hard-coded offsets and lengths and always wondered why this was such common practice back then. Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? It was a combination of inexperienced programmers, poor training, tunnel vision and a philosophy of Après moi, le déluge. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
Après moi, le déluge.Charles de Gualle was right in a way. On Fri, Jul 30, 2010 at 7:35 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net shmuel%2bibm-m...@patriot.net wrote: In 4c45ba35.8000...@phoenixsoftware.com, on 07/20/2010 at 08:01 AM, Edward Jaffe edja...@phoenixsoftware.com said: I've seen other old programs with many hard-coded offsets and lengths and always wondered why this was such common practice back then. Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? It was a combination of inexperienced programmers, poor training, tunnel vision and a philosophy of Après moi, le déluge. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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 -- Guy Gardoit z/OS Systems Programming -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
On Tue, 20 Jul 2010 08:01:09 -0700, Edward Jaffe wrote: I've seen other old programs with many hard-coded offsets and lengths and always wondered why this was such common practice back then. Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? But this reminds me of the current struggle to extend DASD volume sizes beyond 54GB, largely because IBM apparently at the introduction of the 3390 made a committment to support forever programmers with the unconscionable habit of hard- coding device geometry parameters rather than fetching them dynamically from system services. If no programmers had hard-coded 15 tracks per cylinder, IBM could easily have supported HH values up to 65535. It's all virtual, anyway, nowadays. -- gil -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
But this reminds me of the current struggle to extend DASD volume sizes beyond 54GB, largely because IBM apparently at the introduction of the 3390 made a committment to support forever programmers with the unconscionable habit of hard- coding device geometry parameters rather than fetching them dynamically from system services. I think that was a good thing. I was one of the ones, in Canada, complaining about the constant changes in geometry. 3330-3350-3380-3390 (and don't forget 'compatability' mode. This impacted productivity, migration, space (at a time it mattered), and storage management in general. If no programmers had hard-coded 15 tracks per cylinder, IBM could easily have supported HH values up to 65535. They hard-coded because it was there. It's all virtual, anyway, nowadays. Yes, but it removes one more responsibility from the programmer. SMS was intended to remove space management from them. Since it's virtual, does it matter? - I'm a SuperHero with neither powers, nor motivation! Kimota! -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
On 07/30/2010 05:30 PM, Paul Gilmartin wrote: On Tue, 20 Jul 2010 08:01:09 -0700, Edward Jaffe wrote: I've seen other old programs with many hard-coded offsets and lengths and always wondered why this was such common practice back then. Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? But this reminds me of the current struggle to extend DASD volume sizes beyond 54GB, largely because IBM apparently at the introduction of the 3390 made a committment to support forever programmers with the unconscionable habit of hard- coding device geometry parameters rather than fetching them dynamically from system services. If no programmers had hard-coded 15 tracks per cylinder, IBM could easily have supported HH values up to 65535. It's all virtual, anyway, nowadays. -- gil If we have any code in use on our system with hard coded device geometry values, it is in IBM code or vendor code, not in our tens of thousands of application programs. Now JCL and control cards (mainly IDCAMS), and possibly dynamic file allocations embedded in programs, that's another matter. Figuring out what TRK and CYL allocations would need to be changed, and how, to accomodate a change in device geometry would be a non trivial exercise. Even if you have encouraged use of allocation by records and system-determined blocksize for years, some of the older stuff always persists. And as long as device geometry interacts with VSAM CI size and CA size determination, which in turn subtly interacts with the amount of unused space for a given VSAM FREESPACE value, even allocation by records for VSAM can produce a different effective file capacity if the device geometry changes. And finally, another side effect of any device geometry change that results in different blocksizes or CISIZE may be to require changes in buffer pools and buffer counts in finely-tuned batch jobs or CICS regions. Yes, one can deal with all these issues; but why waste resources doing so if it's not really necessary? Perhaps the answer for those that feel a need for larger cylinders is for IBM to come up with another optional alternative virtual device type on DASD subsystems with a maximized cylinder size, but this would have to also be combined with support for new rules other than using geometry cylinder size for limiting VSAM CA size and provide some alternative for utilities like dfdss and sorts that generate maximum buffers per phsyical write based on cylinder size. Max index CISIZE would limit the maximum DATA CA size that can be supported, but even within that limit larger INDEX CISIZEs required for larger CAs may unacceptably degrade random access performance when multiple levels of INDEX CIs must be read and retained. Another consideration is that too large of a CA would make the delay from moving half the data on a CA-split a much more serious performance issue. -- Joel C. Ewing, Fort Smith, ARjcew...@acm.org -- 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
History of Hard-coded Offsets (Was: TSSO problems)
Scott Rowe wrote: 2) In OSWAITRC (the ESTAE for the OSWAIT TSO command), there is an NI instruction to reset the wait bit in an AOF entry. The offset into the AOF entry is hard-coded and ... I made one enhancement to TSSO years ago and got frustrated with it because there were so many hard-coded offsets and lengths. Every change I made seemed to break something else. I remember thinking, this program needs a major cleanup/restructure to be maintainable! I've seen other old programs with many hard-coded offsets and lengths and always wondered why this was such common practice back then. Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
Remember: there used to be several levels of assembler: D, E, and F as well as H. D and E in particular had lots of restrictions on what MACROs and COPYs could do because of lack of memory. I believe D would run in a 64K real machine and E required 96K machine. And to make matters sweeter you had to compile several operating system things on site in order to install a new release. So even operating system routines had to live with some of the limitations. I believe HLASM is based on the H level assembler with lots of changes. Lloyd - Original Message From: Edward Jaffe edja...@phoenixsoftware.com To: IBM-MAIN@bama.ua.edu Sent: Tue, July 20, 2010 11:01:09 AM Subject: History of Hard-coded Offsets (Was: TSSO problems) Scott Rowe wrote: 2) In OSWAITRC (the ESTAE for the OSWAIT TSO command), there is an NI instruction to reset the wait bit in an AOF entry. The offset into the AOF entry is hard-coded and ... I've seen other old programs with many hard-coded offsets and lengths and always wondered why this was such common practice back then. Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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 -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
I remember learning that method from an assembler programmer I worked with. I can also remember poring over microfiche source code listings to get some of this information so maybe the information was not readily available from IBM in those days. The practice seemed to be fairly common in the early 1970s. That was in the day when systems programmers would hack something together to perform a required task and not worry too much about support as a better idea would always come along. Then suddenly that was all wrong and we had to use the macro definitions for all offsets etc and write structured code. That happened (in my case at least) toward the end of the 1970s and probably coincided with the rise of commercial software development as well as the dreaded standards that were coming in. Probably it was just because things were becoming more organized. David Elliot zSeries Software Support -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Tuesday, July 20, 2010 10:01 AM To: IBM-MAIN@bama.ua.edu Subject: History of Hard-coded Offsets (Was: TSSO problems) Scott Rowe wrote: 2) In OSWAITRC (the ESTAE for the OSWAIT TSO command), there is an NI instruction to reset the wait bit in an AOF entry. The offset into the AOF entry is hard-coded and ... I made one enhancement to TSSO years ago and got frustrated with it because there were so many hard-coded offsets and lengths. Every change I made seemed to break something else. I remember thinking, this program needs a major cleanup/restructure to be maintainable! I've seen other old programs with many hard-coded offsets and lengths and always wondered why this was such common practice back then. Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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 -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Tuesday, July 20, 2010 11:01 AM To: IBM-MAIN@bama.ua.edu Subject: History of Hard-coded Offsets (Was: TSSO problems) Scott Rowe wrote: 2) In OSWAITRC (the ESTAE for the OSWAIT TSO command), there is an NI instruction to reset the wait bit in an AOF entry. The offset into the AOF entry is hard-coded and ... I made one enhancement to TSSO years ago and got frustrated with it because there were so many hard-coded offsets and lengths. Every change I made seemed to break something else. I remember thinking, this program needs a major cleanup/restructure to be maintainable! I've seen other old programs with many hard-coded offsets and lengths and always wondered why this was such common practice back then. Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? I have always suspected some degree of inattention to detail and/or just plain lack of experience on the part of such programmers as the root cause myself. OTOH, programmers who have not had the experience of maintaining O.P.P.'s (Other People's Programs) in, for example, an ISV shop or a large business enterprise may not have had the hard knocks experience of the pain that supporting poorly written code can bring. It's so much easier to change one definition and have the position and length automatically propagated than to have to find all the places where the offset or length is hard-coded, but if you've never had the pain of having to fix such a problem you may not have learned the lesson. Just my USD$0.02. Peter This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
snip Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? /snip Having been 'part of that problem', I believe that the last two statement are correct. The first one is definitely not true because there were some outstanding coder then. The assemble didn't take labels for lengths and displacement and, as mentioned, going thru fiche, to find displacement and lengths made it difficult enough. And 'throw away' could be part of the issue, as I remember out full time job was trying to keep the hardware and software up long enough to do coding. just a thought Jack Kelly 202-502-2390 (Office) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
The Assembler I used in 1966 ran in 8K under BPS/360 on a model 30. It had LOTS of restrictions. I sort of remember that instruction names and storage field names had to be no longer than six characters. And it took two passes through all the cards to complete the assembly process. Bill Fairchild -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lloyd Fuller Sent: Tuesday, July 20, 2010 10:09 AM To: IBM-MAIN@bama.ua.edu Subject: Re: History of Hard-coded Offsets (Was: TSSO problems) Remember: there used to be several levels of assembler: D, E, and F as well as H. D and E in particular had lots of restrictions on what MACROs and COPYs could do because of lack of memory. I believe D would run in a 64K real machine and E required 96K machine. Lloyd - 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 -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
In a message dated 7/20/2010 10:18:06 A.M. Central Daylight Time, elli...@aafes.com writes: That happened (in my case at least) toward the end of the 1970s and probably coincided with the rise of commercial software development as well as the dreaded standards that were coming in. Probably it was just because things were becoming more organized. I don't know if it was 'standard' but many modules used to have patch areas to let us plug in new values or offsets. Not for the feint of heart or uneducated. I did one waiting for 3rd party support and transposed the next to last instruction. Fun and games for about 3 hours. -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
Having been doing this from the mid-60's to today, I would have to say it was all of the above. What I coded in the 60's would get me fired today. It was cutting edge then and trash today. We learned on the job. I went to a big university and then the only computer science course offered was something about programming an ANALOG computer. The assembler of today is something we could only dream about then. I am glad on the one hand that the good old days are in the past, and sad on the other hand because it was a lot more cutting edge. Chris Blaicher Phone: 512-340-6154 Mobile: 512-627-3803 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Kelly Sent: Tuesday, July 20, 2010 10:25 AM To: IBM-MAIN@bama.ua.edu Subject: Re: History of Hard-coded Offsets (Was: TSSO problems) snip Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? /snip Having been 'part of that problem', I believe that the last two statement are correct. The first one is definitely not true because there were some outstanding coder then. The assemble didn't take labels for lengths and displacement and, as mentioned, going thru fiche, to find displacement and lengths made it difficult enough. And 'throw away' could be part of the issue, as I remember out full time job was trying to keep the hardware and software up long enough to do coding. just a thought Jack Kelly 202-502-2390 (Office) -- 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 -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
On Tue, 20 Jul 2010 08:01:09 -0700, Edward Jaffe wrote: I've seen other old programs with many hard-coded offsets and lengths and always wondered why this was such common practice back then. Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? Could some of it have come about by disassembling to reconstruct or reverse engineer unavailable source code? -- gil -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
On 7/20/2010 11:01 AM, Edward Jaffe wrote: I've seen other old programs with many hard-coded offsets and lengths and always wondered why this was such common practice back then. Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? In addition to all the other reasons, I'd suggest two more. One was the belief that IBM wouldn't change the offsets, the other that in the days of mountable DASD, SYS1.(A)MODGEN just wasn't accessible most of the time. We also ordered IBM optional source, and extracted the macros (SYS1.PVTMACS), and those also wasn't resident until the seventies. Gerhard Postpischil Bradford, VT -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
Gerhard Postpischil wrote: On 7/20/2010 11:01 AM, Edward Jaffe wrote: I've seen other old programs with many hard-coded offsets and lengths and always wondered why this was such common practice back then. Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? In addition to all the other reasons, I'd suggest two more. One was the belief that IBM wouldn't change the offsets, the other that in the days of mountable DASD, SYS1.(A)MODGEN just wasn't accessible most of the time. We also ordered IBM optional source, and extracted the macros (SYS1.PVTMACS), and those also wasn't resident until the seventies. A lot of these programs (e.g., TSSO) have hard-coded offsets and lengths to their own data areas -- not just IBM's. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
snip Could some of it have come about by disassembling to reconstruct or reverse engineer unavailable source code? /snip NO 202-502-2390 (Office) -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
Edward E Jaffe wonders: ... old programs with many hard-coded offsets and lengths ... why [was this] such common practice back then[?] Younger and newer programmers followed the habits of those who came before them. Many of those who first ventured into OS extensions and neat, useful programs did so on what today would be considered unusably slow computers (mostly due to I/O). In addition, output was to a line printer, and hundred-page Assembler program listings were to be avoided. Today we save such things in various places on disk drives, and only rarely actually kill trees. In the very early days OS macros were not easily or directly available, and most folks didn't bother to create their own versions of DSECTs for things that you could not get out of IBM in the first place. Fewer pages and fewer expanded -- not to mention, printed -- DSECT macros were virtues. All knew where the CVT pointer was; nobody bothered with the CVT DSECT macro, much less the PSA DSECT -- which did not then even exist. It was just a habit, really. Stuff that got done for some sort of external distribution (SHARE Program Library, and the like) was, on the whole, constructed better in this regard, but some of the most famous and widespread mods were as haphazardly coded as private, in-house RYO stuff. All of these are just excuses, however. Everyone except the idiots knew better, even then. But all of those bad habits were simply too readily adopted as purportedly valid excuses for sloppy work. Few had the time to tilt at windmills or hit the mattresses to bring light and order into that world. So we're still fixing the mistakes of the past today, albeit motivated to do so by considerations that would have been considered valid even back then when this type of sloppy programming was originally being done. But, aside from excuses, the original reasons were: 1. Slow machines (for the most part, 360/65 and below) - with slow memories (but that was to be expected) 2. Slow software: Assembler (F) [I/O limited] 3. Slow DASD I/O: 2311 and 2314 4. Slow printers: 1403-N1 5. Small memories: Assembler F had to execute in small partitions [but it did not benefit from large ones] 6. Non-existent/unavailable control block DSECT macros The above reasons meant there was a purported advantage to write that type of code. But they were reinforced by these reasons: 7. Already long-established, bad Assembler language coding Habits. Assembler F was light years ahead of anything else available at the time. New programming habits and good conventions had yet to be established, recognized and promulgated to the community. Many good programmers were actually put off by code that used DSECTs USINGs (it was not mainstream). 8. The community was smaller; the potential confusion due to such poor practice was unrecognized unappreciated because we were used to reading and using such code -- even (or especially) code in IBM software (see Note 1) -- and had no trouble deciphering what it was doing to what (or so we deluded ourselves). So, all was well, even if we were able to recognize slick, tight, beautiful code when we saw it (if we did not write it ourselves). Years later, other considerations (such as maintainability) started to become much more important. -- WB Note 1: I remember POK IBMers showing up at GUIDE and SHARE asking us to look at the source for some element involved in processing the START command. Nobody in POK could determine what, exactly, it did -- but they were afraid to touch it or take it out. The original coder had included not the first comment anywhere of any substance, didn't use macros, and if I remember correctly used only a few DSECTs (this was a 10- or 15-page Assembly listing). What was left of one of the original OS/360 elements after it was denuded for OS/VS2 was just an obscure golden oldie. In fact, if you look at OS/360 source code today you can easily see that most of it was what we'd describe as junky code, devoid of useful comments or any documentation. This element happened to be one that lived on, somewhat touched but still working, well into MVS/XA and ESA days. -- 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
--snip Was it because there were a lot of inexperienced assembler programmers writing code? Was it because people thought the platform would not last and treated every program as a throw away? Was it due to limitations in the assembler itself? ---unsnip-- In my experience/observation, most programmers THOUGHT that the offsets and lengths would never change because they never had changed. I'm guilty of the same practice myself, but when things started to change, I quickly broke the habit and started using the mapping macros provided, with all the information they provided. 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
Re: History of Hard-coded Offsets (Was: TSSO problems)
-snip- Could some of it have come about by disassembling to reconstruct or reverse engineer unavailable source code? --unsnip-- Guilty as charged. I'm sure that was a contributing factor. 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
