Re: [OT ] Mainframe memories
In m3ha77p31u@garlic.com, on 03/09/2014 at 03:47 PM, Anne Lynn Wheeler l...@garlic.com said: ... the executable image on disk could be directly mapped to any address in memory w/o any further alterations or changes. You don't consider a PSECT to be part of the image? -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
On 10 March 2014 10:57, Anne Lynn Wheeler l...@garlic.com wrote: I would tend to use the distinction that for the psect, a private copy was loaded and adjusted for the specific virtual address space location ... separately from (r/o) memory mapping the executable image with no requirement for pre-loading and/or changing ... allowing the same exact (r/o) executable image to concurrently occur simultaneously in different virtual address spaces at different virtual addresses (with just a per virtual address space private copy of the psect having been preloaded and swizzled). The overlay scheme used in HASP II had fixed-sized modules that were read into an available area without relocation. If the space was needed, when the first module got control again it could be loaded at a different address. But the trick was that these tasks were never preempted, so it was permissible to have a register containing an address within the module, as long as it was made relative before (loosely) calling the dispatcher, which might result in relocation. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
t...@harminc.net (Tony Harminc) writes: The overlay scheme used in HASP II had fixed-sized modules that were read into an available area without relocation. If the space was needed, when the first module got control again it could be loaded at a different address. But the trick was that these tasks were never preempted, so it was permissible to have a register containing an address within the module, as long as it was made relative before (loosely) calling the dispatcher, which might result in relocation. re: http://www.garlic.com/~lynn/2014d.html#25 [OT ] Mainframe memories http://www.garlic.com/~lynn/2014d.html#27 [OT ] Mainframe memories http://www.garlic.com/~lynn/2014d.html#30 [OT ] Mainframe memories for other topic drift ... I first modified HASP for release 15/16 to add 2714 tty terminal support for online conversational editor ... implementing CMS editor syntax (had to be redone from scratch since cms execution/programming environment was completely different than hasp). of course I thought it was much better than what they came out with for TSO. past posts mentioning HASP, HASP networking, JES2, and/or NJE http://www.garlic.com/~lynn/submain.html#hasp that summer, I was sucked into going to Boeing (still an undergraduate) to help setup Boeing Computer Services (consolidate dataprocessing in independent business unit to better monitize the investment). 747#3 was flying the skies of seattle for FAA certification. I thought that the renton datacenter was possibly the largest in the world (several hundred million in 360s), that summer there was flow of 360/65s constantly coming in, faster than could be installed ... there were alwyas pieces of 360/65s being staged in the hallways around the machine roomr. There was a disaster scenario where Mt. Rainer heats up causing a mudslide that takes out the renton datacenter. The estimate was the loss of the renton datacenter for a week would cost the company more than the cost of the renton datacenter ... so they were in the process of replicating it at the new 747 plant up in everett. they also got a 360/67 in corporate datacenter (across from boeing field) previously only had a single 360/30 for running company payroll. that summer I modified cp67 to support pageable kernel. The standard cp67 kernel was fix-loaded at boot time. I modified low-useage pieces of the kernel into fixed sized 4kbyte page sizes ... which could use the standard paging i/o system for bringing in and removing. However, the cp67 kernel ran non-translate mode ... so the changes were somewhat analogous to what you describe for HASP II. While a lot of my code from undergraduate days were picked up and shipped in CP67 ... the pageable kernel change didn't showup in the product until vm370. posts mentioning dynamic adaptive resource management http://www.garlic.com/~lynn/subtopic.html#fairshare posts mentioning kernel paging algorithm rewrites http://www.garlic.com/~lynn/subtopic.html#wsclock that summer they also brought the duplex (multiprocessor) 360/67 up to seattle from boeing hunstville. it had been originally ordered for tss/360 ... but never got to point of production use. As a result Huntsville, starting out running the duplex as two 360/65 with os/360. The primary application was numerous 2250 graphic devices used for physical design. The problem was that OS/360 had fragmentation with storage allocation that significantly worsened for long running applications. Boeing Hunstville had modified OS/360 MVT release 13 ... to run in virtual memory mode on the 360/67 ... it didn't actually use virtual memory for paging operations ... it just just the virtual memory hardware to address the OS/360 storage fragmentation problem (exasperated by long running applications). I've mentioned before that there were a number os/360 subsystems done during that period ... as work around to significant os/360 problems ... including CICS ... both the enormous pathlength overhead of many os/360 services ... but also things like storage fragmentation. Other trivia drift ... Univ. library had gotten ONR grant to do an online catalog ... some of the money was used to get a 2321 datacell. The effort was also tagged to be one of the original CICS product betatest sites ... and I was tasked to support/debug CICS for the project. misc. past posts mentioning CICS (/or BDAM) http://www.garlic.com/~lynn/submain.html#cics For other drift ... later I got to know John Boyd and sponsored his briefings at IBM. His biographies mention that Boyd did a stint in command of spook base (about the time I was at Boeing) including a comment that it was a $2.5B windfall for IBM (over $17B in today's dollars) nearly order of magnitude more than renton datacenter. old description of spook base, gone 404 ... but lives on at wayback machine http://web.archive.org/web/20030212092342/http://home.att.net/~c.jeppeson/igloo_white.html/a past Boyd posts URL references from around the web http
Re: [OT ] Mainframe memories
Guess the naming gnomes were trying to subliminally suggest it had no SS instructions. In a message dated 3/10/2014 1:56:17 P.M. Central Daylight Time, et...@tulsagrammer.com writes: IBM System/360 Model 44, optimized for scientific work -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
On 3/8/14, 6:49 PM, Shmuel Metz , Seymour J. wrote: In b6c1eb4364c30e47950e0f68ef65f46708f24...@proditmailbox1.us.syncsort.com, on 03/07/2014 at 08:50 PM, Blaicher, Christopher Y. cblaic...@syncsort.com said: When working for a third party disk vendor I was in a computer room and there was an IBM CE working on a 360/45. No such animal; I might believe 360/40 or 370/145. But there WAS an IBM System/360 Model 44, optimized for scientific work: http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2044.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
In 1966 we got 360/44 Serial 2 at the Purdue University's Laboratory for Agricultural Remote Sensing, which was the proving ground of K.S. Fu's work used subsequently in all of the earth satellite pattern recognition algorithms. I did my Master's evaluating the Karhunen-Loeve theorem in FORTRAN on it, and twice I set a pair of transistors in the floating point divide unit on fire; a new heat shield had to be added to that circuit board. I also used a transistor radio by the console to listen to the 360/44 and it was very easy to hear all of the program transisions and I could tell in which loop I was running after a little while, and especially when I had gone into a never-ending loop as well! Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer MXG Software Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229 ba...@mxg.com http://www.mxg.com - FAQ has Most Answers ad...@mxg.com - invoices/PO/Payment supp...@mxg.com- technical tel: 214 351 1966 - expect slow reply, use email fax: 214 350 3694 - prefer email, still works -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Eric Chevalier Sent: Monday, March 10, 2014 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [OT ] Mainframe memories On 3/8/14, 6:49 PM, Shmuel Metz , Seymour J. wrote: In b6c1eb4364c30e47950e0f68ef65f46708f24...@proditmailbox1.us.syncsort.c om, on 03/07/2014 at 08:50 PM, Blaicher, Christopher Y. cblaic...@syncsort.com said: When working for a third party disk vendor I was in a computer room and there was an IBM CE working on a 360/45. No such animal; I might believe 360/40 or 370/145. But there WAS an IBM System/360 Model 44, optimized for scientific work: http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2044.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
Now that's something to be proud of, and funny too! Richard and Vickie Pinion --- ba...@mxg.com wrote: From: Barry Merrill ba...@mxg.com To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [OT ] Mainframe memories Date: Mon, 10 Mar 2014 14:09:58 -0500 In 1966 we got 360/44 Serial 2 at the Purdue University's Laboratory for Agricultural Remote Sensing, which was the proving ground of K.S. Fu's work used subsequently in all of the earth satellite pattern recognition algorithms. I did my Master's evaluating the Karhunen-Loeve theorem in FORTRAN on it, and twice I set a pair of transistors in the floating point divide unit on fire; a new heat shield had to be added to that circuit board. I also used a transistor radio by the console to listen to the 360/44 and it was very easy to hear all of the program transisions and I could tell in which loop I was running after a little while, and especially when I had gone into a never-ending loop as well! Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer MXG Software Merrill Consultants 10717 Cromwell Drive Dallas, TX 75229 ba...@mxg.com http://www.mxg.com - FAQ has Most Answers ad...@mxg.com - invoices/PO/Payment supp...@mxg.com- technical tel: 214 351 1966 - expect slow reply, use email fax: 214 350 3694 - prefer email, still works -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Eric Chevalier Sent: Monday, March 10, 2014 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [OT ] Mainframe memories On 3/8/14, 6:49 PM, Shmuel Metz , Seymour J. wrote: In b6c1eb4364c30e47950e0f68ef65f46708f24...@proditmailbox1.us.syncsort.c om, on 03/07/2014 at 08:50 PM, Blaicher, Christopher Y. cblaic...@syncsort.com said: When working for a third party disk vendor I was in a computer room and there was an IBM CE working on a 360/45. No such animal; I might believe 360/40 or 370/145. But there WAS an IBM System/360 Model 44, optimized for scientific work: http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2044.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
In m38usiot5y@garlic.com, on 03/10/2014 at 01:33 PM, Anne Lynn Wheeler l...@garlic.com said: 2714 2741? -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
Maybe IBM elected a new chairman that evening? Chris hoelscher Technology Architect | Database Infrastructure Services Technology Solution Services 123 East Main Street |Louisville, KY 40202 choelsc...@humana.com Humana.com (502) 476-2538 - office (502) 714-8615 - blackberry Keeping CAS and Metavance safe for all HUMANAty -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Blaicher, Christopher Y. Sent: Saturday, March 08, 2014 10:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] [OT ] Mainframe memories Right you are, but it was a long time ago. It was a 360, I know. It could have been a 40 or 50. I just remember the column of smoke and how fast the CE moved. It must have been drawn by a fan as it was a column about 3 or 4 inches in in diameter just going straight up. If I remember correctly, it turned out to be a big resistor. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Saturday, March 08, 2014 7:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [OT ] Mainframe memories In b6c1eb4364c30e47950e0f68ef65f46708f24...@proditmailbox1.us.syncsort.com, on 03/07/2014 at 08:50 PM, Blaicher, Christopher Y. cblaic...@syncsort.com said: When working for a third party disk vendor I was in a computer room and there was an IBM CE working on a 360/45. No such animal; I might believe 360/40 or 370/145. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
jcew...@acm.org (Joel C. Ewing) writes: And the IBM 4341 supported System/370 architecture, so VM/370 was indeed supported on the 4341 and was probably what the author intended. I believe the CP-40 and CP-67 precursors of VM/370 required more than just S/360 architecture; namely, a S/360 model that was hardware-enhanced to include a form of hardware virtual memory support, which subsequently evolved to become part of S/370 architecture. So not only is Seymour correct that VM/360 did not exist, but it would also be inappropriate to retroactively think of CP-40 or CP-67 as equivalent to a VM/360, since both required more than basic S/360 architecture. re: http://www.garlic.com/~lynn/2014d.html#16 [OT ] Mainframe memories http://www.garlic.com/~lynn/2014d.html#22 [OT ] Mainframe memories Bob Creasy (manager of cp40 effort) sent me copy of his cp40 speech he gave on seas (european share) 1982 ... I ocr'ed it and put it up http://www.garlic.com/~lynn/cp40seas1982.txt basically the science center had done the hardware modifications to add virtual memory support to 360/40 ... pending the availability of the standard ibm product with virtual memory ... 360/67. When they were able to get standard 360/67 virtual memory machine, cp40 morphs into cp67. posts mentioning science center http://www.garlic.com/~lynn/subtopic.html#545tech 50th anniv of science center just passed a month ago ... mentioned in previous post in this thread. Melinda Varian did detailed history that was available at share and also early versions were posted on vmshare ... tymshare had made its cms-based online computer conferencing available to share for free starting in AUG1976 ... archives available here http://vm.marist.edu/~vmshare melinda's current home page ... scroll done for the detailed history http://www.leeandmelindavarian.com/Melinda/ lots of customers had been convinced to order 360/67 to run the official ibm virtual memory operating system, tss/360 ... however tss/360 had difficulty making it to production level ... so many locations just ran the machine as 360/65 with os/360. http://en.wikipedia.org/wiki/TSS/360 However a couple locations wrote their own virtual memory operating systems for 360/67. Univ. of Michigan wrote MTS (michigan terminal system) http://en.wikipedia.org/wiki/Michigan_Terminal_System MTS was ported to 370 and was in use at numerous locations ... MTS customers also were the early adopters of clone processors. A large east coast financial datacenter was planning on being the first commercial big blue customer to install a clone processor (would be a red box in a datacenter with enormous sea of blue boxes) because the local branch office had done something that had made them extremely angry. I was asked to spend six months at the customer basically obfuscating why the customer was installing the box. I was use to periodically visiting the customer and knew the people well and also knew that my being onsite would have no effect on their decision ... so I refused (I had been told that the CEO would be grateful if I made it look like it was my failure that the customer installed clone processor ... so the refusal wasn't exactly career enhancing decision ... along with periodically ridiculing the FS effort). Stanford wrote Orvyl (Wylburwas original implemented on Orvyl before porting to MVS). http://en.wikipedia.org/wiki/ORVYL_and_WYLBUR -- 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: [OT ] Mainframe memories
l...@garlic.com (Anne Lynn Wheeler) writes: lots of customers had been convinced to order 360/67 to run the official ibm virtual memory operating system, tss/360 ... however tss/360 had difficulty making it to production level ... so many locations just ran the machine as 360/65 with os/360. http://en.wikipedia.org/wiki/TSS/360 re: http://www.garlic.com/~lynn/2014d.html#16 [OT ] Mainframe memories http://www.garlic.com/~lynn/2014d.html#22 [OT ] Mainframe memories http://www.garlic.com/~lynn/2014d.html#23 [OT ] Mainframe memories as undergraduate in the 60s, I got to rewrite a lot of cp67 (after it being installed in at the univ in jan1968). I had to compete with the IBM SE working on tss/360 for weekend dedicated stand-alone time (the rest of the time, the machine ran os/360). one of the things I did was dynamic adaptive resource manager ... periodically called fair share scheduler because a default resource management policy was fair share ... some past posts http://www.garlic.com/~lynn/subtopic.html#fairshare ... and would ridicule the table driven scheduler in tss/360. the IBM SE and I did a synthetic workload benchmark ... simulating user think time doing fortran program edit, compile and execute ... he ran it on tss/360 with four simulated users ... I ran it on cp67/cms (on identical hardware) with 35 simulated users ... getting better response and throughput (than he did with four simulated users). one of tss/360 features was single level store ... basically filesystem was treated as extension of memory access ... which had very poor throughput. For whatever reason, the tss/360 single level store design was carried over into the future system effort http://www.garlic.com/~lynn/submain.html#futuresys after joining the science center, I did a form of single level store for CMS as paged-mapped filesystem ... but fixing most of the throughput problems I had observed in tss/360 ... and was part of the reason that I would periodic ridicule what they were doing in FS (considering both my resource management and my paged mapped filesystem significantly better than what they were doing). this was included in stuff that I later migrated from cp67 to vm370 ... but the page mapped filesystem was not one of the things included for release to customers possibly because of the bad rep that single level store got in both tss/360 and future system. misc. past posts http://www.garlic.com/~lynn/submain.html#mmap one of the things that I did have lots of problems with was supporting position independent code (mentioned in the tss/360 wiki article) ... constantly having to hack code to make in position independent http://www.garlic.com/~lynn/submain.html#adcon -- 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: [OT ] Mainframe memories
l...@garlic.com (Anne Lynn Wheeler) wrote: begin extract one of the things that I did have lots of problems with was supporting position independent code (mentioned in the tss/360 wiki article) ...constantly having to hack code to make in position independent /end extract Is 'position independent' code the same as location-independent code? Presumably not, since location-dependent code, which gives trouble when modifications are made elsewhere in its containing routine, is something that I have tried to avoid for a good many years now. (I recall with no fondness a 60-year-old pseudo-random number generator that was location-dependent.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
re: http://www.garlic.com/~lynn/2014d.html#16 [OT ] Mainframe memories http://www.garlic.com/~lynn/2014d.html#22 [OT ] Mainframe memories http://www.garlic.com/~lynn/2014d.html#23 [OT ] Mainframe memorie http://www.garlic.com/~lynn/2014d.html#25 [OT ] Mainframe memorie univ ran fortran student jobs on 709 ibsys tape-to-tape in around second per job ... tapes were moved between 709 drive and 1401 drive where the 1401 handled input/output unit record. in transition from 709 to 360/67 tss/360 ... it got a 360/30 to replace the 1401 ... could run in 1401 hardare emulation ... but also be used to get some familiarity with 360. as noted, tss/360 never got to production level, so when 360/67 came in, it ran mostly as 360/65 with os/360. initially student fortran ran over a minute elapsed time (almost 100 times longer than on 709). getting hasp cut the elapsed time in half to little over 30secs. I then did a lot of work on os/360 starting with mft11 to carefully order the placement of files and pds members to optimize PDS member search and arm seek distance ... which got almost additional three times improvement in elapsed time. This is old post with part of presentation I gave at fall1968 share meeting ... mostly about major rewrite I did for cp67 kernel and associated pathlength and throughput improvements ... but also discusses a little about the very careful rework of stage2 sysgen to optimize disk throughput. http://www.garlic.com/~lynn/94.html#18 CP/67 OS MFT14 http://www.garlic.com/~lynn/94.html#20 CP/67 OS MFT14 -- 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: [OT ] Mainframe memories
jwgli...@gmail.com (John Gilmore) writes: begin extract one of the things that I did have lots of problems with was supporting position independent code (mentioned in the tss/360 wiki article) ...constantly having to hack code to make in position independent /end extract Is 'position independent' code the same as location-independent code? Presumably not, since location-dependent code, which gives trouble when modifications are made elsewhere in its containing routine, is something that I have tried to avoid for a good many years now. (I recall with no fondness a 60-year-old pseudo-random number generator that was location-dependent.) re: http://www.garlic.com/~lynn/2014d.html#25 [OT ] Mainframe memories I've used position location independence somewhat interchangeably. In my use for cp67/cms page mapped filesystem and in tss/360 use ... the executable image on disk could be directly mapped to any address in memory w/o any further alterations or changes. traditional os/360 image had relocatable address constants ... originally the executable image would be loaded into some arbitrary address in real storage ... and then the loading process would cycle through the list of relocatable address constants ... appropriately adjusting them for the loaded address/location. http://en.wikipedia.org/wiki/OS/360_Object_File_Format in tss/360, position/location independance met that the executable image on disk could be mapped to arbitrary address in virtual memory w/o having to change/adjust antyhing (there was no such thing as os/360 relocatable address constants). going from 360/67 to 370 virtual memory ... it was limited to only 24bit virtual addressing ... which could be configured as 256 64kbyte segments. in my paged mapped implementation ... http://www.garlic.com/~lynn/submain.html#mmap it was possible to map executable images (or any file system object) as one or more shared segments (single copy appearing simultaneously in multiple different virtual address spaces). with position independence, any address space could have any combination of shared objects at any arbitrary virtual address. in the location/position dependent subset implementation (characteristic of os/360 relocatable address constant paradigm), each shared object effectively had to have a unique virtual address across the whole system (in effect it had to be reloaded at some address, and all the relocatable address constants fixed for that address, and that image written back to disk). this became extremely problamatical in a large system when the total aggregate of all possible shared objects exceeded 16mbytes. in the location/position independent implementation any single virtual address space could have any possible combination of shared objects up to a total of 16mbytes. in the location/position dependent subject, a virtual address space couldn't have shared objects that had been predefined at the same address (even if there was still large amount of remaining space at other locations in the virtual address space) http://www.garlic.com/~lynn/submain.html#adcon re: http://www.garlic.com/~lynn/2014d.html#16 [OT ] Mainframe memories http://www.garlic.com/~lynn/2014d.html#22 [OT ] Mainframe memories http://www.garlic.com/~lynn/2014d.html#23 [OT ] Mainframe memorie http://www.garlic.com/~lynn/2014d.html#26 [OT ] Mainframe memorie -- 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: [OT ] Mainframe memories
Was the smoke black or white? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chris Hoelscher Sent: Sunday, March 09, 2014 9:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [OT ] Mainframe memories Maybe IBM elected a new chairman that evening? Chris hoelscher Technology Architect | Database Infrastructure Services Technology Solution Services 123 East Main Street |Louisville, KY 40202 choelsc...@humana.com Humana.com (502) 476-2538 - office (502) 714-8615 - blackberry Keeping CAS and Metavance safe for all HUMANAty -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Blaicher, Christopher Y. Sent: Saturday, March 08, 2014 10:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] [OT ] Mainframe memories Right you are, but it was a long time ago. It was a 360, I know. It could have been a 40 or 50. I just remember the column of smoke and how fast the CE moved. It must have been drawn by a fan as it was a column about 3 or 4 inches in in diameter just going straight up. If I remember correctly, it turned out to be a big resistor. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Saturday, March 08, 2014 7:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [OT ] Mainframe memories In b6c1eb4364c30e47950e0f68ef65f46708f24...@proditmailbox1.us.syncsort.com, on 03/07/2014 at 08:50 PM, Blaicher, Christopher Y. cblaic...@syncsort.com said: When working for a third party disk vendor I was in a computer room and there was an IBM CE working on a 360/45. No such animal; I might believe 360/40 or 370/145. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
In 531be625.2040...@acm.org, on 03/08/2014 at 09:55 PM, Joel C. Ewing jcew...@acm.org said: I believe the CP-40 and CP-67 precursors of VM/370 required more than just S/360 architecture; For CP-40 the extension was nonstandard, but for CP-67 the extension was part of a standard 360/67, even though it was not part of the S/360 architecture. There's a 360/67 functional specifications on bitsavers that describes the non-architected features. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
On 9 March 2014 09:01, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: Much earlier, someone decided that the power unit for the 650 was of a convenient height for drying socks. A Selenium rectifier blew out. Not a pleasant smell (the rectifier; no comment on the socks), as anyone who's been near a cooked one will know. There are easily found refs to the increasing horribleness and persistence of the smell of certain organic sulphur, selenium, and tellurium compounds (and the near impossibility of ever knowing what compounds of the next element down the column in the periodic table - polonium - might smell like. Of course working up the column instead, DHMO doesn't small bad at all. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Write Inhibit (Was: Re: [OT ] Mainframe memories)
On Fri, 7 Mar 2014 22:47:26 -0800, Ed Jaffe wrote: There should still be write inhibit switch for a volume, even if only a logical one. It can be very useful, when running under z/VM, to be able to define some z/OS volumes as read-only. It would be nice if you could do something similar in a z/OS LPAR. Let's turn the discussion around Ed, and inject a little left-field logic. Why run z/OS in an LPAR at all ?. It's already running under a hipervisor - why not just junk PR/SM (and CPs) and run everybody on ILFs under z/VM ?. If IBM can do their development under z/VM, why can't we as customers avail ourselves of the inherent advantages. For free of course, just like PR/SM ... win/win (except maybe IBM and a few ISVs ;-) Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Write Inhibit (Was: Re: [OT ] Mainframe memories)
There should still be write inhibit switch for a volume, even if only a logical one. It can be very useful, when running under z/VM, to be able to define some z/OS volumes as read-only. It would be nice if you could do something similar in a z/OS LPAR. Amen. We could really use this feature. It could be an option when defining devices in the IOCP. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Write Inhibit (Was: Re: [OT ] Mainframe memories)
There should still be write inhibit switch for a volume, even if only a logical one. It can be very useful, when running under z/VM, to be able to define some z/OS volumes as read-only. It would be nice if you could do something similar in a z/OS LPAR. Amen. We could really use this feature. It could be an option when defining devices in the IOCP. z/VM intercepts every SSCH done by its guests, and examines/modifies the guest channel programs. LPAR does not routinely intercept guest SSCH. So it would likely not be reasonable for LPAR to provide a write inhibit switch for a device. z/OS does scan and modify DASD channel programs, so it might be reasonable to have DASD UCB switch which says to set the mask byte in the Define Extent (or analogous command) parameter to inhibit all write operations. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
My memory was about an incident that occurred at an installation that I worked at. Their DASD were 2314s (which were 9 drive units - 8 live and one spare). The address of the drives were controlled by a round plug that could be removed and placed in the address hole of another drive. There were 2 of these units in the room addresses as 170 to 177 and 178 to 17F. The operator know that a job was going to start which was going to need a certain disk volume so to save time he placed it in the space drive of the 170-177 unit. When the job started, the system unmounted 17A and asked for the volume to be mounted there. To save time instead of spinning down the space where he had mounted the volume and placing it in the drive currently known as 17A (or the 178-17F Spare), he just moved the 17A plug into the spare's address hole. Since there was no difference between a xx2 and xxA plug (both are just indicate that they are the 3rd of 8 addresses on the control unit - the 2314 control unit was just wired to respond as 170-177 or 178-17F) suddenly there were 2 drives marked as 172. You can imagine the crash that then occurred killing a long running job using the real 172. The job had to be restarted from the beginning after the volume was restored. The operator was new there and was used to 3330s which only had 8 drives and no spares so this type of premount error could not occur since the new volume would have either been placed in a drive whose volume had been unloaded (and the system would have spotted it there and selected it) or it would have done the unload to free up the drive. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
In b6c1eb4364c30e47950e0f68ef65f46708f24...@proditmailbox1.us.syncsort.com, on 03/07/2014 at 08:50 PM, Blaicher, Christopher Y. cblaic...@syncsort.com said: When working for a third party disk vendor I was in a computer room and there was an IBM CE working on a 360/45. No such animal; I might believe 360/40 or 370/145. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
Right you are, but it was a long time ago. It was a 360, I know. It could have been a 40 or 50. I just remember the column of smoke and how fast the CE moved. It must have been drawn by a fan as it was a column about 3 or 4 inches in in diameter just going straight up. If I remember correctly, it turned out to be a big resistor. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Saturday, March 08, 2014 7:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [OT ] Mainframe memories In b6c1eb4364c30e47950e0f68ef65f46708f24...@proditmailbox1.us.syncsort.com, on 03/07/2014 at 08:50 PM, Blaicher, Christopher Y. cblaic...@syncsort.com said: When working for a third party disk vendor I was in a computer room and there was an IBM CE working on a 360/45. No such animal; I might believe 360/40 or 370/145. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
On 03/08/2014 06:43 PM, Shmuel Metz (Seymour J.) wrote: In 68b5f70ac126ab4dad0e627d782a606a38f...@ufexch-mbxn01.ad.ufl.edu, on 03/07/2014 at 07:56 PM, Nims,Alva John (Al) ajn...@ufl.edu said: IBM 4341 running VM/360 No such animal; there was a CP-67 for the S/360, but VM was strictly for the S/370 and its name reflected that. And the IBM 4341 supported System/370 architecture, so VM/370 was indeed supported on the 4341 and was probably what the author intended. I believe the CP-40 and CP-67 precursors of VM/370 required more than just S/360 architecture; namely, a S/360 model that was hardware-enhanced to include a form of hardware virtual memory support, which subsequently evolved to become part of S/370 architecture. So not only is Seymour correct that VM/360 did not exist, but it would also be inappropriate to retroactively think of CP-40 or CP-67 as equivalent to a VM/360, since both required more than basic S/360 architecture. I remember an IBM 3033 putting out a puff of smoke once, but it stopped before anyone could seriously think about using the EPO. I can't remember whether it was a resistor or capacitor that had fried; but I do remember that the system just kept on running without reporting any errors as if nothing had happened! The CE eventually tracked down the failing component with his nose. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
At 19:54 -0500 on 03/08/2014, Shmuel Metz (Seymour J.) wrote about Re: [OT ] Mainframe memories: In b6c1eb4364c30e47950e0f68ef65f46708f24...@proditmailbox1.us.syncsort.com, on 03/07/2014 at 08:50 PM, Blaicher, Christopher Y. cblaic...@syncsort.com said: When working for a third party disk vendor I was in a computer room and there was an IBM CE working on a 360/45. No such animal; I might believe 360/40 or 370/145. Or a 360/44. -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
At 15:13 -0600 on 03/08/2014, Barry Merrill wrote about Re: [OT ] Mainframe memories: In 1972, the Corporation's Annual PL job read multiple tape reels from each of the 26 regional offices, so 26 tape drives were allocated to the job, which took over 40 hours across a dedicated weekend, and the operators were kept busy mounting and dismounting, but when they had all 26 drives mounted and spinning, and could take a breath to watch, it was a sight to behold. It was so beautiful that one of the junior tape operators took a picture of the spinning tapes. With flash. Causing half of those spinning tape drives to abruptly open, because the optical sensor saw that flash of light as the reflector at the end of the tape, and ABENDing the job. This reminds me of the story of a computer center which was in a high-rise building and about 3 months after some non-IBM drives were added to the IBM ones the non-IBM drives suddenly started to experience a problem. At about 3PM they would suddenly dump their tape loop into the column or unload. High level CEs were called in to diagnose the problem. They finally figured out that the sun was being reflected off the glass windows of the building across the street triggering the optic sensors (IBM Drives used vacuum not optic sensors in the columns so were not affected). The symptom took 3 months to occur since until then the sun was not in the correct position to be reflected. The fix was to put blinds over the windows. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
When I worked for the Ontario government in the early 1980's, we had four 3033's all named after the original colours that they had been as 370's. They were all blue by the time I started working there, but there we signs over each one stating which colour they were and you could use the /*ROUTE JCL card to actually state which colour you wanted the job to run on - -teD - Original Message From: William Donzelli Sent: Thursday, March 6, 2014 23:12 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: [OT ] Mainframe memories To commemorate the 50th anniversary of S/360 I wrote a blog that many of you may have seen already but just in case you missed it: http://butmostlyaboutcats.blogspot.com/2014/03/mainframe-memories.html Very nice, thank you. One thing I noted was the bit about the colors - how each upgraded system had to be a different color. You were probably one of the very few shops that picked green and brown from IBM. These actually were standard paint options for many systems during the late 1970s, but as far as I can see, were almost completely unpopular. -- Will -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
Anyone have 360 Emergency Pull stories? This is secondhand, but I heard of operators playing Frisbee in the machine room and-yeah, emergency PUSH button, no guard. I've used that story to explain to people why there's a guard over it. I also heard of a manager being in the computer room when some sort of alarm went off-maybe just a tape mount request warning-and hitting the BRS to make the noise stop. Well, it stopped. Along with everything else. And I fondly remember the Red Room, aka The Pit, at UofWaterloo. This was a two-story computer room with classrooms and terminal rooms surrounding it on the second level, with glass walls so you could look down into the room and watch the operator ignoring your tape mount. OK, that wasn't the intention, but it was what happened-you'd see the operator reading; submit your request; see the op look up, read the message, and go back to his book. That became less of a good idea once I was on the Systems staff and could go down and yell at them, but of course by then I mostly wasn't working in the public terminal rooms! ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
When working for a third party disk vendor I was in a computer room and there was an IBM CE working on a 360/45. At one point I looked around and saw a column of smoke rising from the center of the processor. I called out to the CE and pointing, said, Is that normal? He flew over a table and hit the EPO on the front of it. He then turned to me and said, no, it isn't. Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith Sent: Friday, March 07, 2014 3:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [OT ] Mainframe memories Anyone have 360 Emergency Pull stories? ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
My shop had an Amdahl circa 1980. The console keyboard had a very convenient LOAD button right there on one side. Too convenient. One of the operators came in and set her purse on the table by the keyboard. Sure enough, it tipped over and started an IPL. Shortly thereafter, Amdahl installed an MES guard around the button. No charge to the customer. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Phil Smith p...@voltage.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 03/07/2014 12:34 PM Subject:Re: [OT ] Mainframe memories Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Anyone have 360 Emergency Pull stories? This is secondhand, but I heard of operators playing Frisbee in the machine room and-yeah, emergency PUSH button, no guard. I've used that story to explain to people why there's a guard over it. I also heard of a manager being in the computer room when some sort of alarm went off-maybe just a tape mount request warning-and hitting the BRS to make the noise stop. Well, it stopped. Along with everything else. And I fondly remember the Red Room, aka The Pit, at UofWaterloo. This was a two-story computer room with classrooms and terminal rooms surrounding it on the second level, with glass walls so you could look down into the room and watch the operator ignoring your tape mount. OK, that wasn't the intention, but it was what happened-you'd see the operator reading; submit your request; see the op look up, read the message, and go back to his book. That became less of a good idea once I was on the Systems staff and could go down and yell at them, but of course by then I mostly wasn't working in the public terminal rooms! ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
One of the operators came in and set her purse on the table by the keyboard. Sure enough, it tipped over and started an IPL Interesting. We had an operator who dropped a book on it. Same result. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
I am sure everyone remembers raised tiles, right? Well our cleaning people started to use some cleaning solution that weakened the tile on the raised floor. This caused people to stumble on these. One Sunday morning we came in to test and found that someone (it turned out to be a disk CE (OEM)) had stumbled on one of these loose tiles and he ripped it all the way off the floor and used it as a HUGE frisbee and let it sail across the computer console area and he broke some equipment and of course the EPO switch. Killed our test time and we had to take pictures and a week later all our OEM equipment was off the floor. I am assuming the disk company had to pay the $25K (this was in the 1970's) damages. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
At a former employer, we had a red master EPO switch under a nice lexan cover, at the bottom of the ramp leading out of the raised floor. And at the bottom of the ramp, right next to the door was another red switch, to actuate the automatic door opener. (Every door release in the building was red) One day, a new printer tech came calling. Guess what happened? The door switches were green, thereafter. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith Sent: Friday, March 07, 2014 3:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [OT ] Mainframe memories Anyone have 360 Emergency Pull stories? ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
Yup - Had exactly the same event with the Cleaner. EPO on Left side of the man trap door and door switch on the right side. 2 days later the EPO was covered with a Plexiglas cover Jerry Whitteridge Lead Systems Programmer Safeway Inc. 925 951 4184 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gary Jacek Sent: Friday, March 07, 2014 3:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [OT ] Mainframe memories At a former employer, we had a red master EPO switch under a nice lexan cover, at the bottom of the ramp leading out of the raised floor. And at the bottom of the ramp, right next to the door was another red switch, to actuate the automatic door opener. (Every door release in the building was red) One day, a new printer tech came calling. Guess what happened? The door switches were green, thereafter. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith Sent: Friday, March 07, 2014 3:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [OT ] Mainframe memories Anyone have 360 Emergency Pull stories? ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Email Firewall made the following annotations. -- Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
ibm science center was on part of the 4th flr of 545 tech sq ... some past posts http://www.garlic.com/~lynn/subtopic.html#545tech but the machine room occupied part of the 2nd flr. it had duplex (two processor) 360/67, 768kbytes memory, three 2301 drums, five 8+1 drive 2314 string plus one 5 drive string. The IBM CE painted each 2314 string a different color ... so mount/unmount 2314 packs on specific drives could be more easily identify which string. on one side along one wall ... right next to floor level ... the 4in (6in?) water pipe from air conditioned units poured directly into 8in sewer pipe (bldg. codes required air gap). the (virtual machine) cp67 development group split off from the science center and took over the ibm boston programming center that occupied part of the 3rd flr (the rest of the 3rd flr was listed as lawyer firm, but the telco closet was on the ibm side, and clearly labled it as a 3letter gov. agency) ... where they got a 370/145 with (unannounced) virtual memory for development of vm370 (morphing cp67/cms into vm370/cms) in their own machine room. MIT Multics was on the 5th flr and they had (multics) GE645 machine room. city of cambridge wanted to pass a water conservation ordinance and cut flowing water directly through air conditioning units and straight into the city sewer ... however, it turned out that bldgs. had not been designed/built to handle weight of recirculating water towers on the roofs. Happy 50th Birthday to the IBM Cambridge Scientific Center, Kendall Square Pioneer (1Feb1964) http://angelinvestingnews.blogspot.com/2014/02/happy-50th-birthday-to-ibm-cambridge.html wiki http://en.wikipedia.org/wiki/Cambridge_Scientific_Center current tech square (bldg 200 is the old 545 with major rennovation, encapsulating a lot of the old bldg) http://tech-square.com/property.html multics 545 tech sq reference http://www.multicians.org/tech-square.html recent view https://maps.google.com/maps?q=545+technology+squarehl=enll=42.363441,-71.091049spn=0.006811,0.00449sll=42.363441,-71.091048lr=lang_ensafe=imageshnear=545+Technology+Square,+Cambridge,+Massachusetts+02139t=hz=19iwloc=A the science centers were shutdown in 1992 ... as part of company going into the red ... company was then reorganized into the 13 baby blues in preparation for breaking up the company (before the board brought in Gerstner to reverse the breakup and resurrect the company) http://smartphonestechnologyandbusinessapps.blogspot.com/2011/07/rip-ibm-cambridge-scientific-center.html invention of virtual machines http://smartphonestechnologyandbusinessapps.blogspot.com/2010/05/bob-creasy-invented-virtual-machines-on.html for other trivia ... a couple of above references were by G. McQuilken, IBM 65-81 (including cambridge science center 77-81) ... other positions included CEO of RSA Security 85-87. -- 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: [OT ] Mainframe memories
My two favorite memories are: 1 - I got called at 0230 because first the system crashed for no apparent reason, then when they went to IPL, it failed to. So I drive into work, go to the machine room, and as I am trying to figure out what is going on, I notice some tape rings on the floor. So I do some investigation and find some more, over by the disk (3350) drive area. So I look a little closer and discover that 3 of the drives had the Write Inhibit switch in the wrong position. One of them was a local page dataset, cause of the initial crash and another was the CSA page pack (which, because we IPL'd with CLPA, was the cause of the IPL failure). 2 - We had a backup site that had our prior mainframe installed. One time, while the machine was powered down, a maintenance person went to the machine room, and all the lights were off, so he reaches into the dark room and fumbles around looking for the switch, however, unknown to him, the halon dump switch was about a foot below the light switch, and guess which one his hand hit first? == Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(at)us(dot)ibm(dot)com All opinions are mine, and do not represent IBM Corporation. == IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 03/07/2014 02:50:00 PM: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
Wayne -- did you ever find out where the tape rings came from, and who'd munged the Write Inhibit switches? On Fri, Mar 7, 2014 at 10:10 PM, Wayne Driscoll wdri...@us.ibm.com wrote: My two favorite memories are: 1 - I got called at 0230 because first the system crashed for no apparent reason, then when they went to IPL, it failed to. So I drive into work, go to the machine room, and as I am trying to figure out what is going on, I notice some tape rings on the floor. So I do some investigation and find some more, over by the disk (3350) drive area. So I look a little closer and discover that 3 of the drives had the Write Inhibit switch in the wrong position. One of them was a local page dataset, cause of the initial crash and another was the CSA page pack (which, because we IPL'd with CLPA, was the cause of the IPL failure). 2 - We had a backup site that had our prior mainframe installed. One time, while the machine was powered down, a maintenance person went to the machine room, and all the lights were off, so he reaches into the dark room and fumbles around looking for the switch, however, unknown to him, the halon dump switch was about a foot below the light switch, and guess which one his hand hit first? == Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(at)us(dot)ibm(dot)com All opinions are mine, and do not represent IBM Corporation. == IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu wrote on 03/07/2014 02:50:00 PM: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- zMan -- I've got a mainframe and I'm not afraid to use it -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
To commemorate the 50th anniversary of S/360 I wrote a blog that many of you may have seen already but just in case you missed it: http://butmostlyaboutcats.blogspot.com/2014/03/mainframe-memories.html Very nice, thank you. One thing I noted was the bit about the colors - how each upgraded system had to be a different color. You were probably one of the very few shops that picked green and brown from IBM. These actually were standard paint options for many systems during the late 1970s, but as far as I can see, were almost completely unpopular. -- Will -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
