Re: Item on TPF
On 2/27/2010 at 8:13 AM, in message listserv%201002270913195378.0...@bama.ua.edu, Eric Bielefeld eric-ibmm...@wi.rr.com wrote: I'm curious. How much more does z/OS cost than z/VSE? An approximate percentage is good enough. I have no idea. I'm just an apps guy. What are your reasons for converting? It sounds like from the way you worded your comment below that z/VSE doesn't have some restrictions that z/OS does, although I may have misread your comments. In my opinion only. I could list probably 20 things I miss from VSE. But I don't want to bore everyone. The main reason we are converting, as far as I can tell, is that z/OS is just better supported, but by IBM and by ISVs. I don't think anyone here is unhappy with how VSE works. Again, don't get me wrong, z/OS has a lot of good stuff. But it seems to be missing some things that I have found to be very useful on VSE. I did a conversion back in 1985 from DOS to MVS 1.3.6. I think it took alomost as long to convert from DOS to MVS as it did to get off of the mainframe 4 years ago. In 1985, we ran 5 DOS guests under VM. We've been working on it since, I think, late 2008. Conversion date is scheduled for the end of May this year. Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- 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
Cobol for OS/390 VM V1r2 still supported
Is IBM cobol for OS/390 VM v1r2 is still supported under regular support terms? If so, is there any drop from support date? ITschak -- 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: Cobol for OS/390 VM V1r2 still supported
Hi Itschak, The place to look is IBMs Software Support Lifecycle page (http://www-01.ibm.com/software/support/lifecycle/index_a_z.html). David Stephens Lead Systems Programmer d...@longpelaexpertise.com.au www.longpelaexpertise.com.au http://www.longpelaexpertise.com.au/images/logo.gif (Longpela Expertise Logo) Longpela Expertise - System z Mainframe Consultants Read new expert Mainframe articles every quarter in our LongEx Mainframe Quarterly http://www.longpelaexpertise.com.au/ezine Itschak Mugzach wrote: Is IBM cobol for OS/390 VM v1r2 is still supported under regular support terms? If so, is there any drop from support date? ITschak -- 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: Cobol for OS/390 VM V1r2 still supported
Thanks. It look like it is not supported anymore. ITschak On Sun, Feb 28, 2010 at 2:45 PM, David Stephens d...@longpelaexpertise.com.au wrote: Hi Itschak, The place to look is IBMs Software Support Lifecycle page ( http://www-01.ibm.com/software/support/lifecycle/index_a_z.html). David Stephens Lead Systems Programmer d...@longpelaexpertise.com.au www.longpelaexpertise.com.au http://www.longpelaexpertise.com.au/images/logo.gif (Longpela Expertise Logo) Longpela Expertise - System z Mainframe Consultants Read new expert Mainframe articles every quarter in our LongEx Mainframe Quarterly http://www.longpelaexpertise.com.au/ezine Itschak Mugzach wrote: Is IBM cobol for OS/390 VM v1r2 is still supported under regular support terms? If so, is there any drop from support date? ITschak -- 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 -- 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: Cobol for OS/390 VM V1r2 still supported
Itschak Mugzach wrote: Is IBM cobol for OS/390 VM v1r2 is still supported under regular support terms? If so, is there any drop from support date? ITschak -- 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 See http://www-03.ibm.com/servers/eserver/zseries/zos/le/history/cobmvs.html and note that V1 was named COBOL for MVS VM and V2 was named COBOL for OS/390 VM so the VvRr and compiler name you showed don't appear to match. George -- 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: Red Alert: All TCPIP users on z/OS 1.11 (2010.02.26)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Jacobs Sent: Friday, February 26, 2010 6:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Red Alert: All TCPIP users on z/OS 1.11 (2010.02.26) I seem to remember a similar red alert last year for all the then = supported zOS releases. I'm surprised this popped up again under zOS = 1.11. Mark Jacobs -Original Message- From: IBM Mainframe Discussion List on behalf of Knutson, Sam Sent: Fri 2/26/2010 7:25 PM To: IBM-MAIN@bama.ua.edu Subject: Red Alert: All TCPIP users on z/OS 1.11 (2010.02.26) =20 http://www14.software.ibm.com/webapp/set2/sas/f/redAlerts/20100226.html = Abstract: A logic error in the base TCPIP code of z/OS 1.11 can cause applications = using ASYNCIO Writes to be driven twice. This can affect various = applications and subsystems using z/OS TCPIP ASYNCIO on the sending = side, such as Websphere MQ, JES and non-IBM products. Description: A logic error in TCPIP on z/OS 1.11 can cause applications using ASYNCIO = Writes to be driven twice. The application data presented on the socket = write operation is sent over the TCP connection twice, thus corrupting = the data stream. This can affect various applications and subsystems = using z/OS TCPIP ASYNCIO on the sending side, such as Websphere MQ, JES = and non-IBM products. Please see APAR PM08514 for the details and = symptoms that may result.=20 Recommended Action: All z/OS 1.11 users should install the APAR fix for PM08514 that is = currently available from IBM Support. This APAR does not apply to prior = z/OS releases.=20 SNIPPAGE It is the same thing. We were talking with IBM on Friday and ... Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is a Server? (Was FTP Datahub Question)
In listserv%201002240949176433.0...@bama.ua.edu, on 02/24/2010 at 09:49 AM, Paul Gilmartin paulgboul...@aim.com said: Size doesn't matter? For example, consider X11, where the terms are widely misused. Likewise SMTP. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What was old is new again (water chilled)
In m3y6irr6mo@garlic.com, on 02/17/2010 at 02:42 PM, Anne Lynn Wheeler l...@garlic.com said: As an aside, vm370 release 6 ... was the last free vm370 kernel ... the next release being vm/sp release 1 You don't consider SEPP (VM/SE) or BSEPP (VM/BSE) to be VM releases? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Need tool to zap core
In 8s7ko59k15vnib8c1qkvaqo83dkjppj...@4ax.com, on 02/28/2010 at 09:48 AM, Binyamin Dissen bdis...@dissensoftware.com said: Who suggested another case? Nobody suggested *any* case; you left it open. That makes it reasonable to take it as a general statement, rather than as one limited to a special case. Feel better now? I'd feel better if the HMC let me plug in an ASN[1] Or if IBM brought back DSS, suitably updated and supported. I won't hold my breathe. [1] Yes, that would be system dependent, but then so would the page fixing that I'd also want :-( -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Adventure - Or Colossal Cave Adventure
In 4b89f3d6.60...@valley.net, on 02/27/2010 at 11:40 PM, Gerhard Postpischil gerh...@valley.net said: AFAIK, IBM distributed a type 3 program named RACS (Remote Access Computing System) in the mid sixties; Boston University modified that to develop RAX; and McGill modified it to MUSIC. I recall RAX as having been FORTRAN only. By the time I heard of MUSIC it was more general and I wasn't aware of the RAX connection. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHAREWARE at Its Finest
jim.marsh...@opm.gov (Jim Marshall) writes: P.S. Getting the first of a new generation of IBM computer, the IBM 3032, made us a showplace besides being in the Pentagon. But 6 months later IBM shipped the first IBM 3033 to Singer up in New Jersey, we were obsolete and never got the IBM 3032-AP/MP we hoped would come. 3032 was basically 168-3 repackaged to use 303x channel director instead of the 168 external channel boxes. in the wake of demise of future system, there was mad-rush to get stuff back into the 370 product pipelines. they took the 158 integrated channel microcode and split it into separate (dedicated 158 engine) box for the 303x channel controller. the 3031 then becomes a 158 with just the 370 microcode and a 2nd/separate 158 with just the integrated channel microcode (with same 158 engine no longer needed to be shared with executing both 370 microcode and integrated channel microcode, 3031 thruput becomes almost as fast as 4341). the 3032 then becomes a 168 with 303x channel director (158 with just the integrated channel microcode) instead of the 168 external channel boxes. the 3033 started out being the 168 logic mapped to chips that were 20percent faster. The chips also had a lot more circuits per chip ... initially that would be unused. In the 3033 product cycle there was some effort to redesign pieces of 168 logic to take advantage of the higher cicuit density ... and finally got the 3033 up to 50% faster than 168. there was eventually a 3033N sold that was crippled to be slower than 168/3032 but could be field upgraded to full 3033. -- 42yrs 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: What was old is new again (water chilled)
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. shmuel+ibm-m...@patriot.net (Shmuel Metz , Seymour J.) writes: You don't consider SEPP (VM/SE) or BSEPP (VM/BSE) to be VM releases? re: http://www.garlic.com/~lynn/2010d.html#43 What was old is now new again (water chilled) they were charged for kernel add-ons to the free vm370 release 6 base. as part of 23jun69 unbundling announcement, there was start of charging for application software (somewhat as the result of various litigation), however they managed to make the case that kernel software was still free. http://www.garlic.com/~lynn/submain.html#unbundle also discussed in this recent posts: http://www.garlic.com/~lynn/2010d.html#42 search engine history, was Happy DEC-10 Day http://www.garlic.com/~lynn/2010e.html#24 Unbundling HONE with the demise of future system project ... there was mad rush to get items back into the 370 product pipeline ... also there have been claims that it was the distraction of the FS product (and lack of products) that allowed clone processors to get foothold in the marketplace. misc. past FS posts http://www.garlic.com/~lynn/submain.html#futuresys part of the rush to get things back into 370 product pipeline contributed to picking up various 370 things that I had been doing during the FS period for product release. some recent discussion (as well as Unbundling HONE post referenced above) http://www.garlic.com/~lynn/2010e.html#21 paged-access method One of the things was the resource manager. However, possibly because of the foothold that the clone processors were getting in the market, there was decision to start charging for kernel software ... and my resource manager was selected as guinea pig. Also discussed here http://www.garlic.com/~lynn/2010e.html#25 HONE Compute Intensive which shipped in the middle of the vm370 release 3 time-frame. As mentioned in the above ... vm370 multiprocessor support was to go out in vm370 release 4 ... but design/implementation was dependent on lots of code in the resource manager. The initial policy for kernel charging was that hardware support would still be free (including multiprocessor support) and couldn't have prerequisite that was charged for ... as in my resource manager. The eventually solution was to move approx. 90% of the code from the resource manager into the free base ... but leave the price of the release 4 resource manager the same (as release 3, even tho it was only about 10% of the code). for vm370 release 5, the resource manager was repackaged with some amount of other code ... including multiple shadow table support ... discussed here: http://www.garlic.com/~lynn/2010e.html#1 LPARs: More or Less? and renamed HPO (i.e. HPO was the charged for software that fit ontop of vm370 release 5). for vm370 release 6, the charged for software was repackaged, a full set of all the software (previously HPO) which was renamed SEPP ... and a subset of the SEPP software ... at a lower price that was named BSEPP. So neither SEPP nor BSEPP were free ... they were both kernel add-on software for the free vm370 release 6 base, that was charged for. When it came time for vm370 release 7, there was transition to charging for all kernel software ... and everything was merged back into single charged for kernel renamed VM/SP (and there was no more vm370 releases). vm370 release 6 being free has been made available for Hercules (370 virtual machine on intel platform) ... but not any of the charged for software ... my resource manager, HPO, SEPP, BSEPP, vm/sp, etc. -- 42yrs 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: Item on TPF
From: Frank Swarbrick frank.swarbr...@efirstbank.com To: IBM-MAIN@bama.ua.edu Sent: Sun, February 28, 2010 2:52:46 AM Subject: Re: Item on TPF --SNIP--- In my opinion only. I could list probably 20 things I miss from VSE. But I don't want to bore everyone. The main reason we are converting, as far as I can tell, is that z/OS is just better supported, but by IBM and by ISVs. I don't think anyone here is unhappy with how VSE works. Again, don't get me wrong, z/OS has a lot of good stuff. But it seems to be missing some things that I have found to be very useful on VSE. SNIP--- I do not know about you but there is a list a mile long about the things I hated about DOS. One of the most difficult things that I ran across were split cylinders. DOS documentation was in my opinion horrid. After reading the doc (I used that term loosely) I had to go to our local IBM rep. He read it over and admitted he didn't quite understand it. So he called up a friend of his in Hiedleberg (Germany), and he got a quick lesson so he explained it to me. I guess I understood it but as soon as I saw it used in DOS JCL (that is a laugh) It baffled me so I took the JCL up to my IBM friend and asked him to translate and he couldn't (I did not feel bad). He called his friend again and the friend was puzzled but good through it and I got on the phone and we went step by step through it. I walked away hating DOS forever more. There were other idiosyncrasies that was so stupid I just shook my head and thought I would be so happy never to see DOS again for the rest of my life. I didn't either. I was happy to work on MFT it did make sense. When I got out of the army the OS we were running was MFT and soon upgraded to OS/VS2 then I switched jobs and have been MVS ever since. YUCK DOS SUCKED. Ed -- 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: What was old is new again (water chilled)
On Sun, Feb 28, 2010 at 8:35 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net shmuel%2bibm-m...@patriot.net wrote: You don't consider SEPP (VM/SE) or BSEPP (VM/BSE) to be VM releases? (Basic) System Extensions Program Product? No, that would be an add-on. -- 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: ServerPac share something amusing
Sorry. The first CHANGE PATH switches /Service/ and /, the second changes
it right back.
Looks like a waste to me, but maybe there is something I am missing.
Scott Rowe scott.r...@joann.com
Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
02/27/2010 07:23 PM
Please respond to
IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
Expire Date: 02/28/2012
To
IBM-MAIN@bama.ua.edu
cc
Subject
Re: ServerPac share something amusing
OK, you win. What's wrong with it?
John Mattson john_matt...@ea.epson.com 02/27/10 6:44 PM
Going thru the ServerPAC for CICSTS 4.1 I noticed the followng in the
SCPPBENU(UP). No editing by me, exactly how it looks...
SET BDY(CICT410) .
ZEDIT DDDEF .
CHANGE PATH('/Service/'*,
'/'*) .
ENDZEDIT .
ZEDIT DDDEF .
CHANGE UNIT(*,*) .
CHANGE VOLUME(*,*) .
CHANGE PATH('/'*,
'/Service/'*) .
ENDZEDIT .
--
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: Crazed idea: SDSF for z/Linux
On Fri, 26 Feb 2010 11:26:44 -0500, Thompson, Steve steve_thomp...@stercomm.com wrote: I think we are talking about two different issues. Entirely possible. My apologies if I've misunderstood. Now, if you were to do this with a running system (z/Linux for instance), I'd think that the auditors and security people should be able to use piano wire or whatever. I'll go with whatever. Piano wire would be too quick. But again if running under VM, VM has the ability to prevent your access to the target volumes by reason of IEF, does it not? Sure, but no more than LPAR I/O config. Exception: You can give a guest R/O access to the volume - LPAR can't do that. Of course, that doesn't help you *repair* it unless you want to clone it and repair the clone, leaving the original untouched. I don't know what IEF means. Alan Altmark IBM -- 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: ServerPac share something amusing
On 28 February 2010 20:52, John Mattson john_matt...@ea.epson.com wrote: Sorry. The first CHANGE PATH switches /Service/ and /, the second changes it right back. Looks like a waste to me, but maybe there is something I am missing. The second may change more than just what the first change changed. Tony H. -- 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: SHAREWARE at Its Finest
On 28 February 2010 16:13, Anne Lynn Wheeler l...@garlic.com wrote: they took the 158 integrated channel microcode and split it into separate (dedicated 158 engine) box for the 303x channel controller. the 3031 then becomes a 158 with just the 370 microcode and a 2nd/separate 158 with just the integrated channel microcode In light of your oft-posted anecdotes about disk test-cell and MTTF of MVS I/O subsystem... Around 1977, a grad student friend of mine got a gig with the university to build a buffer for the unbuffered 2501 card reader, so that multiple such readers could be used over 2944 channel extenders, which added an unacceptable delay when used over close to a mile of twisted-pairs, and provoked channel overruns. (The other choice was an OEM buffered card reader, which worked fine electrically, but couldn't come close to the mechanical reliability and ability to read a warped and sticky student deck.) He did initial testing with my assistance (as sysprog and writer of standalone test programs) on our 165 or 155, depending on which was available overnight or weekends. Early debugging on the 165 (2870 byte multiplexor channel) generally resulted in appropriate I/O status codes if the interface timing was bad. The same debugging on the 155 invariably produced red lights and complete machine lockup, resolved only by power off/on. I don't know how similar the 158 and 155 really were (certainly very different front panel implementations), but it's interesting that the 303x got the microcoded channels, rather than the clunky but rock solid 28x0 hardwired ones. Tony H. -- 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: SHAREWARE at Its Finest
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. t...@harminc.net (Tony Harminc) writes: I don't know how similar the 158 and 155 really were (certainly very different front panel implementations), but it's interesting that the 303x got the microcoded channels, rather than the clunky but rock solid 28x0 hardwired ones. re: http://www.garlic.com/~lynn/2010e.html#27 SHAREWARE at Its Finest as i've mentioned before ... happening to mention the 15min MTBF issue internally at the time brought down the wrath of the mvs organization on my head. the 3081 channel was a lot like the 158 also. some discussion about the 3081 ... another somewhat quick effort in the wake of the failure of FS; http://www.jfsowa.com/computer/memo125.htm misc. past posts mentioning future system http://www.garlic.com/~lynn/submain.html#futuresys misc. past posts getting to play disk engineer in bldgs. 1415 http://www.garlic.com/~lynn/subtopic.html#disk i had been doing some timing tests on how sort a dummy record that was needed to doing track head switch (seek head) between two rotationally consecutive records on different tracks (involving both channel processing latency and control unit processing latency). 168, 145, 4341 could succesfully do the switch with shorter block than 158, 303x, and 3081. There were also some number of OEM disk controllers that had lower latency and required smaller dummy record ... less of rotational delay to cover the processing latency to process seek head operation. The 3830 disk controller was horizontal microcode engine that was much faster than the vertical microcode engine (jib-prime) used in the 3880 disk controller. To compensate for the slower processing and also handle higher data rates ... there was dedicated hardware for data flow ... separate from the control processing done by the jib-prime. Data-streaming was also introduced (no longer having to do handshake for every byte transfer (help both with supporting 3mbyte transfers at the same time allowing max. channel length to be increased from 200ft to 400ft). There was requirement at the time that 3880 had to be within +/- 5percent of 3830 ... they ran some batch operating performance tests in STL and it didn't quite make it ... so they tweaked the 3880 control to present operation complete interrupt ... before 3880 had actually fully completed all the operations (to appear to be within five percent of 3830). Then if 3880 discovered something in error in its cleanup work ... it would present an asyncrhonous unit check. I told them that was violation of the architecture ... at which time they dragged me into resolution conference calls with the channel engineers in POK. Finally they decided that they would saved up the unit check error condition ... and present it as cc=1, csw-stored, unit check on the next sio (unsolicited unit checks were violation of channel architecture). so everybody seems to be happy. then one monday morning the bldg. 15 engineers call me up and asked me what i did over the weekend to trash the performance of the (my) vm370 system they were running. I claimed to have done nothing ... they claimed to have done nothing. Finally it was determined that they had replaced a 3830 that they were using with string of 16 3330 cms drives ... with a 3880. While their batch os acceptance test didn't have a problem ... i had severely optimized the pathlength for i/o redrive (of queued operations) after an i/o completion. My redrive sio was managed to hit the 3880 with the next operation while the 3880 was still busy cleaning up the previous operation (they had assumed that they could get it done faster than operating system interrupt processing). Because the controller was still busy, I would get cc=1, csw-stored, sm+busy (aka controller busy). The operation then would have to be requeued and go off to look for something else to do. Then because the controller had signaled SM+BUSY, it was obligated to do a CUE interrupt. The combination of the 3880 slower processing and all the extra operating system processing gorp ... was degrading their interactive service by severe 30percent (which was what had prompted the monday morning call). While 3880, the batch performance acceptance tests had originally eventually passsed ... however somewhat related the the earlier 15min MTBF issue ... much nearer 3880 product ship, engineers had developed a regression test suite of 57 expected errors. old email that for all the errors in the regression test, mvs required reboot ... and in 2/3rds the cases, there was no evidence of what required mvs to be rebooted. Recent post mentioning the issue http://www.garlic.com/~lynn/2010d.html#59 LPARs: More or Less? old posted email mentioning the problem: http://www.garlic.com/~lynn/2007.html#email801015 -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
Out of Office Mike Spires/AO/USR/FTU is out of the office.
I will be out of the office starting 03/01/2010 and will not return until 03/08/2010. I will respond to your message when I return. -- 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
