Re: Secret Service plans IT reboot
On Mon, 26 Oct 2009 11:57:00 -0400, Bill Fairchild wrote: Speed Matching Buffer, probably. I always thought it would have been more appropriately called a Speed Reducing Buffer. It didn't really match the speed of the device to the speed of the channel, but only reduced the speed to 1.5 MB/second. It was pretty common to get overruns when doing I/O through the SMB. -- Tom Marchant -- 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: Secret Service plans IT reboot
Why is it called a memory leak? I think that's a distributed term. We used to call it something else on the mainframe, but I can't remember what. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Purdy Sent: Monday, October 26, 2009 2:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service plans IT reboot It probably was a 3081 - I may have a memory leak. Tek had seven business data centers and one engineering data center at the time. Engineering was running a 3083 with VM/HPO5 for circuit simulation, and circuit board design system for a time. The disclaimer, ...if I remember is becoming more and more relevant. Sorry for the misinformation. David Purdy -Original Message- From: Anne Lynn Wheeler l...@garlic.com To: IBM-MAIN@bama.ua.edu Sent: Mon, Oct 26, 2009 2:49 pm Subject: Re: Secret Service plans IT reboot dpurd...@aol.com (David Purdy) writes: Yup, Speed Matching Buffer is correct. 168 had timing issues with state-of-the-art 3380's (STK 8380's if I remember). Worst thing was the 168 shared DASD with a 3033 - the 168 always came in second. actually the 168 had faster channels than 3033. after the demise of future system effort, there was a mad rush to get stuff into the 370 softwareproduct pipeline. ... 303x was stop-gap while they got 3081 370-xa moving. -- 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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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: Secret Service plans IT reboot
On Tue, Oct 27, 2009 at 10:10 AM, Ward, Mike S mw...@ssfcu.org wrote: Why is it called a memory leak? I think that's a distributed term. We used to call it something else on the mainframe, but I can't remember what. Core cancer? Hmm, in a few years this list will mainly consist of folks asking for the meaning of terms they've forgotten! (Not zingin' ya, I did it yesterday ...) -- 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: Secret Service plans IT reboot
2009/10/27 Ward, Mike S mw...@ssfcu.org: Why is it called a memory leak? I think that's a distributed term. We used to call it something else on the mainframe, but I can't remember what. Core cancer. Though that term doesn't really apply to what the OP used it for. Tony H. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Purdy Sent: Monday, October 26, 2009 2:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service plans IT reboot It probably was a 3081 - I may have a memory leak. Tek had seven business data centers and one engineering data center at the time. Engineering was running a 3083 with VM/HPO5 for circuit simulation, and circuit board design system for a time. The disclaimer, ...if I remember is becoming more and more relevant. Sorry for the misinformation. David Purdy -- 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: Secret Service plans IT reboot
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Tuesday, October 27, 2009 9:11 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service plans IT reboot Why is it called a memory leak? I think that's a distributed term. We used to call it something else on the mainframe, but I can't remember what. SNIP Memory creep. Memory leak is a nice way of saying someone's coding practices are a little shaky -- in particular, from my experience, what is produced by certain compilers seem to not correctly cleanup after themselves forcing PAPS to have to be rebooted. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer -- -- 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: Secret Service plans IT reboot
I've heard core cancer too, but the term we usually used was storage creep. Mark Vitale Senior Software Engineer Office: 610.865.0300 mark.vit...@perfman.com www.PERFMAN.com This email and any files transmitted with it may contain confidential and /or legally privileged information. It is intended solely for the use of the individual or entity to whom it is addressed. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this email and its attachment(s) is strictly prohibited. If you have received this email in error please notify the sender and delete this email and any attachment(s). -- 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: Secret Service plans IT reboot
It does not happen too much anymore on the mainframe, at least not too noticeable. But we always called it 'Storage Creep'. It just keeps on creeping up until IPL time, if you didn't catch it in time... - Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of P S Sent: Tuesday, October 27, 2009 10:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service plans IT reboot On Tue, Oct 27, 2009 at 10:10 AM, Ward, Mike S mw...@ssfcu.org wrote: Why is it called a memory leak? I think that's a distributed term. We used to call it something else on the mainframe, but I can't remember what. Core cancer? Hmm, in a few years this list will mainly consist of folks asking for the meaning of terms they've forgotten! (Not zingin' ya, I did it yesterday ...) -- 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: Secret Service plans IT reboot
Storage creep? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Tuesday, October 27, 2009 9:11 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service plans IT reboot Why is it called a memory leak? I think that's a distributed term. We used to call it something else on the mainframe, but I can't remember what. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Purdy Sent: Monday, October 26, 2009 2:04 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service plans IT reboot It probably was a 3081 - I may have a memory leak. Tek had seven business data centers and one engineering data center at the time. Engineering was running a 3083 with VM/HPO5 for circuit simulation, and circuit board design system for a time. The disclaimer, ...if I remember is becoming more and more relevant. Sorry for the misinformation. David Purdy -Original Message- From: Anne Lynn Wheeler l...@garlic.com To: IBM-MAIN@bama.ua.edu Sent: Mon, Oct 26, 2009 2:49 pm Subject: Re: Secret Service plans IT reboot dpurd...@aol.com (David Purdy) writes: Yup, Speed Matching Buffer is correct. 168 had timing issues with state-of-the-art 3380's (STK 8380's if I remember). Worst thing was the 168 shared DASD with a 3033 - the 168 always came in second. actually the 168 had faster channels than 3033. after the demise of future system effort, there was a mad rush to get stuff into the 370 softwareproduct pipeline. ... 303x was stop-gap while they got 3081 370-xa moving. -- 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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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: Secret Service plans IT reboot
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. steve_thomp...@stercomm.com (Thompson, Steve) writes: Why is it called a memory leak? I think that's a distributed term. We used to call it something else on the mainframe, but I can't remember what. SNIP Memory creep. Memory leak is a nice way of saying someone's coding practices are a little shaky -- in particular, from my experience, what is produced by certain compilers seem to not correctly cleanup after themselves forcing PAPS to have to be rebooted. Regards, Steve Thompson old lstsrv-l archives from 1991 (back when mailing lists were on bitnet vm370 machines) http://community.emailogy.com/scripts/wa-COMMUNITY.exe?A2=ind9111L=lstsrv-lP=41042 storage cancer -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- 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: Secret Service plans IT reboot
Storage Creep! snip Why is it called a memory leak? I think that's a distributed term. We used to call it something else on the mainframe, but I can't remember what. Core cancer? /snip -- 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: Secret Service plans IT reboot
It does not happen too much anymore on the mainframe, at least not too noticeable. Run JAVA on the mainframe! - Too busy driving to stop for gas! -- 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: Secret Service plans IT reboot
That's it Storage Creep.. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Richbourg, Claude Sent: Tuesday, October 27, 2009 9:32 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service plans IT reboot It does not happen too much anymore on the mainframe, at least not too noticeable. But we always called it 'Storage Creep'. It just keeps on creeping up until IPL time, if you didn't catch it in time... - Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of P S Sent: Tuesday, October 27, 2009 10:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service plans IT reboot On Tue, Oct 27, 2009 at 10:10 AM, Ward, Mike S mw...@ssfcu.org wrote: Why is it called a memory leak? I think that's a distributed term. We used to call it something else on the mainframe, but I can't remember what. Core cancer? Hmm, in a few years this list will mainly consist of folks asking for the meaning of terms they've forgotten! (Not zingin' ya, I did it yesterday ...) -- 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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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: Secret Service plans IT reboot
Yea, it was always *storage creep* then we started running WAS 3.01 back in, oh, 2001 or so and it became *storage leak* while on calls with IBM. So what does that make it now, *storage creak*. --- On Tue, 10/27/09, Ted MacNEIL eamacn...@yahoo.ca wrote: From: Ted MacNEIL eamacn...@yahoo.ca Subject: Re: Secret Service plans IT reboot To: IBM-MAIN@bama.ua.edu Date: Tuesday, October 27, 2009, 5:35 PM It does not happen too much anymore on the mainframe, at least not too noticeable. Run JAVA on the mainframe! - Too busy driving to stop for gas! -- 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
Secret Service plans IT reboot
The Secret Service wants information from industry as it prepares to overhaul its information technology infrastructure. Forty-two mission-oriented applications run on a 1980s IBM mainframe with a 68 percent performance reliability rating. I wonder how reliable a 1980s wintel box would be. http://fcw.com/articles/2009/10/19/web-secret-service-it-modernization.aspx?s=fcwdaily_261009 Dennis Roach GHG Corporation Lockheed Martin Mission Services Facilities Design and Operations Contract Strategic Technical Engineering NASA/JSC Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.commailto:dennis.ro...@usa-spaceops.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -- 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: Secret Service plans IT reboot
On Mon, 2009-10-26 at 09:53 -0400, Roach, Dennis (N-GHG) wrote: 68 percent performance reliability rating I wonder what that *means*? Do they have 68% uptime? Is there a 68% chance of finding a spare TCM? 68% of their staff know how to IPL? What? -- 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: Secret Service plans IT reboot
-Original Message- From: IBM Mainframe Discussion List [On Behalf Of David Andrews Sent: Monday, October 26, 2009 9:07 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service plans IT reboot On Mon, 2009-10-26 at 09:53 -0400, Roach, Dennis (N-GHG) wrote: 68 percent performance reliability rating I wonder what that *means*? Do they have 68% uptime? Is there a 68% chance of finding a spare TCM? 68% of their staff know how to IPL? What? Given that 63.7% of all statistics are made up on the spot, any guess could be arbitrarily declared wrong. -jc- -- 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: Secret Service plans IT reboot
In a message dated 10/26/2009 9:08:13 A.M. Central Daylight Time, d...@lists.duda.com writes: wonder what that *means*? They don't know what they're doing! -- 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: Secret Service plans IT reboot
On Mon, 26 Oct 2009 10:07:17 -0400 David Andrews d...@lists.duda.com wrote: :On Mon, 2009-10-26 at 09:53 -0400, Roach, Dennis (N-GHG) wrote: : 68 percent performance reliability rating :I wonder what that *means*? Do they have 68% uptime? Is there a 68% :chance of finding a spare TCM? 68% of their staff know how to IPL? :What? Is that even possible for 1980 era hardware? How long has it been since the last spare parts were made? -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: Secret Service plans IT reboot
Is that even possible for 1980 era hardware They probably stored old equipment that can be cannibalized for parts. I'm sure IBM doesn't stock parts that old. This will probably be advertised as another getting off the mainframe story. Bob Shannon Rocket Software -- 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: Secret Service plans IT reboot
Is that even possible for 1980 era hardware? -Not sure about parts, but in 1989 at Tektronix, we turned off supposedly the last 168 (MP of course) running west of the Mississippi. We had about a half-dozen CE's there, who wanted a picture taken with each powering down the frame. After the first one did the power-off, the sucker wouldn't come back up, even with the half-dozen working on it for 30 minutes. Didn't shed a tear about it - those SMB APARS were a PITA. And there were no parts locally in Portland. -- 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: Secret Service plans IT reboot
On Mon, Oct 26, 2009 at 10:47 AM, David Purdy dpurd...@aol.com wrote: Is that even possible for 1980 era hardware? -Not sure about parts, but in 1989 at Tektronix, we turned off supposedly the last 168 (MP of course) running west of the Mississippi. We had about a half-dozen CE's there, who wanted a picture taken with each powering down the frame. After the first one did the power-off, the sucker wouldn't come back up, even with the half-dozen working on it for 30 minutes. Didn't shed a tear about it - those SMB APARS were a PITA. And there were no parts locally in Portland. I probably once knew what SMB was, but nowadays my brain says Small/Medium Business or Server Message(ing?) Block. What was it then? -- 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: Secret Service plans IT reboot
Speed Matching Buffer, probably. Bill Fairchild Software Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 Email: bi...@mainstar.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of P S Sent: Monday, October 26, 2009 10:53 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Secret Service plans IT reboot On Mon, Oct 26, 2009 at 10:47 AM, David Purdy dpurd...@aol.com wrote: Is that even possible for 1980 era hardware? -Not sure about parts, but in 1989 at Tektronix, we turned off supposedly the last 168 (MP of course) running west of the Mississippi. We had about a half-dozen CE's there, who wanted a picture taken with each powering down the frame. After the first one did the power-off, the sucker wouldn't come back up, even with the half-dozen working on it for 30 minutes. Didn't shed a tear about it - those SMB APARS were a PITA. And there were no parts locally in Portland. I probably once knew what SMB was, but nowadays my brain says Small/Medium Business or Server Message(ing?) Block. What was it then? -- 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: Secret Service plans IT reboot
Speed Matching Buffer, probably. I thought so, too. They were more trouble than they were worth. Just like the fixed head on (some) original 3350's. - Too busy driving to stop for gas! -- 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: Secret Service plans IT reboot
Speed Matching Buffer, probably. Yup, Speed Matching Buffer is correct. 168 had timing issues with state-of-the-art 3380's (STK 8380's if I remember). Worst thing was the 168 shared DASD with a 3033 - the 168 always came in second. -Original Message- Is that even possible for 1980 era hardware? -Not sure about parts, but in 1989 at Tektronix, we turned off supposedly the last 168 (MP of course) running west of the Mississippi. We had about a half-dozen CE's there, who wanted a picture taken with each powering down the frame. After the first one did the power-off, the sucker wouldn't come back up, even with the half-dozen working on it for 30 minutes. Didn't shed a tear about it - those SMB APARS were a PITA. And there were no parts locally in Portland. I probably once knew what SMB was, but nowadays my brain says Small/Medium Business or Server Message(ing?) Block. What was it then? -- 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: Secret Service plans IT reboot
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. eamacn...@yahoo.ca (Ted MacNEIL) writes: Speed Matching Buffer, probably. I thought so, too. They were more trouble than they were worth. Just like the fixed head on (some) original 3350's. 168 had 1.5mbyte channels (there had been special hack for 3mbyte 2305 ... but it had very limited channel distance). 3380 and 3880 would run at 3mbyte ... to retrofit 3380s to 1.5mbyte channels needed speed matching (and eckd) for 3380 (code named: calypso). calypso for CKD had lots of real problems (most of the speed-match problems with CKD which don't exist if it had been FBA). a few past posts mentioning (problems getting) Calypso (working) http://www.garlic.com/~lynn/2004o.html#7 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2007e.html#40 FBA rant http://www.garlic.com/~lynn/2007f.html#0 FBA rant http://www.garlic.com/~lynn/2008q.html#40 TOPS-10 http://www.garlic.com/~lynn/2009k.html#44 Z/VM support for FBA devices was Re: z/OS support of HMC's 3270 emulation? Note that fixed-head feature on 3350s was for disk intensive operations ... theoritically put high-use data there and not have latency of arm motion. problem was that it didn't ship with multiple exposures (being able to overlap data transfer with 3350 arm motion) ... so a high-use 3350 with arm nearly always in motion (device busy) ... lost a lot of the benefit (transfers had to wait until arm motion and device signaled complete). I tried to get 3350 multiple exposure support out the door ... but was opposed for some esoteric internal political reasons by organizations in hudson valley (they thot I was going to put a lot of high-use paging data there ... and they wanted to come out with an all electronic paging device ... prior incarnation of SSD ... and my paging stuff might compete with them; eventually their stuff got canceled w/o even being announced, but by then, it was too late to do anything for 3350 fixed-head feature, ... note what they were doing somewhat was re-incarnated as extended store) some of provisions for high activity data also lost some motivation with introduction of cache controllers (Ironwood/Sheriff) 3880-11 3380-13 misc. past posts being allowed to play disk engineer in bldgs 14 (disk engineering) 15 (disk product test) http://www.garlic.com/~lynn/subtopic.html#disk -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- 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: Secret Service plans IT reboot
In a message dated 10/26/2009 11:04:56 A.M. Central Daylight Time, dpurd...@aol.com writes: remember). Worst thing was the 168 shared DASD with a 3033 - the 168 always came in second. Ate my lunch on JES3. Had a fall thru list of DEV types followed by a DC X'00'. We don't have no SMB's in the lab...maddest I've ever seen a PSR. -- 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: Secret Service plans IT reboot
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. dpurd...@aol.com (David Purdy) writes: Yup, Speed Matching Buffer is correct. 168 had timing issues with state-of-the-art 3380's (STK 8380's if I remember). Worst thing was the 168 shared DASD with a 3033 - the 168 always came in second. actually the 168 had faster channels than 3033. after the demise of future system effort, there was a mad rush to get stuff into the 370 softwareproduct pipeline. ... 303x was stop-gap while they got 3081 370-xa moving. the 158 had integrated channels (same engine doing both 370 microcode and channel microcode). they took 158 engine with only integrated channel microcode and made it the 303x channel director. A 3031 was then a 158 engine with only 370 microcode and a 2nd 158 engine (channel director) running only channel microcode. A 3032 as 168 reconfigured to use channel director as enternal channels. 3033 started out being 168 logic using 20% chips (the chips also had something like 10 times the number of circuits ... before product ship ... some amount of the logic was redone to use the larger circuits per chip and got 3033 up to 1.5 times 168 ... instead of only 1.2 times). In disk enginneering lab, I was doing channel processing overhead timings ... latency to do a head-switch on 3330 disk drive (read/write CCW, seak head, read/write CCW). 3330s could be formated with dummy records that increased inter-record gap ... allowing timing latency to insert a head-switch seek between the end of one record on a track and the start of a next record on a different track (but same cylinder). The size of the dummy record ... was adjusted to take into account channel processing latency. The fastest channel (lowest latency in terms of size of dummy record to allow for channel latency) was 168, 148, 4341, etc. The slowest was 158 (needed larger dummy record ... to account for higher latency and slower processing of 158 integrated channel). All of the 303x processing (3031, 3032, 3033) with (158 engine) channel director had identical operational characteristics to 158. Now sjr (bldg. 28 across street from bldg. 14 15) for a time had a 168 MVS system and a 158 VM system. All of the 3330 strings were interconnected ... but there was a rule that NO MVS packs would be mounted on VM-designated strings ... because the enormous performance penalty (drive, controller, channel) associated with common MVS multi-track search operations. One day, an operator, accidentially mount a MVS pack on a drive in a VM-designated string. Within 10 minutes ... the datacenter was getting irate calls from users regarding severe degraded performance. Operations initially refused to switch the pack (to MVS-designated string) until off-shift. The VM group had a VS1 sysetm that had been highly optimized ... especially for running under VM. They took the VS1 pack and placed it on a MVS-designated string ... and started up standard sequence of (OS360) multi-track searches (VTOC, PDS, etc) ... and nearly brought the MVS system to its knews (i.e. the VS1 system on a VM/158 system nearly resulting in stoping a MVS/168 system ... by being able to do better job of multitrack searches). The nearly halting of the MVS/168 system ... so slowed down the multi-track searchs on the mis-mounted MVS pack ... that the VM/158 user throughput then nearly returned to normal (even with the load of virtual VS1 keeping the MVS/168 system in check). At that point, operations decided to immediately move the mis-mounted MVS pack ... if the VM group would shutdown their virtual VS1 system. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 -- 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: Secret Service plans IT reboot
It probably was a 3081 - I may have a memory leak. Tek had seven business data centers and one engineering data center at the time. Engineering was running a 3083 with VM/HPO5 for circuit simulation, and circuit board design system for a time. The disclaimer, ...if I remember is becoming more and more relevant. Sorry for the misinformation. David Purdy -Original Message- From: Anne Lynn Wheeler l...@garlic.com To: IBM-MAIN@bama.ua.edu Sent: Mon, Oct 26, 2009 2:49 pm Subject: Re: Secret Service plans IT reboot dpurd...@aol.com (David Purdy) writes: Yup, Speed Matching Buffer is correct. 168 had timing issues with state-of-the-art 3380's (STK 8380's if I remember). Worst thing was the 168 shared DASD with a 3033 - the 168 always came in second. actually the 168 had faster channels than 3033. after the demise of future system effort, there was a mad rush to get stuff into the 370 softwareproduct pipeline. ... 303x was stop-gap while they got 3081 370-xa moving. -- 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: Secret Service plans IT reboot
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. re: http://www.garlic.com/~lynn/2009p.html#12 Secret Service plans IT reboot there use to be a joke about TSO users not realizing how deplorable performance was because they couldn't see the difference by operating with w/o MVS (actually in large part, CKD multi-track search). CKD multi-track search introduced with original 360 was scarce resource use trade-off of the period ... by the mid-70s, the relative amounts of resources had nearly inverted (which resources were the scarcest), starting to make multi-track search the exact wrong thing to do, there was a large national retail operation with a consolidated datacenter (large number of systems in loosely-coupled configuration) ... which started to run into severe throughput problem during peak periods. This went on for awhile, lots of experts being brought in over period of time, until they eventualy got around to calling me in. I was brought into a class room with large number of long class tables ... covered with high stacks of paper performance details from all the systems. while i started to leaf through all the pages (for shared disk activity, I had to aggregate drive activity from different systems/reports in my head ... while they started through overall summary of the symptoms). After about 20-25 minutes ... I started to notice a somewhat anomolous circumstance ... about the only correlation between good thruput and nearly no thruput was a specific pack had aggregated i/o counts between 6 and 7 during high-load/low-throughput (which would seem to hardly be a thruput limitation). After a little more investigation ... it turned out, the pack contained the shared application library for the whole complex ... more investigation was that the PDS had a three cylinder PDS directory. Back of the envelope calculations was that avg. depth of search was cylinder and half (PDS member lookup) ... that would be two multi-track search I/Os that took elapsed time of nearly 1/2 second. Assumption then was the two PDS directory lookup I/Os would be followed by a single I/O for a PDS member load. That accounts for aggregate of six I/Os per second saturating the drive ... basically limiting the whole national loosely-coupled infrastructure to performing an aggregate of two application (PDS) program library loads per second. Each full-cylinder multi-track search represented enormous busy elapsed time for the processor channel (locking out any other activity on the same channel). The full-cylinder multi-track searches also locked up the (shared) controller, string and drive ... locking out all systems from accessing anything else associated with those resources. The eventual result was reconfiguring everything to try and come as close as possible to eliminating the long multi-track searches (drastically reduced PDS directory size) ... and replicating the shared application library on non-shared drives for each system. PDS directory ( vtoc) multi-track searches alleviated needing the real storage to contain the directory information (at enormous cost in I/O resources). By the mid-70s, real storage was becoming plentiful enough that it was practical to keep high-useage (vtoc ) PDS directory information cached in system storage (allowing fast lookup of instorage index) ... so program loads could happen at normal disk activity thruput speeds (say 30-50/second) ... instead of at 2/second (limited by the enormous PDS directory multi-track search penalty). This resource trade-off also showed up with RDBMS ... the original relational/sql was done on vm system in bldg. 28 ... system/r ... misc. past posts: http://www.garlic.com/~lynn/subtopic.html#systemr In the 70s, there was somewhat rivalry between the IMS group in STL and system/r in bldg. 28 on the main plant site. IMS group claimed better trade-offs because record pointers were exposed as part of the data ... and it was possible to go directly to a specific piece of data. This was contrasted with RDBMS implementation that had an implicit index ... which could take 4-5 disk i/os to eventually find the location of the desired data record. This implicit index also tended to double the physical disk space required (vis-a-vis same data in IMS). The system/r group countered that the exposed record pointers created a significant administrative and maintanance overhead ... especially for adding data ... nearly eliminated by the implicit indexes). The resource trade-offs argument changed with combination of enormous disk size increases and drastic fall in cost/mbyte (muting the issue regarding doubling disk space for the indexes). At the same time there was significant increase in available system real storage ... making it practical to cache a large portion of the (implicit) RDBMS indexes (drastically reducing separate physical disk i/os to find data record). -- 40+yrs
Re: Secret Service plans IT reboot
Is that even possible for 1980 era hardware? How long has it been since the last spare parts were made? Do we even know that it is one of the water machines? Maybe it is a 4381 - those things might run forever. In any case, I would *really* like to know where this machine ends up. The old water cooled machines are nearly extinct. -- Will -- 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: Secret Service plans IT reboot
In a message dated 10/26/2009 8:08:27 P.M. Central Daylight Time, wdonze...@gmail.com writes: Do we even know that it is one of the water machines? Maybe it is a 4381 - those things might run forever. One of the classic SHAREs the 'Fat Boys' actually were brave enough to document their experiences when converting to a 43xx(maybe a 61 don't remember). Doing pretty good 'til they tried to hook up a three phase printer(maybe a Siemens) and managed to blow out the circuit boards to the I/O driver for everything. There were holes where the T05 cans used to be! -- 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
