Re: What was a 3314? (was: Whither VIO)
Caveat: daily digester back from a long weekend (in Canada) -> responses are implicitly delayed. Martin: using ISMF, in the VIO Storage Pool definition is VIO Unit (beside the MaxSize). I haven't been able to find a complete list of available device types but v2.1 documentation focus is on 3390 with the occasional mention of 3380. Supposedly any valid device could be used. [pause] hey, managed to locate it. [1] Presumably it's used to determine byte to track conversions for SPACE=. Similar to " Default Device Geometry :" in the CDS Base panels. [2] From Implementing SMS manual, " The VIO device type is virtual and is unrelated to actual devices on your system. " [1] DGTHDT06 HELP DEVICE TYPES SUPPORTED BY ISMF --HELP COMMAND ===> The following list contains the device types that are supported by ISMF. DASD Device Types: TAPE Device Types: 3380 3400-3 3390 3400-4 9345 3400-5 3400-6 3400-9 3480 3480X 3490 3590-1 [2] DGTHBS07 HELP DEFAULT DEVICE GEOMETRY -HELP COMMAND ===> The DEFAULT DEVICE GEOMETRY field specifies the default values to use when converting all requests for space into KB or MB. These values appear in the BYTES/TRACK and TRACKS/CYLINDER fields. > signature = 8 lines follows < Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee “How *do* you plan for something like that?” Guardian Bob, Reboot “For every action, there is an equal and opposite criticism.” “Systems Programming: Guilty, until proven innocent” John Norgauer 2004 "Schrodinger's backup: The condition of any backup is unknown until a restore is attempted." John McKown 2015 -Original Message- From: Martin Packer [mailto:ma..pac..@UK.. ..COM] Sent: May 20, 2016 01:48 Subject: Re: What was a 3314? (was: Whither VIO) Right. My (now long gone, I fear) VIOTOES presentation majored on (the then new) DFSMS implementation. In particular ACS Routines and VIOMAXSIZE. But I still thought you had to have some VIO devices defined. > On 19 May 2016, at 22:53, Gibney, David Allen wrote: > > Very, Very early in implementing SMS (the minimal implementation) is managing > VIO. > > Since we've been SMS for a long time, there aren't even any devices in our > EDT(s) for VIO [snip] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Pipelines RFE (was: Whither VIO)
On 2016-05-20, at 14:04, Jesse 1 Robinson wrote: > I'm not sure how this interacts with the SMS limit on VIO, but we once > experienced a near system meltdown from TSO TRANSMIT of a large file. ... > There's some rationale here for the Pipelines RFE. CMS Pipelines includes a NETDATA stage which would make it possible to TRANSMIT a PS file with no use of temporary data sets (but CMS SENDFILE is not yet so savvy). To TRANSMIT a PO file would require that IEBCOPY be Pipelines-savvy on the PDSU side. In CMS, it's dismaying that most traditional utilities are not Pipelines-savvy. Rather, for some of them there are surrogate Pipelines filters. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
I'm not sure how this interacts with the SMS limit on VIO, but we once experienced a near system meltdown from TSO TRANSMIT of a large file. There's a parameter in the TRANSREC entry in SYS1.PARMLIB(IKJTSO00) to control use of VIO. The pertinent keyword is VIO(xxx), which if defaulted (at least at that time) allowed the use of VIO for the XMIT temporary data set. We now specify VIO(SYSALLDA), which pushes the temporary file to real DASD. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: Friday, May 20, 2016 11:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: What was a 3314? (was: Whither VIO) The "all 16 extents" applies to VIOMAXSIZE calculation, by the way. Cheers, Martin Sent from my iPad > On 20 May 2016, at 17:26, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On 2016-05-19, at 15:04, Longabaugh, Robert E wrote: >> >> ... Also VIO would get all 16 extents at once, so saying TRK(1,1) >> was not better than saying TRK(16). When a job did the VIO allocation, it got the page slots. >> > Perhaps not quite. My experience is that it gets the page slot as > each page > is accessed. Thereby hangs a tale. > > I had a job that passed a temp DS I had overallocated as CYL(0,large); primary > 0 to circumvent the then behavior of reading residual data if the DS > was never > written; EODAD was entered at end-of-extent. > > Then I tried UNIT=VIO. Worked fine and only page slots actually > written were > allocated. Until once when the first step didn't open it for output. > In the > second step, VIO read every slot looking for EOF. Page storage exhaused. > For everybody. Ouch! > > -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
The "all 16 extents" applies to VIOMAXSIZE calculation, by the way. Cheers, Martin Sent from my iPad > On 20 May 2016, at 17:26, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On 2016-05-19, at 15:04, Longabaugh, Robert E wrote: >> >> ... Also VIO would get all 16 extents at once, so saying TRK(1,1) was not better than saying TRK(16). When a job did the VIO allocation, it got the page slots. >> > Perhaps not quite. My experience is that it gets the page slot as each page > is accessed. Thereby hangs a tale. > > I had a job that passed a temp DS I had overallocated as CYL(0,large); primary > 0 to circumvent the then behavior of reading residual data if the DS was never > written; EODAD was entered at end-of-extent. > > Then I tried UNIT=VIO. Worked fine and only page slots actually written were > allocated. Until once when the first step didn't open it for output. In the > second step, VIO read every slot looking for EOF. Page storage exhaused. > For everybody. Ouch! > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
On 2016-05-19, at 15:04, Longabaugh, Robert E wrote: > ... Also VIO would get all 16 extents at once, so saying TRK(1,1) was not > better than saying TRK(16). When a job did the VIO allocation, it got the > page slots. > Perhaps not quite. My experience is that it gets the page slot as each page is accessed. Thereby hangs a tale. I had a job that passed a temp DS I had overallocated as CYL(0,large); primary 0 to circumvent the then behavior of reading residual data if the DS was never written; EODAD was entered at end-of-extent. Then I tried UNIT=VIO. Worked fine and only page slots actually written were allocated. Until once when the first step didn't open it for output. In the second step, VIO read every slot looking for EOF. Page storage exhaused. For everybody. Ouch! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
A few remaining synapses at the back of my brain are saying "Module, Bin, Cylinder, Head, Record" But they could be telling lies Ray -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ward, Mike S Sent: 19 May 2016 23:24 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) Wasn't the MM the bon number? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edward Gould Sent: Wednesday, May 18, 2016 11:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) > On May 18, 2016, at 7:50 PM, Charles Mills wrote: > > I remember them well. I was answering Steve's two implied questions. > > 2321 was certainly characterized as DASD. It was indeed a direct access > storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape > (though it had a family resemblance!) and certainly not unit record. It addressing had MMBBCCHHR(R?) so I guess you could address it directly. Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where is Seymour?). Ed > > I don't think anyone recalls a 3314. I think the OP said it was a typo, 2314 > mis-remembered as 3000-series DASD. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Edward Gould > Sent: Wednesday, May 18, 2016 5:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: What was a 3314? (was: Whither VIO) > > Chales, > > 2321 was a data cell (magnetic strip) hardly could be called DASD) I > don’t recall a 3314 . The removable 3340 (not sure the number anyone?) > > Ed > >> On May 16, 2016, at 7:47 PM, Charles Mills wrote: >> >> >> >> 2301, 2321. >> CharlesSent from a mobile; please excuse the brevity >> >> Original message ---- >> From: Steve Thompson >> Date: 05/16/2016 4:51 PM (GMT-08:00) >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: What was a 3314? (was: Whither VIO) >> >> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've >> had the pleasure of working with. I've forgotten the drum device >> numbers and the noodle snatcher model number. > > -- > 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 == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is 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 message 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...@listserv.ua.edu with the message: INFO IBM-MAIN -- This e-mail message has been scanned and cleared by Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
Right. My (now long gone, I fear) VIOTOES presentation majored on (the then new) DFSMS implementation. In particular ACS Routines and VIOMAXSIZE. But I still thought you had to have some VIO devices defined. Cheers, Martin Sent from my iPad > On 19 May 2016, at 22:53, Gibney, David Allen wrote: > > Very, Very early in implementing SMS (the minimal implementation) is managing VIO. > > Since we've been SMS for a long time, there aren't even any devices in our EDT(s) for VIO > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Norman.Hollander >> Sent: Thursday, May 19, 2016 2:45 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: What was a 3314? (was: Whither VIO) >> >> Maybe a bunch of JCL with UNIT=VIO is a cause to make you fuss? >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Ted MacNEIL >> Sent: Thursday, May 19, 2016 1:18 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: What was a 3314? (was: Whither VIO) >> >> Memory is abundant in most shops and cheap overall. So, why all fuss about >> VIO? Make s decision, implement it, forget it. >> >> -teD >> Original Message >> From: Norman.Hollander >> Sent: Thursday, May 19, 2016 12:19 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Reply To: IBM Mainframe Discussion List >> Subject: Re: What was a 3314? (was: Whither VIO) >> >> Track size. We actually used to use a 2305 "drum" definition for VIO. But if >> you genned 1 dummy address, you had to gen all 8. Made for a larger IO-gen. >> So we would go for the next best tracksize of the 2314. So- how many 4K >> pages fit into a track without wasting too much of it? Plus the 2314 was small, >> so quick sorts in VIO might be possible, but it prevented sorting a kabillion >> records. I'm pretty sure 2305 support was removed a long time ago, so you >> couldn't define it today. Probably true for the 2311/2314/2319. Last time I >> went through IODF, a fake 3390 (address DEFF) was defined as the only VIO >> capable device. With all the various Sort and Memory exits today, it's >> probably just a good history lesson. Oh- way back in the 70s, a company >> named Ampex (IIRC) made look alike (aka cheaper) memory and Disk storage. >> Think their mountable disk was the 3314. OK- discuss further... >> >> zNorman >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Martin Packer >> Sent: Wednesday, May 18, 2016 10:45 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: What was a 3314? (was: Whither VIO) >> >> >> It's sort of come back to me: >> >> A small track size limits the virtual storage window (probably usually below >> the line in 1989 when I looked at this). Or it might've been cylinder. But I >> think it was track. >> >> I'm wondering if anyone else remembers something like this. >> >> Cheers, Martin >> >> Sent from my iPad >> >> On 19 May 2016, at 05:20, Edward Gould >> wrote: >> >>>> On May 18, 2016, at 7:50 PM, Charles Mills >> wrote: >>>> >>>> I remember them well. I was answering Steve's two implied questions. >>>> >>>> 2321 was certainly characterized as DASD. It was indeed a direct >>>> access >> storage device. Not a disk, but DASD nonetheless. Certainly not magnetic >> tape (though it had a family resemblance!) and certainly not unit record. >>> >>> It addressing had MMBBCCHHR(R?) so I guess you could address it directly. >> Anyone remember how to do that? (progr5amming for a 2321 is a lost art >> (where is Seymour?). >>> >>> Ed >>> >>>> >>>> I don't think anyone recalls a 3314. I think the OP said it was a >>>> typo, >> 2314 mis-remembered as 3000-series DASD. >>>> >>>> Charles >>>> >>>> -Original Message- >>>> From: IBM Mainframe Discussion List [mailto:IBM- >> m...@listserv.ua.edu] >>>> On >> Behalf Of Edward Gould >>>> Sent: Wednesday, May 18, 2016 5:33 PM >>>> To: IBM-MAIN@LISTSERV.UA.EDU >>>> Subject: Re: What was a 3314? (was: Whither VIO) >>>> >>>> Chales, >>>> >>>> 2321 was a data cell (magnetic strip) hardly could be called DASD) I >> don’t recall a 3314 . The removabl
Re: What was a 3314? (was: Whither VIO)
On 19 May 2016 at 16:56, Martin Packer wrote: > The whole disk is NOT in your virtual storage; The track window IS (IIRC). Well I wasn't thinking *your* (the caller's) virtual storage; obviously it can't all be there. I was thinking there would be a VSM mapping of the whole device in *some* virtual space, but clearly this wouldn't have worked with 24-bit addressing. So I guess my mental model for this is wrong; presumably VIO is a driver of ASM at the same level as VSM is. And there must be a track (or some larger or smaller page-multiple) buffer that forms the interface to ASM. Well I guess going and looking at the code would be best; MVS 3.8 is still out there for the reading. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
Wasn't the MM the bon number? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edward Gould Sent: Wednesday, May 18, 2016 11:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) > On May 18, 2016, at 7:50 PM, Charles Mills wrote: > > I remember them well. I was answering Steve's two implied questions. > > 2321 was certainly characterized as DASD. It was indeed a direct access > storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape > (though it had a family resemblance!) and certainly not unit record. It addressing had MMBBCCHHR(R?) so I guess you could address it directly. Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where is Seymour?). Ed > > I don't think anyone recalls a 3314. I think the OP said it was a typo, 2314 > mis-remembered as 3000-series DASD. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Edward Gould > Sent: Wednesday, May 18, 2016 5:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: What was a 3314? (was: Whither VIO) > > Chales, > > 2321 was a data cell (magnetic strip) hardly could be called DASD) I > don’t recall a 3314 . The removable 3340 (not sure the number anyone?) > > Ed > >> On May 16, 2016, at 7:47 PM, Charles Mills wrote: >> >> >> >> 2301, 2321. >> CharlesSent from a mobile; please excuse the brevity >> >> Original message ---- >> From: Steve Thompson >> Date: 05/16/2016 4:51 PM (GMT-08:00) >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: What was a 3314? (was: Whither VIO) >> >> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've >> had the pleasure of working with. I've forgotten the drum device >> numbers and the noodle snatcher model number. > > -- > 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 == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is 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 message 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
Very, Very early in implementing SMS (the minimal implementation) is managing VIO. Since we've been SMS for a long time, there aren't even any devices in our EDT(s) for VIO > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Norman.Hollander > Sent: Thursday, May 19, 2016 2:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: What was a 3314? (was: Whither VIO) > > Maybe a bunch of JCL with UNIT=VIO is a cause to make you fuss? > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Ted MacNEIL > Sent: Thursday, May 19, 2016 1:18 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: What was a 3314? (was: Whither VIO) > > Memory is abundant in most shops and cheap overall. So, why all fuss about > VIO? Make s decision, implement it, forget it. > > -teD > Original Message > From: Norman.Hollander > Sent: Thursday, May 19, 2016 12:19 > To: IBM-MAIN@LISTSERV.UA.EDU > Reply To: IBM Mainframe Discussion List > Subject: Re: What was a 3314? (was: Whither VIO) > > Track size. We actually used to use a 2305 "drum" definition for VIO. But if > you genned 1 dummy address, you had to gen all 8. Made for a larger IO-gen. > So we would go for the next best tracksize of the 2314. So- how many 4K > pages fit into a track without wasting too much of it? Plus the 2314 was > small, > so quick sorts in VIO might be possible, but it prevented sorting a kabillion > records. I'm pretty sure 2305 support was removed a long time ago, so you > couldn't define it today. Probably true for the 2311/2314/2319. Last time I > went through IODF, a fake 3390 (address DEFF) was defined as the only VIO > capable device. With all the various Sort and Memory exits today, it's > probably just a good history lesson. Oh- way back in the 70s, a company > named Ampex (IIRC) made look alike (aka cheaper) memory and Disk storage. > Think their mountable disk was the 3314. OK- discuss further... > > zNorman > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Martin Packer > Sent: Wednesday, May 18, 2016 10:45 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: What was a 3314? (was: Whither VIO) > > > It's sort of come back to me: > > A small track size limits the virtual storage window (probably usually below > the line in 1989 when I looked at this). Or it might've been cylinder. But I > think it was track. > > I'm wondering if anyone else remembers something like this. > > Cheers, Martin > > Sent from my iPad > > On 19 May 2016, at 05:20, Edward Gould > wrote: > > >> On May 18, 2016, at 7:50 PM, Charles Mills > wrote: > >> > >> I remember them well. I was answering Steve's two implied questions. > >> > >> 2321 was certainly characterized as DASD. It was indeed a direct > >> access > storage device. Not a disk, but DASD nonetheless. Certainly not magnetic > tape (though it had a family resemblance!) and certainly not unit record. > > > > It addressing had MMBBCCHHR(R?) so I guess you could address it directly. > Anyone remember how to do that? (progr5amming for a 2321 is a lost art > (where is Seymour?). > > > > Ed > > > >> > >> I don't think anyone recalls a 3314. I think the OP said it was a > >> typo, > 2314 mis-remembered as 3000-series DASD. > >> > >> Charles > >> > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] > >> On > Behalf Of Edward Gould > >> Sent: Wednesday, May 18, 2016 5:33 PM > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: What was a 3314? (was: Whither VIO) > >> > >> Chales, > >> > >> 2321 was a data cell (magnetic strip) hardly could be called DASD) I > don’t recall a 3314 . The removable 3340 (not sure the number anyone?) > >> > >> Ed > >> > >>> On May 16, 2016, at 7:47 PM, Charles Mills > wrote: > >>> > >>> > >>> > >>> 2301, 2321. > >>> CharlesSent from a mobile; please excuse the brevity > >>> > >>> Original message > >>> From: Steve Thompson > >>> Date: 05/16/2016 4:51 PM (GMT-08:00) > >>> To: IBM-MAIN@LISTSERV.UA.EDU > >>> Subject: Re: What was a 3314? (was: Whither VIO) > >>> > >>> 2314, 2419, 2311, these are just a few of the &qu
Re: What was a 3314? (was: Whither VIO)
Maybe a bunch of JCL with UNIT=VIO is a cause to make you fuss? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ted MacNEIL Sent: Thursday, May 19, 2016 1:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) Memory is abundant in most shops and cheap overall. So, why all fuss about VIO? Make s decision, implement it, forget it. -teD Original Message From: Norman.Hollander Sent: Thursday, May 19, 2016 12:19 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: What was a 3314? (was: Whither VIO) Track size. We actually used to use a 2305 "drum" definition for VIO. But if you genned 1 dummy address, you had to gen all 8. Made for a larger IO-gen. So we would go for the next best tracksize of the 2314. So- how many 4K pages fit into a track without wasting too much of it? Plus the 2314 was small, so quick sorts in VIO might be possible, but it prevented sorting a kabillion records. I'm pretty sure 2305 support was removed a long time ago, so you couldn't define it today. Probably true for the 2311/2314/2319. Last time I went through IODF, a fake 3390 (address DEFF) was defined as the only VIO capable device. With all the various Sort and Memory exits today, it's probably just a good history lesson. Oh- way back in the 70s, a company named Ampex (IIRC) made look alike (aka cheaper) memory and Disk storage. Think their mountable disk was the 3314. OK- discuss further... zNorman -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: Wednesday, May 18, 2016 10:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) It's sort of come back to me: A small track size limits the virtual storage window (probably usually below the line in 1989 when I looked at this). Or it might've been cylinder. But I think it was track. I'm wondering if anyone else remembers something like this. Cheers, Martin Sent from my iPad On 19 May 2016, at 05:20, Edward Gould wrote: >> On May 18, 2016, at 7:50 PM, Charles Mills wrote: >> >> I remember them well. I was answering Steve's two implied questions. >> >> 2321 was certainly characterized as DASD. It was indeed a direct >> access storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape (though it had a family resemblance!) and certainly not unit record. > > It addressing had MMBBCCHHR(R?) so I guess you could address it directly. Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where is Seymour?). > > Ed > >> >> I don't think anyone recalls a 3314. I think the OP said it was a >> typo, 2314 mis-remembered as 3000-series DASD. >> >> Charles >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Edward Gould >> Sent: Wednesday, May 18, 2016 5:33 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: What was a 3314? (was: Whither VIO) >> >> Chales, >> >> 2321 was a data cell (magnetic strip) hardly could be called DASD) I don’t recall a 3314 . The removable 3340 (not sure the number anyone?) >> >> Ed >> >>> On May 16, 2016, at 7:47 PM, Charles Mills wrote: >>> >>> >>> >>> 2301, 2321. >>> CharlesSent from a mobile; please excuse the brevity >>> >>> Original message >>> From: Steve Thompson >>> Date: 05/16/2016 4:51 PM (GMT-08:00) >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: What was a 3314? (was: Whither VIO) >>> >>> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've >>> had the pleasure of working with. I've forgotten the drum device >>> numbers and the noodle snatcher model number. >> >> - >> - 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 >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listser
Re: What was a 3314? (was: Whither VIO)
ESCTVIO (Expanded Storage Criterion Age for VIO) was supposed to control it. Current Migration Age was compared to the Criterion Age. (I think Criterion Age SINGULAR for VIO. Someone correct me if I'm wrong, please.) Cheers, Martin Sent from my iPad > On 19 May 2016, at 22:05, Longabaugh, Robert E wrote: > > Small track sizes were considered more efficient for VIO because of the number of page slots that had to be used in order to satisfy the allocation. Also VIO would get all 16 extents at once, so saying TRK(1,1) was not better than saying TRK(16). When a job did the VIO allocation, it got the page slots. > > In 1990 or 1991 (before I worked for Sterling Software and now CA) my employer had a series of system slowdowns which were caused by paging slot shortages, or exhaustion. We found that many jobs were using VIO for SORTWKnn DDs. This all traced back to an individual application programmer who knew just enough about VIO to see it was virtual, but did not grasp the difference between "virtual" and "unlimited". > > I don't remember there being a way to put a hard limit on the total amount of VIO in use by the system. Now in the days of cached and solid state DASD the I/O performance payback isn't as big. As in the previous response, the system did not set aside an entire 2314 (or 3330) worth of page slots to back the VIO requests. It just fulfilled the requests for "tracks" as they came in. > > > Bob Longabaugh > CA Technologies > Storage Management > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer > Sent: Thursday, May 19, 2016 3:56 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: What was a 3314? (was: Whither VIO) > > > The whole disk is NOT in your virtual storage; The track window IS (IIRC). > > Cheers, Martin > > Sent from my iPad > >>> On 19 May 2016, at 21:45, Tony Harminc wrote: >>> >>> On 19 May 2016 at 01:44, Martin Packer wrote: >>> It's sort of come back to me: >>> >>> A small track size limits the virtual storage window (probably >>> usually below the line in 1989 when I looked at this). Or it might've >>> been cylinder. But I think it was track. >>> >>> I'm wondering if anyone else remembers something like this. >> >> I'm not sure I get the "virtual storage window" idea. VIO emulates an >> entire disk drive in virtual storage. So where is there a window? The >> whole disk has to be in virtual storage at once. Well, I suppose there >> could be logic to not allocate Virtual until used, but that would >> surely better be left to VSM's and RSM's expertise at managaing their >> respective kinds of storage. >> >> Now maybe VIO was changed much later (surely there wasn't expanded >> storage in 1989...?) to use or perhaps favour expanded storage, in >> which case a window model could make some sense. But only if VIO was >> directly dealing with expanded storage rather than just requesting >> that RSM use it to back virtual storage used to hold the VIO disk >> data. >> >> Tony H. >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > -- > 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-MAINUnless > stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
Small track sizes were considered more efficient for VIO because of the number of page slots that had to be used in order to satisfy the allocation. Also VIO would get all 16 extents at once, so saying TRK(1,1) was not better than saying TRK(16). When a job did the VIO allocation, it got the page slots. In 1990 or 1991 (before I worked for Sterling Software and now CA) my employer had a series of system slowdowns which were caused by paging slot shortages, or exhaustion. We found that many jobs were using VIO for SORTWKnn DDs. This all traced back to an individual application programmer who knew just enough about VIO to see it was virtual, but did not grasp the difference between "virtual" and "unlimited". I don't remember there being a way to put a hard limit on the total amount of VIO in use by the system. Now in the days of cached and solid state DASD the I/O performance payback isn't as big. As in the previous response, the system did not set aside an entire 2314 (or 3330) worth of page slots to back the VIO requests. It just fulfilled the requests for "tracks" as they came in. Bob Longabaugh CA Technologies Storage Management -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: Thursday, May 19, 2016 3:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) The whole disk is NOT in your virtual storage; The track window IS (IIRC). Cheers, Martin Sent from my iPad > On 19 May 2016, at 21:45, Tony Harminc wrote: > >> On 19 May 2016 at 01:44, Martin Packer wrote: >> It's sort of come back to me: >> >> A small track size limits the virtual storage window (probably >> usually below the line in 1989 when I looked at this). Or it might've >> been cylinder. But I think it was track. >> >> I'm wondering if anyone else remembers something like this. > > I'm not sure I get the "virtual storage window" idea. VIO emulates an > entire disk drive in virtual storage. So where is there a window? The > whole disk has to be in virtual storage at once. Well, I suppose there > could be logic to not allocate Virtual until used, but that would > surely better be left to VSM's and RSM's expertise at managaing their > respective kinds of storage. > > Now maybe VIO was changed much later (surely there wasn't expanded > storage in 1989...?) to use or perhaps favour expanded storage, in > which case a window model could make some sense. But only if VIO was > directly dealing with expanded storage rather than just requesting > that RSM use it to back virtual storage used to hold the VIO disk > data. > > Tony H. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: What was a 3314? (was: Whither VIO)
The whole disk is NOT in your virtual storage; The track window IS (IIRC). Cheers, Martin Sent from my iPad > On 19 May 2016, at 21:45, Tony Harminc wrote: > >> On 19 May 2016 at 01:44, Martin Packer wrote: >> It's sort of come back to me: >> >> A small track size limits the virtual storage window (probably usually >> below the line in 1989 when I looked at this). Or it might've been >> cylinder. But I think it was track. >> >> I'm wondering if anyone else remembers something like this. > > I'm not sure I get the "virtual storage window" idea. VIO emulates an > entire disk drive in virtual storage. So where is there a window? The > whole disk has to be in virtual storage at once. Well, I suppose there > could be logic to not allocate Virtual until used, but that would > surely better be left to VSM's and RSM's expertise at managaing their > respective kinds of storage. > > Now maybe VIO was changed much later (surely there wasn't expanded > storage in 1989...?) to use or perhaps favour expanded storage, in > which case a window model could make some sense. But only if VIO was > directly dealing with expanded storage rather than just requesting > that RSM use it to back virtual storage used to hold the VIO disk > data. > > Tony H. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
On 19 May 2016 at 01:44, Martin Packer wrote: > It's sort of come back to me: > > A small track size limits the virtual storage window (probably usually > below the line in 1989 when I looked at this). Or it might've been > cylinder. But I think it was track. > > I'm wondering if anyone else remembers something like this. I'm not sure I get the "virtual storage window" idea. VIO emulates an entire disk drive in virtual storage. So where is there a window? The whole disk has to be in virtual storage at once. Well, I suppose there could be logic to not allocate Virtual until used, but that would surely better be left to VSM's and RSM's expertise at managaing their respective kinds of storage. Now maybe VIO was changed much later (surely there wasn't expanded storage in 1989...?) to use or perhaps favour expanded storage, in which case a window model could make some sense. But only if VIO was directly dealing with expanded storage rather than just requesting that RSM use it to back virtual storage used to hold the VIO disk data. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
Memory is abundant in most shops and cheap overall. So, why all fuss about VIO? Make s decision, implement it, forget it. -teD Original Message From: Norman.Hollander Sent: Thursday, May 19, 2016 12:19 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: What was a 3314? (was: Whither VIO) Track size. We actually used to use a 2305 "drum" definition for VIO. But if you genned 1 dummy address, you had to gen all 8. Made for a larger IO-gen. So we would go for the next best tracksize of the 2314. So- how many 4K pages fit into a track without wasting too much of it? Plus the 2314 was small, so quick sorts in VIO might be possible, but it prevented sorting a kabillion records. I'm pretty sure 2305 support was removed a long time ago, so you couldn't define it today. Probably true for the 2311/2314/2319. Last time I went through IODF, a fake 3390 (address DEFF) was defined as the only VIO capable device. With all the various Sort and Memory exits today, it's probably just a good history lesson. Oh- way back in the 70s, a company named Ampex (IIRC) made look alike (aka cheaper) memory and Disk storage. Think their mountable disk was the 3314. OK- discuss further... zNorman -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: Wednesday, May 18, 2016 10:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) It's sort of come back to me: A small track size limits the virtual storage window (probably usually below the line in 1989 when I looked at this). Or it might've been cylinder. But I think it was track. I'm wondering if anyone else remembers something like this. Cheers, Martin Sent from my iPad On 19 May 2016, at 05:20, Edward Gould wrote: >> On May 18, 2016, at 7:50 PM, Charles Mills wrote: >> >> I remember them well. I was answering Steve's two implied questions. >> >> 2321 was certainly characterized as DASD. It was indeed a direct >> access storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape (though it had a family resemblance!) and certainly not unit record. > > It addressing had MMBBCCHHR(R?) so I guess you could address it directly. Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where is Seymour?). > > Ed > >> >> I don't think anyone recalls a 3314. I think the OP said it was a >> typo, 2314 mis-remembered as 3000-series DASD. >> >> Charles >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Edward Gould >> Sent: Wednesday, May 18, 2016 5:33 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: What was a 3314? (was: Whither VIO) >> >> Chales, >> >> 2321 was a data cell (magnetic strip) hardly could be called DASD) I don’t recall a 3314 . The removable 3340 (not sure the number anyone?) >> >> Ed >> >>> On May 16, 2016, at 7:47 PM, Charles Mills wrote: >>> >>> >>> >>> 2301, 2321. >>> CharlesSent from a mobile; please excuse the brevity >>> >>> Original message >>> From: Steve Thompson >>> Date: 05/16/2016 4:51 PM (GMT-08:00) >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: What was a 3314? (was: Whither VIO) >>> >>> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've >>> had the pleasure of working with. I've forgotten the drum device >>> numbers and the noodle snatcher model number. >> >> - >> - 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 >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
On Thu, 19 May 2016 13:40:48 +, Roach, Dennis wrote: >Since almost all "3390" DASD resides on FBA arrayed disks, the software exists >and is running in the control units to convert ECKD to FBA requests. > Kinda proprietary, though, whether from IBM or competitors, and hard to make a business case for any of them to install in a thumb drive. >[Default] On 18 May 2016 19:31:34 -0700, (Steve Thompson) wrote: >>> snip >>Makes one very glad to have things like thumb drives that we have >>today. Now if I could just get one big enough to IPL z/OS... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
Track size. We actually used to use a 2305 "drum" definition for VIO. But if you genned 1 dummy address, you had to gen all 8. Made for a larger IO-gen. So we would go for the next best tracksize of the 2314. So- how many 4K pages fit into a track without wasting too much of it? Plus the 2314 was small, so quick sorts in VIO might be possible, but it prevented sorting a kabillion records. I'm pretty sure 2305 support was removed a long time ago, so you couldn't define it today. Probably true for the 2311/2314/2319. Last time I went through IODF, a fake 3390 (address DEFF) was defined as the only VIO capable device. With all the various Sort and Memory exits today, it's probably just a good history lesson. Oh- way back in the 70s, a company named Ampex (IIRC) made look alike (aka cheaper) memory and Disk storage. Think their mountable disk was the 3314. OK- discuss further... zNorman -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: Wednesday, May 18, 2016 10:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) It's sort of come back to me: A small track size limits the virtual storage window (probably usually below the line in 1989 when I looked at this). Or it might've been cylinder. But I think it was track. I'm wondering if anyone else remembers something like this. Cheers, Martin Sent from my iPad On 19 May 2016, at 05:20, Edward Gould wrote: >> On May 18, 2016, at 7:50 PM, Charles Mills wrote: >> >> I remember them well. I was answering Steve's two implied questions. >> >> 2321 was certainly characterized as DASD. It was indeed a direct >> access storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape (though it had a family resemblance!) and certainly not unit record. > > It addressing had MMBBCCHHR(R?) so I guess you could address it directly. Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where is Seymour?). > > Ed > >> >> I don't think anyone recalls a 3314. I think the OP said it was a >> typo, 2314 mis-remembered as 3000-series DASD. >> >> Charles >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Edward Gould >> Sent: Wednesday, May 18, 2016 5:33 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: What was a 3314? (was: Whither VIO) >> >> Chales, >> >> 2321 was a data cell (magnetic strip) hardly could be called DASD) I don’t recall a 3314 . The removable 3340 (not sure the number anyone?) >> >> Ed >> >>> On May 16, 2016, at 7:47 PM, Charles Mills wrote: >>> >>> >>> >>> 2301, 2321. >>> CharlesSent from a mobile; please excuse the brevity >>> >>> Original message >>> From: Steve Thompson >>> Date: 05/16/2016 4:51 PM (GMT-08:00) >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: What was a 3314? (was: Whither VIO) >>> >>> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've >>> had the pleasure of working with. I've forgotten the drum device >>> numbers and the noodle snatcher model number. >> >> - >> - 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 >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- 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: What was a 3314? (was: Whither VIO)
W dniu 2016-05-19 o 15:40, Roach, Dennis pisze: Since almost all "3390" DASD resides on FBA arrayed disks, the software exists and is running in the control units to convert ECKD to FBA requests. Not so easy. USB stick use USB "CCW", so without hardware changes on mainframe side there would be no possibility to IPL from that. No USB port on mainframe. Or change USB tisk to support mainframe "CCW" and FICON... Another possibility is to create standalone Linux x64 image on the stick, with Hercules or zPDT, with some z/OS image. ;-) -- Radoslaw Skorupka Lodz, Poland --- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2016 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.955.696 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
Since almost all "3390" DASD resides on FBA arrayed disks, the software exists and is running in the control units to convert ECKD to FBA requests. Dennis Roach, CISSP, PMP IAM Access Administration - Consumer - Senior Analyst 2929 Allen Parkway, America Building, 3rd Floor, Houston, TX 77019 Work: 713-831-8799 Cell: 713-591-1059 Email: dennis.ro...@aig.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. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris Sent: Thursday, May 19, 2016 8:29 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) [Default] On 18 May 2016 19:31:34 -0700, in bit.listserv.ibm-main ste...@copper.net (Steve Thompson) wrote: >> snip >Makes one very glad to have things like thumb drives that we have >today. Now if I could just get one big enough to IPL z/OS... Would 128 gigabytes be enough. I think I have seen 256 GB. The software to emulate ECKD would be interesting. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
[Default] On 18 May 2016 19:31:34 -0700, in bit.listserv.ibm-main ste...@copper.net (Steve Thompson) wrote: >> snip >Makes one very glad to have things like thumb drives that we have >today. Now if I could just get one big enough to IPL z/OS... Would 128 gigabytes be enough. I think I have seen 256 GB. The software to emulate ECKD would be interesting. Clark Morris > >Regards, >Steve Thompson > > >On 05/18/2016 09:07 PM, Paul Gilmartin wrote: >> On Wed, 18 May 2016 17:50:53 -0700, Charles Mills wrote: >> >>> ... It was indeed a direct access storage device. Not a disk, but DASD >>> nonetheless. Certainly not magnetic tape (though it had a family >>> resemblance!) and certainly not unit record. >>> >> What's the criterion? Max/Min latency ratio? Statistical distribution of >> latency >> between randomly selected records? For tape, it's sort of triangular; for >> DASD >> it has a sort of plateau. >> >> Addressable by block and writable randomly without corrupting other blocks? >> DECtape had preformatted addressable blocks; it held a filesystem with a >> directory. It moved from reel to reel past a stationary R/W head. It met >> some >> criteria for DASD and some for tape; it was both. >> >> -- gil >> >> -- >> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
On Wed, May 18, 2016 at 7:33 PM, Edward Gould wrote: > Chales, > > 2321 was a data cell (magnetic strip) hardly could be called DASD) > Technically, it was because you could get to a particular "block" of data "directly" (DASD == Direct Access Storage Device) as opposed to a "serial" device like tape (no "seek" on the original tape drives). It definitely was wasn't a "random access" device because of the seek time (the same is true of all disk devices). SSD and Flash are possibly the only non-volatile true "random" access mass storage devices at present. And I'm not totally sure about them. > I don’t recall a 3314 . The removable 3340 (not sure the number anyone?) > > Ed > > -- The unfacts, did we have them, are too imprecisely few to warrant our certitude. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
It's sort of come back to me: A small track size limits the virtual storage window (probably usually below the line in 1989 when I looked at this). Or it might've been cylinder. But I think it was track. I'm wondering if anyone else remembers something like this. Cheers, Martin Sent from my iPad On 19 May 2016, at 05:20, Edward Gould wrote: >> On May 18, 2016, at 7:50 PM, Charles Mills wrote: >> >> I remember them well. I was answering Steve's two implied questions. >> >> 2321 was certainly characterized as DASD. It was indeed a direct access storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape (though it had a family resemblance!) and certainly not unit record. > > It addressing had MMBBCCHHR(R?) so I guess you could address it directly. Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where is Seymour?). > > Ed > >> >> I don't think anyone recalls a 3314. I think the OP said it was a typo, 2314 mis-remembered as 3000-series DASD. >> >> Charles >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edward Gould >> Sent: Wednesday, May 18, 2016 5:33 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: What was a 3314? (was: Whither VIO) >> >> Chales, >> >> 2321 was a data cell (magnetic strip) hardly could be called DASD) I don’t recall a 3314 . The removable 3340 (not sure the number anyone?) >> >> Ed >> >>> On May 16, 2016, at 7:47 PM, Charles Mills wrote: >>> >>> >>> >>> 2301, 2321. >>> CharlesSent from a mobile; please excuse the brevity >>> >>> Original message >>> From: Steve Thompson >>> Date: 05/16/2016 4:51 PM (GMT-08:00) >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: What was a 3314? (was: Whither VIO) >>> >>> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've had >>> the pleasure of working with. I've forgotten the drum device numbers >>> and the noodle snatcher model number. >> >> -- >> 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 >Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
> On May 18, 2016, at 7:50 PM, Charles Mills wrote: > > I remember them well. I was answering Steve's two implied questions. > > 2321 was certainly characterized as DASD. It was indeed a direct access > storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape > (though it had a family resemblance!) and certainly not unit record. It addressing had MMBBCCHHR(R?) so I guess you could address it directly. Anyone remember how to do that? (progr5amming for a 2321 is a lost art (where is Seymour?). Ed > > I don't think anyone recalls a 3314. I think the OP said it was a typo, 2314 > mis-remembered as 3000-series DASD. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Edward Gould > Sent: Wednesday, May 18, 2016 5:33 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: What was a 3314? (was: Whither VIO) > > Chales, > > 2321 was a data cell (magnetic strip) hardly could be called DASD) I don’t > recall a 3314 . The removable 3340 (not sure the number anyone?) > > Ed > >> On May 16, 2016, at 7:47 PM, Charles Mills wrote: >> >> >> >> 2301, 2321. >> CharlesSent from a mobile; please excuse the brevity >> >> Original message >> From: Steve Thompson >> Date: 05/16/2016 4:51 PM (GMT-08:00) >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: What was a 3314? (was: Whither VIO) >> >> 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've had >> the pleasure of working with. I've forgotten the drum device numbers >> and the noodle snatcher model number. > > -- > 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: What was a 3314? (was: Whither VIO)
Well, the S/360-20 had TPS (Tape Processing System, not to be confused with Tape Operating System) which had a RESVOL that was a tape. And there were utilities to update the tape in place (not copy to another tape and then back, actual update blocks in place). From time to time one would have to make a new copy of the REsVOL to, kinda defrag it as I remember. By the time I got to TPS (Tape Processing System), IBM was no longer putting out maint. Or we just weren't getting any maint for it from IBM (1977-78 when I was working on that system). The Noodle snatcher had "data cells" which were segments that had x strips of tape hanging in them (where x is a number that I've forgotten). It was tape that could be randomly accessed, so it was a kind of DASD. It had a very interesting instruction. RFWBS, Read Forward, Write Backward with Shredding. Yep, catch that mylar strip (aka, noodle) on the edge of the slot and it would peal/slice it in two. That could wreck you whole day. And if you had just had maintenance done, and one of the segments was not correctly fastened in place, when that sucker would rotate, it would fling that segment right through the "glass" and well, things just got exciting for a bit. Makes one very glad to have things like thumb drives that we have today. Now if I could just get one big enough to IPL z/OS... Regards, Steve Thompson On 05/18/2016 09:07 PM, Paul Gilmartin wrote: On Wed, 18 May 2016 17:50:53 -0700, Charles Mills wrote: ... It was indeed a direct access storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape (though it had a family resemblance!) and certainly not unit record. What's the criterion? Max/Min latency ratio? Statistical distribution of latency between randomly selected records? For tape, it's sort of triangular; for DASD it has a sort of plateau. Addressable by block and writable randomly without corrupting other blocks? DECtape had preformatted addressable blocks; it held a filesystem with a directory. It moved from reel to reel past a stationary R/W head. It met some criteria for DASD and some for tape; it was both. -- gil -- 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: What was a 3314? (was: Whither VIO)
On Wed, 18 May 2016 17:50:53 -0700, Charles Mills wrote: > ... It was indeed a direct access storage device. Not a disk, but DASD > nonetheless. Certainly not magnetic tape (though it had a family > resemblance!) and certainly not unit record. > What's the criterion? Max/Min latency ratio? Statistical distribution of latency between randomly selected records? For tape, it's sort of triangular; for DASD it has a sort of plateau. Addressable by block and writable randomly without corrupting other blocks? DECtape had preformatted addressable blocks; it held a filesystem with a directory. It moved from reel to reel past a stationary R/W head. It met some criteria for DASD and some for tape; it was both. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
I remember them well. I was answering Steve's two implied questions. 2321 was certainly characterized as DASD. It was indeed a direct access storage device. Not a disk, but DASD nonetheless. Certainly not magnetic tape (though it had a family resemblance!) and certainly not unit record. I don't think anyone recalls a 3314. I think the OP said it was a typo, 2314 mis-remembered as 3000-series DASD. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Edward Gould Sent: Wednesday, May 18, 2016 5:33 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) Chales, 2321 was a data cell (magnetic strip) hardly could be called DASD) I don’t recall a 3314 . The removable 3340 (not sure the number anyone?) Ed > On May 16, 2016, at 7:47 PM, Charles Mills wrote: > > > > 2301, 2321. > CharlesSent from a mobile; please excuse the brevity > > Original message > From: Steve Thompson > Date: 05/16/2016 4:51 PM (GMT-08:00) > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: What was a 3314? (was: Whither VIO) > > 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've had > the pleasure of working with. I've forgotten the drum device numbers > and the noodle snatcher model number. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
Chales, 2321 was a data cell (magnetic strip) hardly could be called DASD) I don’t recall a 3314 . The removable 3340 (not sure the number anyone?) Ed > On May 16, 2016, at 7:47 PM, Charles Mills wrote: > > > > 2301, 2321. > CharlesSent from a mobile; please excuse the brevity > > Original message > From: Steve Thompson > Date: 05/16/2016 4:51 PM (GMT-08:00) > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: What was a 3314? (was: Whither VIO) > > 2314, 2419, 2311, these are just a few of the "IBM" DASD that > I've had the pleasure of working with. I've forgotten the drum > device numbers and the noodle snatcher model number. > > Regards, > Steve Thompson > > On 05/16/2016 07:24 PM, Jesse 1 Robinson wrote: >> OK, the sleeping dog wants some attention. Before my first reply, I >> carefully Googled device type 2314 to verify the number. Then I typed '3314' >> because who has ever worked with DASD that started with something other than >> '33'? 2314 remained valid in the IODEVICE macro long, long after the final >> one disappeared into the sunset. And as I said, I was advised to use it for >> VIO because of 'device architecture', whatever that meant. Track size, I >> guess, from what others have posted. >> >> . >> . >> . >> J.O.Skip Robinson >> Southern California Edison Company >> Electric Dragon Team Paddler >> SHARE MVS Program Co-Manager >> 323-715-0595 Mobile >> 626-302-7535 Office >> robin...@sce.com >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Clark Morris >> Sent: Monday, May 16, 2016 4:16 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: (External):Re: What was a 3314? (was: Whither VIO) >> >> [Default] On 16 May 2016 07:01:50 -0700, in bit.listserv.ibm-main >> jcal...@narsil.org (Jerry Callen) wrote: >> >>> In the "Whither VIO" thread, J.O.Skip Robinson wrote: >>> >>>>In a previous life, we defined VIO (I believe) to device 3314 even >>>> though we had none left on the floor >>> >>> That's a device type I've never heard of, and the Google knows not of. >>> Could this be a typo for "2314"? >> >> I believe the OP meant 2314 which had 7294 bytes per track. It was a >> removable disk. >> >> Clark Morris >>> >>> -- Jerry >> >> -- >> 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 > > > -- > 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: What was a 3314? (was: Whither VIO)
Lots of OEM's changed 1st digit but kept geometry.CDC, Memorex, Telex, Amdahl, StoraeTek. In a message dated 5/16/2016 6:40:33 P.M. Central Daylight Time, charl...@mcn.org writes: You are going to get some replies on that! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
The real odd balls, 3340, 3344, 3370 & 3375's :-) 3340's had the coolest looking removable disk assembly. I suspected that the 3344 was a code-hacked 3350, it just carved 4 70Mb disks out of the larger physical disk. Len Rugen University of Missouri Division of Information Technology Systems & Operations - Metrics & Automation Team From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Steve Thompson [ste...@copper.net] Sent: Monday, May 16, 2016 6:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've had the pleasure of working with. I've forgotten the drum device numbers and the noodle snatcher model number. Regards, Steve Thompson On 05/16/2016 07:24 PM, Jesse 1 Robinson wrote: > OK, the sleeping dog wants some attention. Before my first reply, I carefully > Googled device type 2314 to verify the number. Then I typed '3314' because > who has ever worked with DASD that started with something other than '33'? > 2314 remained valid in the IODEVICE macro long, long after the final one > disappeared into the sunset. And as I said, I was advised to use it for VIO > because of 'device architecture', whatever that meant. Track size, I guess, > from what others have posted. > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-302-7535 Office > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Clark Morris > Sent: Monday, May 16, 2016 4:16 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: What was a 3314? (was: Whither VIO) > > [Default] On 16 May 2016 07:01:50 -0700, in bit.listserv.ibm-main > jcal...@narsil.org (Jerry Callen) wrote: > >> In the "Whither VIO" thread, J.O.Skip Robinson wrote: >> >>> In a previous life, we defined VIO (I believe) to device 3314 even >>> though we had none left on the floor >> >> That's a device type I've never heard of, and the Google knows not of. Could >> this be a typo for "2314"? > > I believe the OP meant 2314 which had 7294 bytes per track. It was a > removable disk. > > Clark Morris >> >> -- Jerry > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
2301, 2321. CharlesSent from a mobile; please excuse the brevity Original message From: Steve Thompson Date: 05/16/2016 4:51 PM (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) 2314, 2419, 2311, these are just a few of the "IBM" DASD that I've had the pleasure of working with. I've forgotten the drum device numbers and the noodle snatcher model number. Regards, Steve Thompson On 05/16/2016 07:24 PM, Jesse 1 Robinson wrote: > OK, the sleeping dog wants some attention. Before my first reply, I carefully > Googled device type 2314 to verify the number. Then I typed '3314' because > who has ever worked with DASD that started with something other than '33'? > 2314 remained valid in the IODEVICE macro long, long after the final one > disappeared into the sunset. And as I said, I was advised to use it for VIO > because of 'device architecture', whatever that meant. Track size, I guess, > from what others have posted. > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-302-7535 Office > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Clark Morris > Sent: Monday, May 16, 2016 4:16 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: What was a 3314? (was: Whither VIO) > > [Default] On 16 May 2016 07:01:50 -0700, in bit.listserv.ibm-main > jcal...@narsil.org (Jerry Callen) wrote: > >> In the "Whither VIO" thread, J.O.Skip Robinson wrote: >> >>> In a previous life, we defined VIO (I believe) to device 3314 even >>> though we had none left on the floor >> >> That's a device type I've never heard of, and the Google knows not of. Could >> this be a typo for "2314"? > > I believe the OP meant 2314 which had 7294 bytes per track. It was a > removable disk. > > Clark Morris >> >> -- Jerry > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
2314, 2419, 2311, these are just a few of the "IBM" DASD that I've had the pleasure of working with. I've forgotten the drum device numbers and the noodle snatcher model number. Regards, Steve Thompson On 05/16/2016 07:24 PM, Jesse 1 Robinson wrote: OK, the sleeping dog wants some attention. Before my first reply, I carefully Googled device type 2314 to verify the number. Then I typed '3314' because who has ever worked with DASD that started with something other than '33'? 2314 remained valid in the IODEVICE macro long, long after the final one disappeared into the sunset. And as I said, I was advised to use it for VIO because of 'device architecture', whatever that meant. Track size, I guess, from what others have posted. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris Sent: Monday, May 16, 2016 4:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: What was a 3314? (was: Whither VIO) [Default] On 16 May 2016 07:01:50 -0700, in bit.listserv.ibm-main jcal...@narsil.org (Jerry Callen) wrote: In the "Whither VIO" thread, J.O.Skip Robinson wrote: In a previous life, we defined VIO (I believe) to device 3314 even though we had none left on the floor That's a device type I've never heard of, and the Google knows not of. Could this be a typo for "2314"? I believe the OP meant 2314 which had 7294 bytes per track. It was a removable disk. Clark Morris -- Jerry -- 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: What was a 3314? (was: Whither VIO)
> who has ever worked with DASD that started with something other than '33'? You are going to get some replies on that! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Monday, May 16, 2016 4:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What was a 3314? (was: Whither VIO) OK, the sleeping dog wants some attention. Before my first reply, I carefully Googled device type 2314 to verify the number. Then I typed '3314' because who has ever worked with DASD that started with something other than '33'? 2314 remained valid in the IODEVICE macro long, long after the final one disappeared into the sunset. And as I said, I was advised to use it for VIO because of 'device architecture', whatever that meant. Track size, I guess, from what others have posted. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
OK, the sleeping dog wants some attention. Before my first reply, I carefully Googled device type 2314 to verify the number. Then I typed '3314' because who has ever worked with DASD that started with something other than '33'? 2314 remained valid in the IODEVICE macro long, long after the final one disappeared into the sunset. And as I said, I was advised to use it for VIO because of 'device architecture', whatever that meant. Track size, I guess, from what others have posted. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris Sent: Monday, May 16, 2016 4:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: What was a 3314? (was: Whither VIO) [Default] On 16 May 2016 07:01:50 -0700, in bit.listserv.ibm-main jcal...@narsil.org (Jerry Callen) wrote: >In the "Whither VIO" thread, J.O.Skip Robinson wrote: > >> In a previous life, we defined VIO (I believe) to device 3314 even >> though we had none left on the floor > >That's a device type I've never heard of, and the Google knows not of. Could >this be a typo for "2314"? I believe the OP meant 2314 which had 7294 bytes per track. It was a removable disk. Clark Morris > >-- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
[Default] On 16 May 2016 07:01:50 -0700, in bit.listserv.ibm-main jcal...@narsil.org (Jerry Callen) wrote: >In the "Whither VIO" thread, J.O.Skip Robinson wrote: > >> In a previous life, we defined VIO (I believe) to device 3314 even though >> we had none left on the floor > >That's a device type I've never heard of, and the Google knows not of. Could >this be a typo for "2314"? I believe the OP meant 2314 which had 7294 bytes per track. It was a removable disk. Clark Morris > >-- Jerry > >-- >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: What was a 3314? (was: Whither VIO)
On Mon, May 16, 2016 at 9:09 AM, R.S. wrote: > W dniu 2016-05-16 o 16:01, Jerry Callen pisze: > >> In the "Whither VIO" thread, J.O.Skip Robinson wrote: >> >> In a previous life, we defined VIO (I believe) to device 3314 even >>> though we had none left on the floor >>> >> That's a device type I've never heard of, and the Google knows not of. >> Could this be a typo for "2314"? >> > IMHO anything older than 3380 is prehistory or a myth ;-) > Hum, I had a 1316 disk volume (dismountable like ) when I was in college. It was used in the 1311 disk storage unit, attached to a 1620 computer. I loved that machine. A kind of "personal computer" for running FORTRAN II programs. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > --- > Treść tej wiadomości może zawierać informacje prawnie chronione Banku > przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być > jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś > adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej > przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, > rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie > zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, > prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale > usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub > zapisane na dysku. > > This e-mail may contain legally privileged information of the Bank and is > intended solely for business use of the addressee. This e-mail may only be > received by the addressee and may not be disclosed to any third parties. If > you are not the intended addressee of this e-mail or the employee > authorized to forward it to the addressee, be advised that any > dissemination, copying, distribution or any other similar activity is > legally prohibited and may be punishable. If you received this e-mail by > mistake please advise the sender immediately by using the reply facility in > your e-mail software and delete permanently this e-mail including any > copies of it either printed or saved to hard drive. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > www.mBank.pl, e-mail: kont...@mbank.pl > Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego > Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: > 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku > S.A. (w całości wpłacony) wynosi 168.955.696 złotych. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- The unfacts, did we have them, are too imprecisely few to warrant our certitude. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What was a 3314? (was: Whither VIO)
W dniu 2016-05-16 o 16:01, Jerry Callen pisze: In the "Whither VIO" thread, J.O.Skip Robinson wrote: In a previous life, we defined VIO (I believe) to device 3314 even though we had none left on the floor That's a device type I've never heard of, and the Google knows not of. Could this be a typo for "2314"? IMHO anything older than 3380 is prehistory or a myth ;-) -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
What was a 3314? (was: Whither VIO)
In the "Whither VIO" thread, J.O.Skip Robinson wrote: > In a previous life, we defined VIO (I believe) to device 3314 even though we > had none left on the floor That's a device type I've never heard of, and the Google knows not of. Could this be a typo for "2314"? -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Whither VIO?
>[snip] Expanded storage is one of those things that, for a combination of >technical and marketing reasons, had its day in the sun and has gone, while >VIO continues. It's back, just called "Flash Express" these days. It's used for paging, and for some other things (or things to come) just as Expanded Storage was. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Whither VIO?
It's a simulated device and I guess 3314 is tiny. I vaguely recall - from more than 25 years ago - wanting to use a tiny one. I think it might be a limit on something - VIO data sets not being multivolume? (I think this simulation is a significant part of the CPU cost for VIO.) Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Cloud & Systems Performance, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/category/mpt/ From: Jesse 1 Robinson To: IBM-MAIN@LISTSERV.UA.EDU Date: 11/05/2016 17:05 Subject: Re: Whither VIO? Sent by:IBM Mainframe Discussion List Mea culpa once again for misstating the facts. My shop does indeed still support VIO--under a different esoteric--but, as Ed Jaffe pointed out, with a pretty severe size limit. I looked through one PROCLIB for instances of VIO. I found it mostly in compile/link jobs with very small work files. As for DFSORT, our default ICEMAC includes VIO=YES, but I have no idea who would use it. In view of our low limit for VIO, I doubt that many SORTWK files would actually end up there. One question I have. In a previous life, we defined VIO (I believe) to device 3314 even though we had none left on the floor. The device type was still valid in IOGEN at that time, and I was told that device architecture was more suitable for VIO than 3380. VIO here is currently defined to 3390. Is there any difference? . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Betten Sent: Wednesday, May 11, 2016 8:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Whither VIO? When I was in DFSORT, I always recommended not using VIO for sort work data sets. We felt it was better to let DFSORT manage the use of storage for intermediate work space via Hiperspace, Memory Object or Dataspace. One advantage was that DFSORT has controls over the total memory usage by concurrent sort applications. I believe VIO is still something worth exploiting for other types of temporary data sets given the larger storage configurations available today. However, keep in mind that there are also some limitations to VIO such as not supporting large format data sets. Have a nice day, Dave Betten z/OS Performance Specialist Cloud and Systems Performance IBM Corporation email: bet...@us.ibm.com IBM Mainframe Discussion List wrote on 05/11/2016 11:10:55 AM: > From: Martin Packer > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 05/11/2016 11:12 AM > Subject: Re: Whither VIO? > Sent by: IBM Mainframe Discussion List > > I said in another thread that VIO was one of the worse DIM exploiters > for > CPU usage - in the Orange "Coffee Table" book of DIM studies way back > when. > > I've no reason to doubt it now. I would still expect that for many > uses it > is faster than temporary data sets on disk, though. > > So I would question what we're optimising for. > > And I would agree that a rival implementation - such as hiperspace or > 64-Bit Memory Object sorting - is worth investigating. > > Cheers, Martin > > Martin Packer, > zChampion, Principal Systems Investigator, Worldwide Cloud & Systems > Performance, IBM > > +44-7802-245-584 > > email: martin_pac...@uk.ibm.com > > Twitter / Facebook IDs: MartinPacker > > Blog: > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker > > Podcast Series (With Marna Walle): > https://developer.ibm.com/tv/category/mpt/ > > > > From: "Vernooij, CP (ITOPT1) - KLM" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/05/2016 15:32 > Subject:Re: Whither VIO? > Sent by:IBM Mainframe Discussion List > > > > I heard rumors that VIO is that CPU expensive and that I/O is that > fast nowadays, that it is VIO is not worth the extra CPU anymore. > > Therefor I have been thinking about abandoning VIO, but I can't make a > good calculation. I could make the calculation for the SAS WORK file, > which can be in VIO or in HIPERSPACE. The latter is cheaper, as is > stated > by SAS and it is easy to switch to Hiperspace with a simple > installation parameter. > > Does anyone has some figures on other use of VIO? > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Martin Packer > Sent: 11 May, 2016 16:08 > To: IBM-MAI
Re: Whither VIO?
On Wed, 11 May 2016 13:09:45 -0400, Tony Harminc wrote: > >The biggest reason to use VIO rather than the various alternatives >mentioned is that it is compatible. An existing application need know >nothing about it, and can be offered improved performance with no code >changes. In these days of large memory it may seem quaint, but it has >its place. > Compatible. I recall a time when IEBCOPY couldn't deal with VIO because IEBCOPY used EXCP V=R, but VIO relying on paging could accept only virtual addresses. (Surprisingly?) this was addressed in VIO (by a sort of reverse LRA/DAT?) rather than modifying IEBCOPY. I wonder what the cost, and whether nowadays IEBCOPY eschews EXCP V=R so it may run with AC=0. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Whither VIO?
On 11 May 2016 at 10:07, Martin Packer wrote: > The nasty answer to "what happened to VIO?" is "nothing". :-) :-( > > Seriously, it remains as before but implemented in central storage rather > than expanded. VIO long predates the existence of expanded storage. It was original with MVS (2.0 in iirc 1972), and at the time there was nowhere for it to go but the paging system. Expanded storage is one of those things that, for a combination of technical and marketing reasons, had its day in the sun and has gone, while VIO continues. The biggest reason to use VIO rather than the various alternatives mentioned is that it is compatible. An existing application need know nothing about it, and can be offered improved performance with no code changes. In these days of large memory it may seem quaint, but it has its place. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Whither VIO?
On 11 May 2016 at 12:05, Jesse 1 Robinson wrote: > One question I have. In a previous life, we defined VIO (I believe) to device > 3314 even though we had none left on the floor. The device type was still > valid in IOGEN at that time, and I was told that device architecture was more > suitable for VIO than 3380. VIO here is currently defined to 3390. Is there > any difference? I'm not sure about the device architecture, but the traditional reason for choosing a particular and perhaps obsolete device type for VIO was to limit the space available. This was before SMS or any other controls, and if you set up 3350 or 3380 as VIO device types, an application could easily allocate and try to fill up the entire virtual disk, with potentially disastrous results for the paging system. One trick was to specify the VIO device as 2305 (the old fixed-head disk, sometimes incorrectly called a "drum"), which was very small - 5 or 10 MB, depending on the model. The 2314 was next on the list - much bigger, but still only 30 MB or so. The 2311 or 2301 might have been an even better bet, but neither was ever supported on MVS. It may be that the "device architecture" is referring to the number of 4K pages needed to hold a track image for the device in question, with how much wastage. It's kind of the opposite calculation to what makes a good paging device, i.e. how many pages fit on a track with how much left over. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Whither VIO?
I remember hearing in MVS Measurement & Tuning class way back, choosing an older geometry such as 3330 or 3350 track size was preferred for VIO so as to use a smaller window for VIO to minimize precious central storage usage, as compared to the honkin' 3380 track size of 47kb. Technology marches on! Dana On Wed, 11 May 2016 16:05:13 +, Jesse 1 Robinson wrote: > >One question I have. In a previous life, we defined VIO (I believe) to device >3314 even though we had none left on the floor. The device type was still >valid in IOGEN at that time, and I was told that device architecture was more >suitable for VIO than 3380. VIO here is currently defined to 3390. Is there >any difference? > >. >. >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >626-302-7535 Office >robin...@sce.com > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of David Betten >Sent: Wednesday, May 11, 2016 8:41 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: Whither VIO? > >When I was in DFSORT, I always recommended not using VIO for sort work data >sets. We felt it was better to let DFSORT manage the use of storage for >intermediate work space via Hiperspace, Memory Object or Dataspace. One >advantage was that DFSORT has controls over the total memory usage by >concurrent sort applications. > >I believe VIO is still something worth exploiting for other types of temporary >data sets given the larger storage configurations available today. However, >keep in mind that there are also some limitations to VIO such as not >supporting large format data sets. > > >Have a nice day, >Dave Betten >z/OS Performance Specialist >Cloud and Systems Performance >IBM Corporation >email: bet...@us.ibm.com > > >IBM Mainframe Discussion List wrote on >05/11/2016 11:10:55 AM: > >> From: Martin Packer >> To: IBM-MAIN@LISTSERV.UA.EDU >> Date: 05/11/2016 11:12 AM >> Subject: Re: Whither VIO? >> Sent by: IBM Mainframe Discussion List >> >> I said in another thread that VIO was one of the worse DIM exploiters >> for > >> CPU usage - in the Orange "Coffee Table" book of DIM studies way back >> when. >> >> I've no reason to doubt it now. I would still expect that for many >> uses >it >> is faster than temporary data sets on disk, though. >> >> So I would question what we're optimising for. >> >> And I would agree that a rival implementation - such as hiperspace or >> 64-Bit Memory Object sorting - is worth investigating. >> >> Cheers, Martin >> >> Martin Packer, >> zChampion, Principal Systems Investigator, Worldwide Cloud & Systems >> Performance, IBM >> >> +44-7802-245-584 >> >> email: martin_pac...@uk.ibm.com >> >> Twitter / Facebook IDs: MartinPacker >> >> Blog: >> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker >> >> Podcast Series (With Marna Walle): >> https://developer.ibm.com/tv/category/mpt/ >> >> >> >> From: "Vernooij, CP (ITOPT1) - KLM" >> To: IBM-MAIN@LISTSERV.UA.EDU >> Date: 11/05/2016 15:32 >> Subject:Re: Whither VIO? >> Sent by:IBM Mainframe Discussion List >> >> >> >> I heard rumors that VIO is that CPU expensive and that I/O is that >> fast nowadays, that it is VIO is not worth the extra CPU anymore. >> >> Therefor I have been thinking about abandoning VIO, but I can't make a >> good calculation. I could make the calculation for the SAS WORK file, >> which can be in VIO or in HIPERSPACE. The latter is cheaper, as is >> stated > >> by SAS and it is easy to switch to Hiperspace with a simple >> installation parameter. >> >> Does anyone has some figures on other use of VIO? >> >> Kees. >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Martin Packer >> Sent: 11 May, 2016 16:08 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Whither VIO? >> >> The nasty answer to "what happened to VIO?" is "nothing". :-) :-( >> >> Seriously, it remains as before but implemented in central storage >> rather > >> than expanded. >> >> With the improved economics of memory it's worth looking at again - >> but only if memory is available to support it. >> >> Che
Re: Whither VIO?
Mea culpa once again for misstating the facts. My shop does indeed still support VIO--under a different esoteric--but, as Ed Jaffe pointed out, with a pretty severe size limit. I looked through one PROCLIB for instances of VIO. I found it mostly in compile/link jobs with very small work files. As for DFSORT, our default ICEMAC includes VIO=YES, but I have no idea who would use it. In view of our low limit for VIO, I doubt that many SORTWK files would actually end up there. One question I have. In a previous life, we defined VIO (I believe) to device 3314 even though we had none left on the floor. The device type was still valid in IOGEN at that time, and I was told that device architecture was more suitable for VIO than 3380. VIO here is currently defined to 3390. Is there any difference? . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Betten Sent: Wednesday, May 11, 2016 8:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Whither VIO? When I was in DFSORT, I always recommended not using VIO for sort work data sets. We felt it was better to let DFSORT manage the use of storage for intermediate work space via Hiperspace, Memory Object or Dataspace. One advantage was that DFSORT has controls over the total memory usage by concurrent sort applications. I believe VIO is still something worth exploiting for other types of temporary data sets given the larger storage configurations available today. However, keep in mind that there are also some limitations to VIO such as not supporting large format data sets. Have a nice day, Dave Betten z/OS Performance Specialist Cloud and Systems Performance IBM Corporation email: bet...@us.ibm.com IBM Mainframe Discussion List wrote on 05/11/2016 11:10:55 AM: > From: Martin Packer > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 05/11/2016 11:12 AM > Subject: Re: Whither VIO? > Sent by: IBM Mainframe Discussion List > > I said in another thread that VIO was one of the worse DIM exploiters > for > CPU usage - in the Orange "Coffee Table" book of DIM studies way back > when. > > I've no reason to doubt it now. I would still expect that for many > uses it > is faster than temporary data sets on disk, though. > > So I would question what we're optimising for. > > And I would agree that a rival implementation - such as hiperspace or > 64-Bit Memory Object sorting - is worth investigating. > > Cheers, Martin > > Martin Packer, > zChampion, Principal Systems Investigator, Worldwide Cloud & Systems > Performance, IBM > > +44-7802-245-584 > > email: martin_pac...@uk.ibm.com > > Twitter / Facebook IDs: MartinPacker > > Blog: > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker > > Podcast Series (With Marna Walle): > https://developer.ibm.com/tv/category/mpt/ > > > > From: "Vernooij, CP (ITOPT1) - KLM" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/05/2016 15:32 > Subject:Re: Whither VIO? > Sent by:IBM Mainframe Discussion List > > > > I heard rumors that VIO is that CPU expensive and that I/O is that > fast nowadays, that it is VIO is not worth the extra CPU anymore. > > Therefor I have been thinking about abandoning VIO, but I can't make a > good calculation. I could make the calculation for the SAS WORK file, > which can be in VIO or in HIPERSPACE. The latter is cheaper, as is > stated > by SAS and it is easy to switch to Hiperspace with a simple > installation parameter. > > Does anyone has some figures on other use of VIO? > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Martin Packer > Sent: 11 May, 2016 16:08 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Whither VIO? > > The nasty answer to "what happened to VIO?" is "nothing". :-) :-( > > Seriously, it remains as before but implemented in central storage > rather > than expanded. > > With the improved economics of memory it's worth looking at again - > but only if memory is available to support it. > > Cheers, Martin > > Martin Packer, > zChampion, Principal Systems Investigator, Worldwide Cloud & Systems > Performance, IBM > > +44-7802-245-584 > > email: martin_pac...@uk.ibm.com > > Twitter / Facebook IDs: MartinPacker > > Blog: > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker > > Podcast Series (With Marna Walle): > https://developer.ibm.com/tv
Re: Whither VIO?
When I was in DFSORT, I always recommended not using VIO for sort work data sets. We felt it was better to let DFSORT manage the use of storage for intermediate work space via Hiperspace, Memory Object or Dataspace. One advantage was that DFSORT has controls over the total memory usage by concurrent sort applications. I believe VIO is still something worth exploiting for other types of temporary data sets given the larger storage configurations available today. However, keep in mind that there are also some limitations to VIO such as not supporting large format data sets. Have a nice day, Dave Betten z/OS Performance Specialist Cloud and Systems Performance IBM Corporation email: bet...@us.ibm.com IBM Mainframe Discussion List wrote on 05/11/2016 11:10:55 AM: > From: Martin Packer > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 05/11/2016 11:12 AM > Subject: Re: Whither VIO? > Sent by: IBM Mainframe Discussion List > > I said in another thread that VIO was one of the worse DIM exploiters for > CPU usage - in the Orange "Coffee Table" book of DIM studies way back > when. > > I've no reason to doubt it now. I would still expect that for many uses it > is faster than temporary data sets on disk, though. > > So I would question what we're optimising for. > > And I would agree that a rival implementation - such as hiperspace or > 64-Bit Memory Object sorting - is worth investigating. > > Cheers, Martin > > Martin Packer, > zChampion, Principal Systems Investigator, > Worldwide Cloud & Systems Performance, IBM > > +44-7802-245-584 > > email: martin_pac...@uk.ibm.com > > Twitter / Facebook IDs: MartinPacker > > Blog: > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker > > Podcast Series (With Marna Walle): > https://developer.ibm.com/tv/category/mpt/ > > > > From: "Vernooij, CP (ITOPT1) - KLM" > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/05/2016 15:32 > Subject:Re: Whither VIO? > Sent by:IBM Mainframe Discussion List > > > > I heard rumors that VIO is that CPU expensive and that I/O is that fast > nowadays, that it is VIO is not worth the extra CPU anymore. > > Therefor I have been thinking about abandoning VIO, but I can't make a > good calculation. I could make the calculation for the SAS WORK file, > which can be in VIO or in HIPERSPACE. The latter is cheaper, as is stated > by SAS and it is easy to switch to Hiperspace with a simple installation > parameter. > > Does anyone has some figures on other use of VIO? > > Kees. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Martin Packer > Sent: 11 May, 2016 16:08 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Whither VIO? > > The nasty answer to "what happened to VIO?" is "nothing". :-) :-( > > Seriously, it remains as before but implemented in central storage rather > than expanded. > > With the improved economics of memory it's worth looking at again - but > only if memory is available to support it. > > Cheers, Martin > > Martin Packer, > zChampion, Principal Systems Investigator, > Worldwide Cloud & Systems Performance, IBM > > +44-7802-245-584 > > email: martin_pac...@uk.ibm.com > > Twitter / Facebook IDs: MartinPacker > > Blog: > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker > > Podcast Series (With Marna Walle): > https://developer.ibm.com/tv/category/mpt/ > > > > From: Lizette Koehler > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 11/05/2016 14:55 > Subject:Re: Whither VIO? > Sent by:IBM Mainframe Discussion List > > > > My guess would be: > > DASD is faster > Virtual Tape is faster > Central Memory is plentiful (for some shops) > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Jerry Callen > > Sent: Wednesday, May 11, 2016 6:51 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Whither VIO? > > > > In a thread in a distant galaxy, J.O.Skip Robinson wrote: > > > > > ...be aware that some customers (like us) did away with VIO a long > time ago. > > > > I've been away from MVS for a while. Did something better than VIO come > along > > while I wasn't looking? Why would VIO have been vaporized? > > > > -- Jerry > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua
Re: Whither VIO?
I said in another thread that VIO was one of the worse DIM exploiters for CPU usage - in the Orange "Coffee Table" book of DIM studies way back when. I've no reason to doubt it now. I would still expect that for many uses it is faster than temporary data sets on disk, though. So I would question what we're optimising for. And I would agree that a rival implementation - such as hiperspace or 64-Bit Memory Object sorting - is worth investigating. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Cloud & Systems Performance, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/category/mpt/ From: "Vernooij, CP (ITOPT1) - KLM" To: IBM-MAIN@LISTSERV.UA.EDU Date: 11/05/2016 15:32 Subject:Re: Whither VIO? Sent by:IBM Mainframe Discussion List I heard rumors that VIO is that CPU expensive and that I/O is that fast nowadays, that it is VIO is not worth the extra CPU anymore. Therefor I have been thinking about abandoning VIO, but I can't make a good calculation. I could make the calculation for the SAS WORK file, which can be in VIO or in HIPERSPACE. The latter is cheaper, as is stated by SAS and it is easy to switch to Hiperspace with a simple installation parameter. Does anyone has some figures on other use of VIO? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: 11 May, 2016 16:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Whither VIO? The nasty answer to "what happened to VIO?" is "nothing". :-) :-( Seriously, it remains as before but implemented in central storage rather than expanded. With the improved economics of memory it's worth looking at again - but only if memory is available to support it. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Cloud & Systems Performance, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/category/mpt/ From: Lizette Koehler To: IBM-MAIN@LISTSERV.UA.EDU Date: 11/05/2016 14:55 Subject:Re: Whither VIO? Sent by:IBM Mainframe Discussion List My guess would be: DASD is faster Virtual Tape is faster Central Memory is plentiful (for some shops) Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jerry Callen > Sent: Wednesday, May 11, 2016 6:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Whither VIO? > > In a thread in a distant galaxy, J.O.Skip Robinson wrote: > > > ...be aware that some customers (like us) did away with VIO a long time ago. > > I've been away from MVS for a while. Did something better than VIO come along > while I wasn't looking? Why would VIO have been vaporized? > > -- Jerry > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286
Re: Whither VIO?
On 5/11/2016 7:31 AM, Vernooij, CP (ITOPT1) - KLM wrote: I heard rumors that VIO is that CPU expensive and that I/O is that fast nowadays, that it is VIO is not worth the extra CPU anymore. We use VIO for (nearly) ALL temporary data sets. (VIO MAXSIZE is set to the highest supported value of 2G.) I haven't tried to compare VIO against DASD from a performance standpoint -- probably because we never noticed any issues with VIO. For us it's a matter of convenience to have numerous, fairly large "DASD" work data sets that never, Ever, EVER experience VTOC data set naming conflicts or need scratching after a system failure. Another benefit to us is the ability to have a virtual 3380 device for testing code intended to be "DASD-geometry-agnostic" but might not be. We recently uncovered an error with IBM's stand-alone ADRDSSU because we used a temporary 3380 device in the SABLD job. The error is not specific to 3380, it just happens to be reproducible right now on 3380 given the current module sizes. If the error is not fixed, the same problem could occur on 3390 if some PTF changes the sizes of the load modules just right... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Whither VIO?
I heard rumors that VIO is that CPU expensive and that I/O is that fast nowadays, that it is VIO is not worth the extra CPU anymore. Therefor I have been thinking about abandoning VIO, but I can't make a good calculation. I could make the calculation for the SAS WORK file, which can be in VIO or in HIPERSPACE. The latter is cheaper, as is stated by SAS and it is easy to switch to Hiperspace with a simple installation parameter. Does anyone has some figures on other use of VIO? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Martin Packer Sent: 11 May, 2016 16:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Whither VIO? The nasty answer to "what happened to VIO?" is "nothing". :-) :-( Seriously, it remains as before but implemented in central storage rather than expanded. With the improved economics of memory it's worth looking at again - but only if memory is available to support it. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Cloud & Systems Performance, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/category/mpt/ From: Lizette Koehler To: IBM-MAIN@LISTSERV.UA.EDU Date: 11/05/2016 14:55 Subject:Re: Whither VIO? Sent by:IBM Mainframe Discussion List My guess would be: DASD is faster Virtual Tape is faster Central Memory is plentiful (for some shops) Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jerry Callen > Sent: Wednesday, May 11, 2016 6:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Whither VIO? > > In a thread in a distant galaxy, J.O.Skip Robinson wrote: > > > ...be aware that some customers (like us) did away with VIO a long time ago. > > I've been away from MVS for a while. Did something better than VIO come along > while I wasn't looking? Why would VIO have been vaporized? > > -- Jerry > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Whither VIO?
The nasty answer to "what happened to VIO?" is "nothing". :-) :-( Seriously, it remains as before but implemented in central storage rather than expanded. With the improved economics of memory it's worth looking at again - but only if memory is available to support it. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Cloud & Systems Performance, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/category/mpt/ From: Lizette Koehler To: IBM-MAIN@LISTSERV.UA.EDU Date: 11/05/2016 14:55 Subject:Re: Whither VIO? Sent by:IBM Mainframe Discussion List My guess would be: DASD is faster Virtual Tape is faster Central Memory is plentiful (for some shops) Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jerry Callen > Sent: Wednesday, May 11, 2016 6:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Whither VIO? > > In a thread in a distant galaxy, J.O.Skip Robinson wrote: > > > ...be aware that some customers (like us) did away with VIO a long time ago. > > I've been away from MVS for a while. Did something better than VIO come along > while I wasn't looking? Why would VIO have been vaporized? > > -- Jerry > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Whither VIO?
My guess would be: DASD is faster Virtual Tape is faster Central Memory is plentiful (for some shops) Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jerry Callen > Sent: Wednesday, May 11, 2016 6:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Whither VIO? > > In a thread in a distant galaxy, J.O.Skip Robinson wrote: > > > ...be aware that some customers (like us) did away with VIO a long time ago. > > I've been away from MVS for a while. Did something better than VIO come along > while I wasn't looking? Why would VIO have been vaporized? > > -- Jerry > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Whither VIO?
In a thread in a distant galaxy, J.O.Skip Robinson wrote: > ...be aware that some customers (like us) did away with VIO a long time ago. I've been away from MVS for a while. Did something better than VIO come along while I wasn't looking? Why would VIO have been vaporized? -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
