Re: Auxiliary Storage Management I/O in a RAID array world
Jim, Thanks for correcting me. I worked on an ESP 3090-200 in Australia and I was certain that VIO was in ES then, but obviously that's the memory I have with no error correction. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Jim Mulder > Sent: Wednesday, May 05, 2010 9:59 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] Auxiliary Storage Management I/O in a RAID array world > > IBM Mainframe Discussion List wrote on 05/05/2010 > 11:16:18 PM: > > > As far as VIO goes, it started outperforming standard disk from the day > the > > first 3090-200 shipped with expanded storage. With ES the VIO track > window > > was no longer written and discarded from storage when it was no used, > but > > was copied to from CS to ES. This meant that VIO stopped causing major > page > > thrashing, and the performance became incredibly good. Although ES is no > > longer supported, IBM continue to keep VIO in CS as part of the working > set. > > It was a few days later than that. SP2.1.3 (first release to support > 3090 and ESTOR) did not have VIO to ESTOR. That came a few years > via SPE: > > Apar: OY08837 Ext. Symptom: NF Symptom Keyword: FUNCTION > Abstract: SUPPORT THE USE OF EXPANDED STORAGE FOR VIO PAGES > > RB20 PSY UY90242 UP88/07/05 P F806 > RC10 PSY UY90243 UP88/07/05 P F806 > > > Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to analyze a volume's access by dataset
I could probably dig out my old "speeds and feeds" documents (actually little laminated cards we gave out to customers and prospects) that listed the NVS size options of, as I recall, 4M, 8M, 12M, and 16M and some other stuff. They are probably in the attic. I may have time to do this in the coming weeks before it gets too hot to forage in the attic. Maybe I will post a scan of one or more of them. T. J. Watson . . . yeah -- maybe five computers... I, for one, am glad he underestimated! Larry Chenevert - Original Message - From: "Bill Fairchild" Newsgroups: bit.listserv.ibm-main To: Sent: Wednesday, May 05, 2010 9:21 AM Subject: Re: How to analyze a volume's access by dataset I remember now about Amdahl's CSIM. Thanks for the lengthy post on it. Cache and NVS sizes were indeed vanishingly small in the 1980s compared to today's models. I remember attending a SHARE session, ca. 1989, in which an IBM cache control unit person from Tucson said that IBM had modeled vast amounts of traced user I/O requests and decided that 4M, or at most 8M, of NVS was all that anyone would ever need to support DASD fast writes. This reminds of me T. J. Watson's prediction in 1943 that "there is a world market for maybe five computers." lol Bill Fairchild Software Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 Email: bi...@mainstar.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Larry Chenevert Sent: Tuesday, May 04, 2010 7:45 PM To: IBM-MAIN@bama.ua.edu Subject: Re: How to analyze a volume's access by dataset For those who were not there at the time -- in the 80's, when cache and fast-write were first introduced, caches were tiny compared to current technology, and NVS sizes were even smaller -- much smaller. Memory for cache and NVS was quite expensive. Caching and fast-write were, for a short time, specified on a dataset by dataset basis. Many internal marketing tools have corners cut in development (well I guess some companies even cut corners on their products!) and have very rough user interfaces, but not CSIM, which had all the attributes, look and feel of a flagship product. It was not a product, but was a tool for internal people to use -- although it was probably left with some customers. I suppose this tool could have been used to model the performance of different cache algorithms but I doubt it was ever used in that mode. Larry Chenevert -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Auxiliary Storage Management I/O in a RAID array world
IBM Mainframe Discussion List wrote on 05/05/2010 11:16:18 PM: > As far as VIO goes, it started outperforming standard disk from the day the > first 3090-200 shipped with expanded storage. With ES the VIO track window > was no longer written and discarded from storage when it was no used, but > was copied to from CS to ES. This meant that VIO stopped causing major page > thrashing, and the performance became incredibly good. Although ES is no > longer supported, IBM continue to keep VIO in CS as part of the working set. It was a few days later than that. SP2.1.3 (first release to support 3090 and ESTOR) did not have VIO to ESTOR. That came a few years via SPE: Apar: OY08837 Ext. Symptom: NF Symptom Keyword: FUNCTION Abstract: SUPPORT THE USE OF EXPANDED STORAGE FOR VIO PAGES RB20 PSY UY90242 UP88/07/05 P F806 RC10 PSY UY90243 UP88/07/05 P F806 Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: recommended way to send large files from Z/os to WIN and backward
On Wed, 5 May 2010 13:26:47 -0400, Bob Woodside wrote: >On Wednesday 05 May 2010, Paul Gilmartin wrote: >> >> I'm mystified. I use Filezilla server for SMP/E RECEIVE FROMNETWORK, > >I regularly use the FileZilla client on Windows, Linux, and Solaris >workstations to connect to both the MVS and Unix sides of z/OS with no >problem. > >However, there are a couple of caveats: > >You need an up to date version - older versions of the FileZilla indeed >didn't understand the Unix side of z/OS. The oldest version I can find >on any of my workstations id 3.0.1, which works fine. > >You need to specify the server type as Unix under the Advanced tab to >access you Unix filesystem. > I don't use Filezilla client. Is it a GUI? I avoid GUI FTP clients. FTP is broken as specified for GUI use: The format of the reply to LIST or NLST is not specified, and dependent on the server system type. It was the assumption of the design that the reply would be presented as text to a human being at a terminal, who would be familiar with the conventions of the server and know how to proceed. The RFC does not even provide any uniform way to know which entries in the reply text are directories and which are basefiles. Accordingly, the GUI client must contain artificial intelligence to know the conventions of each supported server. z/OS is particularly problematic in that the format of the reply t differs radically according to whether the PWD is: o A legacy data set prefix o A PDS directory o A Unix directory Further, it's possible to CD to a partial prefix that doesn't even appear in the responses to LIST or NLST. This could be resolved by an extension to the FTP RFC specifying a new command with a standard format for directory listings. But there's too little demand to make this likely. And this should be done with a newer, secure protocol such as SFTP that doesn't transmit passwords in the clear and that doesn't require the backsocked for data that's problematic for firewalls. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Out of Office Mike Spires/AO/USR/FTU is out of the office.
I will be out of the office starting 05/06/2010 and will not return until 05/10/2010. I will respond to your message when I return. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Member name format for z/OS directory as simulated PDS?
On Wed, 5 May 2010 17:20:10 -0700, Charles Mills wrote: >Am I correct in my reading between the lines that if one is to process a >z/OS directory as though it were a PDS(E) using BPAM DCB, FIND, etc. then >the simulated member name - the file name - must be no more than eight >characters? > >Must be upper case? >What about names containing a period? No good? Must be no more than eight >characters total? Or . ? > It might be possible that BLDL or FIND issued from an assembler program might be more lenient. BPXWDYN probably won't allow it to be allocated; I wouldn't care to guess whether the restriction is enforced in BPXWDYN, ALLOCATE, or both. I used to have an API to BLDL and STOW that performed no enforcement on the member name; any 64 bits worked. I don't believe it should be the business of an API to enforce syntactic restrictions not in the underlying system service. >Is there any more information on this specific topic other than "Reading >UNIX Files Using BPAM" in "DFSMS Using Data Sets"? > >Yes, I could run experiments, but thought it made more sense to tap the >collected wisdom of this august crowd. > If you're reduced to this, I hope you share the result. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Auxiliary Storage Management I/O in a RAID array world
Alan, In current disk arrays everything between disk and cache is double handled. Read misses and writes are a two stage operation where all trans stop at cache before proceeding. There is no way to bypass cache, so all the vendors have come up with different ways to manage these hints. I may be out of date on in earlier models of Symmetrix EMC did not examine use any of the cache hints in an IO except for the sequential bit for PS-E datasets. Inhibit Cache load, Bypass Cache, Record Level Cache (1 and 2), Cache Fast Write and Sequential hints were all ignored and caching algorithms in the Symm had to figure it out. IBM, HDS, and STK chose to honor these hints in a variety of ways. The way that CFW is cached and handled by remote copy is very different between IBM and HDS, and ICL requests will be handled differently between IBM and STK. Some of this is treated as IP so you need to talk to your DASD vendor to get the story. I think the treatment of Sequential and CFW bits are the only hints of significant consequence in most arrays nowadays. Paging IO was a very poor cache candidate as far back as the 3880-11/13, through the 3990-2/3/6, and continued to be a paging pig on arrays starting with EMC4000 and on through RAMAC, Iceberg, HDS Lightning and in current arrays. It is the nature of paging IO. On HDS USP-V if you are paging heavily I would suggest two approaches that are not concerned with the treatment of cache hints: (1) If cache hits are already low, then prevent cache pollution by allocating the paging volumes on a few array groups and putting them in a very small cache partition (CLPR). This will prevent paging from trashing the other workloads. You may want to consider Flash drives for those array groups. (2) If paging is really critical to your performance then forget about flash drives and Cache Partitions, you want to give those babies real Solid State Performance by locking them in cache with Cache Residency Manager. If you have a paging issue and another vendor's storage they can offer alternatives for their storage architecture. As far as VIO goes, it started outperforming standard disk from the day the first 3090-200 shipped with expanded storage. With ES the VIO track window was no longer written and discarded from storage when it was no used, but was copied to from CS to ES. This meant that VIO stopped causing major page thrashing, and the performance became incredibly good. Although ES is no longer supported, IBM continue to keep VIO in CS as part of the working set. I'm not versed in the z/OS VIO paging algorithms, so I went for some empirical measurement reading and writing 15Mx100B records between two temp datasets. Used ICEGENER and executed five steps each using VIO and DASD. The results speak volumes, especially when you consider that the VIO step was maxed out on the uni-processor speed of our z9-408. DASDVIO 0.5 0.3 0.7 0.3 0.4 0.3 0.9 0.3 0.4 0.3 == Total 2.9 1.5 The working set for the VIO jobs maxed at 760MB and the page datasets did not raise an eyebrow (or an IO) on a 2GB LPAR with not much else running. So there seems to be an extremely good case for using VIO for performance. DFSMS makes it very easy to control what size datasets normally go to VIO, as well as allowing you to put some of your larger loved ones in there and keeping the baddies out. Just remember there can be too much of a good thing. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Starr, Alan > Sent: Wednesday, May 05, 2010 2:04 PM > To: IBM-MAIN@bama.ua.edu > Subject: [IBM-MAIN] Auxiliary Storage Management I/O in a RAID array world > > Hello List, > > It's been 20 or more years since I've looked at this. Once upon a time, one of > the tricks that ASM used to achieve maximum efficiency was to set a PCI bit in > its channel programs. This reduced the number of SIOs and IO interrupts when > the page dataset was isolated on a volume. > > Later, when DASD controllers implemented caches, I believe that ASM set a > "bypass caching" bit in its channel programs. Thus, I/Os performed by QSAM / > BSAM to real DASD that could be serviced by a "read hit" were often faster > (overall I/O service time) than those directed to VIO. I believe that "write > hits" and/or misses were slower. > > I'm wondering how it looks with today's RAID arrays. > > 1) Does ASM still set "bypass caching" in its channel programs? > 2) If so, do modern RAID arrays honor that in a way that matters? I'm thinking > that every I/O gets buffered these days. > 3) Is there any difference in I/O service time for QSAM / BSAM directed to > real DASD as opposed to VIO? > > I'm only looking at overall I/O service time here. I realize that there are > other factors (e.g. page dataset number and size, allocation time, volume > contention). > > Regards, > Alan > > >
Member name format for z/OS directory as simulated PDS?
Am I correct in my reading between the lines that if one is to process a z/OS directory as though it were a PDS(E) using BPAM DCB, FIND, etc. then the simulated member name - the file name - must be no more than eight characters? Must be upper case? What about names containing a period? No good? Must be no more than eight characters total? Or . ? Is there any more information on this specific topic other than "Reading UNIX Files Using BPAM" in "DFSMS Using Data Sets"? Yes, I could run experiments, but thought it made more sense to tap the collected wisdom of this august crowd. Charles Mills -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
AUTO: Jon Nolting is on vacation. I will be checking emails occasionally. (returning 05/13/2010)
I am out of the office until 05/13/2010. Note: This is an automated response to your message "Re: CA Support online?" sent on 5/5/10 11:16:28. This is the only notification you will receive while this person is away. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Auxiliary Storage Management I/O in a RAID array world
>Bottom line: Does the z/OS concept of cache have any performance relevance in >today's age? It's VERY relevant. Without it, you're stuck at spinning speed. >Is a channel program that specifies "bypass caching" any less efficient >(slower) than one that does not? Many years ago, either STK or EMC (or both), changed the caching algorithm based on the inhibit/bypass settings. But, everything still went through cache, upstream or downstream. I believe every I/O does, today. But, with today's disk speed (assisted by cache), I've stopped worrying about the mechanics, and more about the response/throughput. With the size of today's configurations, and adding in remote copying (many flavours) and flash copying, you cannot afford to micro-manage, and get tied up with the implementation of various cache algorithms. Analyse your I/O, and tackle the outliers. BTW, modern solid-state is going to change the knowledge base, again. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Auxiliary Storage Management I/O in a RAID array world
>And, IBM removed suspend/resume logic from ASM's channel programs in APAR OA14248 back in 2006. I thought so, but I couldn't remember the details. Also, with PAV, large cache, fast DASD, fast channels, and all their friends, lots of what we used to do is no longer valid. When I started, we were paging to a dedicated string (channels, cu, etc), of 8 3330's, and doing the 1-CYL PLPA trick. I remember, when we were converting from 3330's to 3350's, and again to 3380's, the capacity people were concerned about the waste of the disk real estate because of dedicating those 'huge' disk volumes to paging. Then, extended swap IUP came along, making us tie up more 'expensive' DASD. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
REPLAY available - May 4 Webcast: The Linux on System z toolchain in a nutshell
Posted to IBMVM,Linux390 & IBMMain for those who are interested in one-hour webcasts. This replay is about Linux on System z. Topic: The Linux on System z toolchain in a nutshell Speaker: Hans-Joachim Picht, IBM Boeblingen Level: Basic to Intermediate Duration: 60 minutes Launch and listen to replay: http://ibmstg.na3.acrobat.com/p27004477/ For customers, ISVs, and BP's. There is no charge to participate in this technical education session Abstract: The System z tools package is the essential tool chain for Linux on System z. It contains everything from the bootloader to dump related tools. This 1-hour webcast will outline the major tools of this package and present them in a nutshell; including the primary use cases; hints and real world examples providing a quick; authoritative solutions to daily system administration challenges. Furthermore the latest additions and extensions will be presented. We apologize for those who had trouble enrolling, or if you had difficulty getting into the web cast. They had to cancel the morning session but had a full house in the afternoon. Thanks for your patience. We will keep track of the LVC's at this web site, in case you ever want to go back and find one (or look for others at some time in the future). http://www.vm.ibm.com/education/lvc/ Julie is looking at the next one for z/VSE. Let us know if there's a particular z/VM, Linux on System z, or z/VSE topic you want to hear and we'll do our best to get an IBM presenter for it. Regards, Pam C P.S. The sunshine and ice cream refers to the beautiful blue sky day we had today. And the soft serve ice cream truck came by. yum. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Auxiliary Storage Management I/O in a RAID array world
Thanks Brian and Bill, That was very useful information and covers the suspend / resume aspect. I hope that somebody will be able to address the cache considerations. I believe that today's modern arrays must be emulating the CKD-based cache that MVS operating systems expect. After all, IDCAMS SETCACHE and LISTDATA still exist. But it also seems logical to me that they may implement some more generalized, "open system" cache arrangement that is relevant to any connecting operating system. Plus, each device has its own "buffer". It makes my head spin. Bottom line: Does the z/OS concept of cache have any performance relevance in today's age? Is a channel program that specifies "bypass caching" any less efficient (slower) than one that does not? Cheers... -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Brian Peterson Sent: Wednesday, May 05, 2010 14:33 To: IBM-MAIN@bama.ua.edu Subject: Re: Auxiliary Storage Management I/O in a RAID array world And, IBM removed suspend/resume logic from ASM's channel programs in APAR OA14248 back in 2006. http://www-01.ibm.com/support/docview.wss?uid=isg1OA14248 Brian On Wed, 5 May 2010 21:22:58 +, Bill Fairchild wrote: >The trick involved setting the Suspend flag bit in the last CCW so that >the channel program would not "end" but would instead "be suspended." You still get an interrupt when that happens. And the way ASM gets the "suspended" channel program running again is with the Resume Subchannel (RSCH) instruction instead of the Start Subchannel (SSCH) instruction. The SIOs and IO interrupts you referred to are still the same total number of each, but "SIO" is now spelled "SSCH and/or RSCH" and "IO interrupt" is now spelled "suspended I/O interrupt" rather than "channel and and device end interrupt". The increase in speed was accomplished by being able to bypass certain logic in the channel microcode when processing the Resume function. > >I don't know about the other technical points you raised. > >Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Auxiliary Storage Management I/O in a RAID array world
Things have changed quite a bit. Systems don't page much (zero average page rate is the ROT), cache is battery protected, and total service times are sometimes better expressed in microseconds than milliseconds. 'Real DASD' is just a logical construct these days. VIO seems to still have fans, but I'm not one of them. What are your issues? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Starr, Alan Sent: Wednesday, May 05, 2010 4:04 PM To: IBM-MAIN@bama.ua.edu Subject: Auxiliary Storage Management I/O in a RAID array world Hello List, It's been 20 or more years since I've looked at this. Once upon a time, one of the tricks that ASM used to achieve maximum efficiency was to set a PCI bit in its channel programs. This reduced the number of SIOs and IO interrupts when the page dataset was isolated on a volume. Later, when DASD controllers implemented caches, I believe that ASM set a "bypass caching" bit in its channel programs. Thus, I/Os performed by QSAM / BSAM to real DASD that could be serviced by a "read hit" were often faster (overall I/O service time) than those directed to VIO. I believe that "write hits" and/or misses were slower. I'm wondering how it looks with today's RAID arrays. 1) Does ASM still set "bypass caching" in its channel programs? 2) If so, do modern RAID arrays honor that in a way that matters? I'm thinking that every I/O gets buffered these days. 3) Is there any difference in I/O service time for QSAM / BSAM directed to real DASD as opposed to VIO? I'm only looking at overall I/O service time here. I realize that there are other factors (e.g. page dataset number and size, allocation time, volume contention). Regards, Alan NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Auxiliary Storage Management I/O in a RAID array world
And, IBM removed suspend/resume logic from ASM's channel programs in APAR OA14248 back in 2006. http://www-01.ibm.com/support/docview.wss?uid=isg1OA14248 Brian On Wed, 5 May 2010 21:22:58 +, Bill Fairchild wrote: >The trick involved setting the Suspend flag bit in the last CCW so that the channel program would not "end" but would instead "be suspended." You still get an interrupt when that happens. And the way ASM gets the "suspended" channel program running again is with the Resume Subchannel (RSCH) instruction instead of the Start Subchannel (SSCH) instruction. The SIOs and IO interrupts you referred to are still the same total number of each, but "SIO" is now spelled "SSCH and/or RSCH" and "IO interrupt" is now spelled "suspended I/O interrupt" rather than "channel and and device end interrupt". The increase in speed was accomplished by being able to bypass certain logic in the channel microcode when processing the Resume function. > >I don't know about the other technical points you raised. > >Bill Fairchild -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Auxiliary Storage Management I/O in a RAID array world
The trick involved setting the Suspend flag bit in the last CCW so that the channel program would not "end" but would instead "be suspended." You still get an interrupt when that happens. And the way ASM gets the "suspended" channel program running again is with the Resume Subchannel (RSCH) instruction instead of the Start Subchannel (SSCH) instruction. The SIOs and IO interrupts you referred to are still the same total number of each, but "SIO" is now spelled "SSCH and/or RSCH" and "IO interrupt" is now spelled "suspended I/O interrupt" rather than "channel and and device end interrupt". The increase in speed was accomplished by being able to bypass certain logic in the channel microcode when processing the Resume function. I don't know about the other technical points you raised. Bill Fairchild Software Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 Email: bi...@mainstar.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Starr, Alan Sent: Wednesday, May 05, 2010 4:04 PM To: IBM-MAIN@bama.ua.edu Subject: Auxiliary Storage Management I/O in a RAID array world Hello List, It's been 20 or more years since I've looked at this. Once upon a time, one of the tricks that ASM used to achieve maximum efficiency was to set a PCI bit in its channel programs. This reduced the number of SIOs and IO interrupts when the page dataset was isolated on a volume. Regards, Alan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Auxiliary Storage Management I/O in a RAID array world
Hello List, It's been 20 or more years since I've looked at this. Once upon a time, one of the tricks that ASM used to achieve maximum efficiency was to set a PCI bit in its channel programs. This reduced the number of SIOs and IO interrupts when the page dataset was isolated on a volume. Later, when DASD controllers implemented caches, I believe that ASM set a "bypass caching" bit in its channel programs. Thus, I/Os performed by QSAM / BSAM to real DASD that could be serviced by a "read hit" were often faster (overall I/O service time) than those directed to VIO. I believe that "write hits" and/or misses were slower. I'm wondering how it looks with today's RAID arrays. 1) Does ASM still set "bypass caching" in its channel programs? 2) If so, do modern RAID arrays honor that in a way that matters? I'm thinking that every I/O gets buffered these days. 3) Is there any difference in I/O service time for QSAM / BSAM directed to real DASD as opposed to VIO? I'm only looking at overall I/O service time here. I realize that there are other factors (e.g. page dataset number and size, allocation time, volume contention). Regards, Alan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problem with allocating ISPCTLXX
On Wed, 5 May 2010 09:51:02 -0700, Starr, Alan wrote: >Hi Joe, > >To answer your question, you can indeed use VIO for ISPCTL0. > >We don't even allocate the temporary ISPF DDs in our logon PROCedure. We allow ISPF to ALLOCate them dynamically, as it needs them. TSO ISPCCONF invokes the configuration utility. Option 3 permits specification of the default PDF unit. Option 4 allows you to indicate "Use Default PDF Unit for ISPF Data Sets". > >This is, of course, only applicable if your TSO userid datasets are not SMS-managed. Ours are, so these datasets just go to the storage group that the ACS routine selects. > >I advise you to try to keep your TSO logon PROCs as short as possible. Fewer DDs = smaller chance of failure. > In the past I've seen some nice performance benefits from pre-allocating those to VIO in large (a few hundred or more) TSO environments. It reduces VTOC contention. Especially when there were mutltiple systems involved. I haven't checked recently (last couple of releases), but I'm sure it's still mentioned (along with a bunch of other items) in the performance chapter of the ISPF customization guide. Of course, YMMV and "the past" goes back to SLED DASD when I actually measured this stuff. Long before things like PAV and multiple allegiance. That is the nice part about "modern DASD", you really don't have to worry about these sorts of things... but they never hurt. I still allocate them to VIO in my own personal ISPF startup. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: recommended way to send large files from Z/os to WIN and backward
I was thinking of the client, sorry if that caused confusion. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ServerPac Download Size for z/OS V1.11 on MOD9
Only needed M9 but had to allocate multiple volumes and specify -size on
format
//DEFINE EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//AMSDUMP DD SYSOUT=*
//SYSINDD *
DEFINE CLUSTER (NAME(OMVS.SMP.ZOS111.SMPNTS.ZFS) -
VOLUMES(ZFS400,ZFS401,ZFS402,ZFS403) -
DATACLASS(DCEXTADR) -
CYL(1) LINEAR SHAREOPTIONS(3,3))
//* Format VSAM Linear Data Set as ZFS Multiple File System Aggregate
//* -size is in K
//* 3390-9 volume = 720K
//* four 3390-9 volumes, 28G -size 2880
//ZFSNEWA EXEC PGM=IOEAGFMT,REGION=0M,
// PARM=('-aggregate OMVS.SMP.ZOS111.SMPNTS.ZFS -size 2880 -compat')
//STEPLIB DD DISP=SHR,DSN=SYS1.DFS.SIOELMOD
//SYSPRINT DD SYSOUT=*
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//CEEDUMP DD SYSOUT=*
//*
-jc-
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Lizette Koehler
> Sent: Tuesday, May 04, 2010 6:56 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: ServerPac Download Size for z/OS V1.11 on MOD9
>
> Listers -
>
> I have been going through the archives to see if this was already
answered.
> Since I did not find anything quickly, I need to ask
>
> We are getting ready to order the z/OS V1.11 from Shop zSeries
>
> We only use 3390-9 at our shop. I have heard rumors that I will need
a
> Mod27 to download this file.
>
> Is this correct?
>
> If so, is there a way to do partial downloads to Mod9 and then
recombine to
> one large file?
> Or is there another method (DSTYPE=LARGE) to spread across 3 Mod9?
>
> Thanks
>
> Lizette
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: rename SYS1.VTOCIX dataset
Works. Just make sure you delete the entry for the VTOCIX from all affected catalogs. OK, I did a "don't". Due to some procedures around here and a need for two large SMPPTS datasets, I created them on an "offline" volume. Now I must clean that up. What I've done is uncatalogued the datasets, clipped the volumes to the proper name, then recatalogued them. Now, I would like to change the name of the VTOCIX to be "proper". I know it will work the way it is, but I don't like it. My thought was that I could make the VTOC an OSVTOC, delete the SYS1.VTOCIX.badvol, recreate SYS1.VTOCIX.goodvl, then do a BUILDIX IXVTOC. Sound reasonable? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: rename SYS1.VTOCIX dataset
Once it is an OSVTOC< you could just rename the VTOCIX, no need to delete/allocate. >>> "McKown, John" 5/5/2010 2:01 PM >>> OK, I did a "don't". Due to some procedures around here and a need for two large SMPPTS datasets, I created them on an "offline" volume. Now I must clean that up. What I've done is uncatalogued the datasets, clipped the volumes to the proper name, then recatalogued them. Now, I would like to change the name of the VTOCIX to be "proper". I know it will work the way it is, but I don't like it. My thought was that I could make the VTOC an OSVTOC, delete the SYS1.VTOCIX.badvol, recreate SYS1.VTOCIX.goodvl, then do a BUILDIX IXVTOC. Sound reasonable? John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: rename SYS1.VTOCIX dataset
On 05/05/10 14:01, McKown, John wrote: OK, I did a "don't". Due to some procedures around here and a need for two large SMPPTS datasets, I created them on an "offline" volume. Now I must clean that up. What I've done is uncatalogued the datasets, clipped the volumes to the proper name, then recatalogued them. Now, I would like to change the name of the VTOCIX to be "proper". I know it will work the way it is, but I don't like it. My thought was that I could make the VTOC an OSVTOC, delete the SYS1.VTOCIX.badvol, recreate SYS1.VTOCIX.goodvl, then do a BUILDIX IXVTOC. Sound reasonable? John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM Yes. That should work fine. -- Mark Jacobs Time Customer Service Tampa, FL It is impossible to make anything foolproof, because fools are so ingenious. -- Robert Heinlein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
rename SYS1.VTOCIX dataset
OK, I did a "don't". Due to some procedures around here and a need for two large SMPPTS datasets, I created them on an "offline" volume. Now I must clean that up. What I've done is uncatalogued the datasets, clipped the volumes to the proper name, then recatalogued them. Now, I would like to change the name of the VTOCIX to be "proper". I know it will work the way it is, but I don't like it. My thought was that I could make the VTOC an OSVTOC, delete the SYS1.VTOCIX.badvol, recreate SYS1.VTOCIX.goodvl, then do a BUILDIX IXVTOC. Sound reasonable? John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
AUTO: Ann Totten/Poughkeepsie/IBM is out of the office until 09/06/2000. (returning 05/10/2010)
I am out of the office until 05/10/2010. Note: This is an automated response to your message "Re: recommended way to send large files from Z/os to WIN and backward" sent on 5/5/10 9:45:23. This is the only notification you will receive while this person is away. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: recommended way to send large files from Z/os to WIN and backward
On Wednesday 05 May 2010, Paul Gilmartin wrote: > On Tue, 4 May 2010 23:18:14 -0500, Bob Wood wrote: > >Filezilla os OK as long as you don't > > have a need to transfer files to USS, which it does not handle > > well. > > I'm mystified. I use Filezilla server for SMP/E RECEIVE FROMNETWORK, > which transfers to Unix files, quite successfully. What are the > problems? Or are you thinking of Filezilla client, with which I > have no experience. I regularly use the FileZilla client on Windows, Linux, and Solaris workstations to connect to both the MVS and Unix sides of z/OS with no problem. However, there are a couple of caveats: You need an up to date version - older versions of the FileZilla indeed didn't understand the Unix side of z/OS. The oldest version I can find on any of my workstations id 3.0.1, which works fine. You need to specify the server type as Unix under the Advanced tab to access you Unix filesystem. -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA Support online?
Very counter intuitive :( I had support.ca.com as a trusted site in my IE Security settings. REMOVING it and now I can logon to support.ca.com. Go figure and then blame it on Microsoft, I guess. Dave Gibney Information Technology Services Washington State University -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problem with allocating ISPCTLXX
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joe Reichman > Sent: Wednesday, May 05, 2010 11:31 AM > To: IBM-MAIN@bama.ua.edu > Subject: Problem with allocating ISPCTLXX > > Hi, > > All of the sudden I am having problems > Logging on to ISPF seems like the culprit in my ISPF login > proc is the > ddnames ISPCTL1-4 > Looked at the JCL it had unit=sysallda > > Can I point these ddnames to a particular VOL where I know I > have room > or maybe UNIT=VIO to allivate > This problem > Thankx > > > Sent from my iPhone What is the problem? JCL failure? SB37-4 abend? Something else? What DSN= in the JCL statement? If none, I would have thought that the allocation would be going to the SMS storage group for temporary datasets. If you don't have such, then they should be going, old style, to any volume which is mounted as PUBLIC or STORAGE. If the DSN= has a valid dataset, then it is either being SMS directed to a particular storage group or if not SMS manged then to some volume mounted STORAGE. I often use UNIT=VIO for temporary files. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problem with allocating ISPCTLXX
Hi Joe, To answer your question, you can indeed use VIO for ISPCTL0. We don't even allocate the temporary ISPF DDs in our logon PROCedure. We allow ISPF to ALLOCate them dynamically, as it needs them. TSO ISPCCONF invokes the configuration utility. Option 3 permits specification of the default PDF unit. Option 4 allows you to indicate "Use Default PDF Unit for ISPF Data Sets". This is, of course, only applicable if your TSO userid datasets are not SMS-managed. Ours are, so these datasets just go to the storage group that the ACS routine selects. I advise you to try to keep your TSO logon PROCs as short as possible. Fewer DDs = smaller chance of failure. Regards, Alan -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joe Reichman Sent: Wednesday, May 05, 2010 09:31 To: IBM-MAIN@bama.ua.edu Subject: Problem with allocating ISPCTLXX Hi, All of the sudden I am having problems Logging on to ISPF seems like the culprit in my ISPF login proc is the ddnames ISPCTL1-4 Looked at the JCL it had unit=sysallda Can I point these ddnames to a particular VOL where I know I have room or maybe UNIT=VIO to allivate This problem Thankx Sent from my iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Problem with allocating ISPCTLXX
Hi, All of the sudden I am having problems Logging on to ISPF seems like the culprit in my ISPF login proc is the ddnames ISPCTL1-4 Looked at the JCL it had unit=sysallda Can I point these ddnames to a particular VOL where I know I have room or maybe UNIT=VIO to allivate This problem Thankx Sent from my iPhone -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Couping Facility SFM Policy MEMSTALLTIME and MQ APAR PM01403
I want to inform the community about a problem we experienced, fortunately in our development environment, running z/OS 1.10 RSU0912. The problem is circumvented by an open MQ APAR and by a z/OS SFM policy parameter. Early one morning last week, our operators reported that all of the systems in the development plex were sick, jobs weren't starting, TSO users weren't able to logon. They reported IXC467I messages indicating that two of the systems were unable to communicate w/ the third. JES2 was issuing $HASP263 messages on all three systems, indicating it wanted but could not get the checkpoint (which is a CF structure). We eventually took a standalone dump and varied that third system out of the plex, which freed up processing on the other two systems. The third system IPLd normally and was fine afterwards. We had been running this software level since mid-March and hadn't seen this problem (or even hints of it) before. IBM determined that MQ v7 was looping and, therefore, not retrieving input messages from one of its structures. MQ on the other systems continued to send messages to the failing system which resulted in XCF buffers filling on this system. They call that an XCF stall condition. We didn't realize it at the time but XCF issued messages IXC431I, IXC430E, IXC631I and IXC640E, warning us of this situation. MQ Level2 told us our problem was another symptom of Open APAR PM01403, originally reported as an S0C4 abend in CSQLGETL. Our symptom is a loop in CSQLLPLM. The problem lies in MQ v7's new method for using preallocated LNMR control blocks. APAR fix AM01403, which restores the MQ v6 technique for handling these control blocks, is available. Level2 says a fixing PTF won't be available until at least the end of June because they're trying to restore the original functionality as well as fix the problem, which is apparently pretty complex. We were pretty shocked that a single address space, failing to retrieve messages from a single structure, could bring down an entire system and significantly impact other systems in the plex. However, XCF Level2 informed us of an SFM policy parameter, which we hadn't heard about previously, that will help us deal with that limitation. MEMSTALLTIME defines the number of seconds XCF will allow an XCF stall condition to exist before it dumps/terminates offending address space(s). The default is NO, which causes XCF to do nothing. Level2 told us XCF would have terminated the MQ address space and discarded its message buffers if we'd been using that parameter. In both cases, the Level2 reps told us no problems had been reported w/ either circumvention, though I think AM01403 is pretty new. We've turned on MEMSTALLTIME this weekend and installed AM01403. We've noticed no ill effects from either, though its still early. I'd recommend MQ v7 users consider installing AM01403 and XCF users implement MEMSTALLTIME. Please let me know if you have any questions. Thanks, Dennis Schaffer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to analyze a volume's access by dataset
bi...@mainstar.com (Bill Fairchild) writes: > I remember now about Amdahl's CSIM. Thanks for the lengthy post on it. > > Cache and NVS sizes were indeed vanishingly small in the 1980s > compared to today's models. I remember attending a SHARE session, > ca. 1989, in which an IBM cache control unit person from Tucson said > that IBM had modeled vast amounts of traced user I/O requests and > decided that 4M, or at most 8M, of NVS was all that anyone would ever > need to support DASD fast writes. This reminds of me T. J. Watson's > prediction in 1943 that "there is a world market for maybe five > computers." lol re: http://www.garlic.com/~lynn/2010i.html#18 How to analyze a volume's access by dataset I had gotten into some disputes with Tucson over some of their cache conclusions. The first two 3880 cache controllers were ironwood (3880-11) and sherif (3880-13) ... they were both 8mbyte cache controller caches ... ironwood was 4k "page" cache, and sherif was full-track cache. (hardware) fast-write allowed system logic to continue as soon as record was in controller cache ... but before arm had been moved and data actually deposited on disk. for no-single-point-of-failure ... this required that the electronic storage was replicated and could survive power-failure (marketing would tend to claim that whatever was shipping was what was actually needed). in some sense, it is temporary staging area to compensate for disk arm delay (and possibly being able to optimally re-arrange order of writes tailored to disk arm motion). fast-write logic shows up in 1980s DBMS implementation (not necessarily mainframe) where the DBMS is directly managing cache of records ... and transaction is considered commited as soon as the transaction image log record has been written ... but the actual data record hasn't yet been written to disk "home" location. The aggregate amount of (outstanding) "fast-write" records would tend to be related to how fast the system was executing transactions. I ran into some issues with this attempting to extend to cluster environment ... frequently used past reference (jan92 meeting in ellison's office) http://www.garlic.com/~lynn/95.html#13 some number of the (non-mainframe) implementations were getting the DBMS vendorsto move their vax/cluster implementation over to ha/cmp. at the time, when a record had to be moved from one cluster member to another, their vax/cluster implementation was to first force any "fast-write" records to their home disk location ... before the other cluster member read it off disk. This ignored the fast interconnect technologies that would allow direct cache-to-cache (of fast-write records) transfers. It turns out to get them off the first write to disk scenario ... there were some tricky issues with correctly merging transactions commits from multiple (cluster) logs during a recovery (say after total power outage). Early on there was apprehension of deploying direct cache-to-cache transfer (of potentially fast-write records) ... because of the complexities with log merging during recovery. misc. ha/cmp posts (direct cache-to-cache transfers, w/o first forcing to disk, was part of cluster scaleup in dbms environment): http://www.garlic.com/~lynn/subtopic.html#hacmp This is somewhat independent of cache size issues and (re-use) hit ratios (i.e. once in cache, what is the probability that the same record would again be requested). The early 3880-13 (full-track) cache documentation claimed 90% hit rates. Their model was sequential read of track formatted with ten records. The first record read from a track would bring in the whole track ... and then the next nine sequential record reads would be found in the cache. I raised the issue if the application switched to full-track sequential read, it would drop the numbers to zero percent cache hit ratio. The 3880-11 was being pitched as paging device ... to somewhat compensate for lack of 2305 followon. I had done page migration and some work on dup/no-dup algorithms in the 70s. Relative large system storage with relatively same amount of paging cache could result in zero percent hit rate. The issue is that if the page is brought into the system ... and the sizes of aggregate cache and system storage were compareable ... then every page that was in the cache would also be in system storage (and therefor would never be requested) ... only pages that weren't in system storage would be requested (but they then weren't likely to be in cache ... because cache was full of duplicates of what was in system storage). In that situation, I created a dynamic "no-duplication" switch ... heavily loaded 2305s would deallocate any record read into system storage. So when 3880-11 was announced, a typical system configuration was 3081 with 32mbytes of real storage. Adding four 3880-11 to the configuration would only have total of 32mbyte of cache. There would easily be the situation that every page in cache would also be in 3081 memory
WLM Managed PAV on VM
We just had an error at a DR exercise. Problem seems to be with WLM managed PAV volumes when LPAR hosted by VM. We ran a DR last year, same operating system, same DR site, with no problems when the LPAR was native on the CEC. This year's test was hosted by VM. Our operating system for this LPAR is z/OS 1.6. The team is traveling today, so messages and codes are fuzzy. The suspected error message was IOS050I. Anyone else experience something similar? Jimmy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to analyze a volume's access by dataset
I remember now about Amdahl's CSIM. Thanks for the lengthy post on it. Cache and NVS sizes were indeed vanishingly small in the 1980s compared to today's models. I remember attending a SHARE session, ca. 1989, in which an IBM cache control unit person from Tucson said that IBM had modeled vast amounts of traced user I/O requests and decided that 4M, or at most 8M, of NVS was all that anyone would ever need to support DASD fast writes. This reminds of me T. J. Watson's prediction in 1943 that "there is a world market for maybe five computers." lol Bill Fairchild Software Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.4503 * Mobile: +1.508.341.1715 Email: bi...@mainstar.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Larry Chenevert Sent: Tuesday, May 04, 2010 7:45 PM To: IBM-MAIN@bama.ua.edu Subject: Re: How to analyze a volume's access by dataset For those who were not there at the time -- in the 80's, when cache and fast-write were first introduced, caches were tiny compared to current technology, and NVS sizes were even smaller -- much smaller. Memory for cache and NVS was quite expensive. Caching and fast-write were, for a short time, specified on a dataset by dataset basis. Many internal marketing tools have corners cut in development (well I guess some companies even cut corners on their products!) and have very rough user interfaces, but not CSIM, which had all the attributes, look and feel of a flagship product. It was not a product, but was a tool for internal people to use -- although it was probably left with some customers. I suppose this tool could have been used to model the performance of different cache algorithms but I doubt it was ever used in that mode. Larry Chenevert -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: recommended way to send large files from Z/os to WIN and backward
On Tue, 4 May 2010 23:18:14 -0500, Bob Wood wrote: > >Filezilla os OK as long as you don't have a need to >transfer files to USS, which it does not handle well. > I'm mystified. I use Filezilla server for SMP/E RECEIVE FROMNETWORK, which transfers to Unix files, quite successfully. What are the problems? Or are you thinking of Filezilla client, with which I have no experience. >You will need to > convert >the DF/DSS backups using AMATERSE in order to get them back properly. >DF/DSS backups are RECFM=U, which can't be sent to a Windows box and >back correctly. The only problem with AMATERSE is that it can be slow on a >box with limited CPU. > AMATERSE has two levels of compression/performance. Are both so slow? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA Support online?
If it's of any help, my company-issued Windoze XP Pro SP3, IE6 laptop hasn't had any of the aforementioned issues. iexploere.exe is at the 6.0.2900.5512 level and wininet.dll is at 6.00.2900.5945. HTH. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: (may o r may not be on top i c) Float in g point ar i thme tic
I'm sorry I started this whole damn discussion by stupidly using pi as an example of a irrational number. My deepest apologies to the entire list for wasting their time and bandwidth. All I was speculating on in my original post was whether a hardware implementation of rational numbers would be of any use. I guess not. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 • N. Richland Hills • TX 76010 (817) 255-3225 phone • (817)-961-6183 cell john.mck...@healthmarkets.com • www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL > Sent: Wednesday, May 05, 2010 6:39 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: (may o r may not be on top i c) Float in g point > ar i thme tic > > >And it is thus perhaps possible to say, very loosely, that > real transcendentals are a subset of the irrationals. > > It's not loosely! > Rational numbers are those that can be described, accurately, > as a ratio, ie: fraction. > > Irrationals are those that cannot. > Therefore transcendentals are irrational. > But, not all irrational numbers are transendental. > The square root of 2, for example is not transendental. > It is algebraic: the solution to the equation X*X-2=0. > If it is not algebraic, and it is irrational, then it is > transcendental. > > Johann Heinrich Lambert conjectured that e and π were both > transcendental numbers in his 1761 paper proving the number π > is irrational. > > From mathisfun.com: > > The number e is a famous irrational number, and is one of the > most important numbers in mathematics. > > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA Support online?
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden > Sent: Tuesday, May 04, 2010 4:35 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: CA Support online? > > It keeps crashing my IE6 session as soon as I start to enter my name. > > I tried deleting just to cookies for ca.support and that > didn't work so I > deleted all the cookies and temp files. Then I got further and was > able to entered my name and password. When I tried submitting > that it just hung. So I closed the browser and tried again. > IE crashed again as I started to enter my user name. > > So I used Firefox and did nothing but login and it worked. :-) > > BTW, IE6 is what is supported on my corporate laptop. I have > Firefox installed > because I can... but many people can't. > > Guess I'll try again tomorrow with IE. > > Mark > -- Standard response around here: "Have you tried reinstalling Windows?" -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: (may o r may not be on top i c) Float in g point ar i thme tic
>And it is thus perhaps possible to say, very loosely, that real >transcendentals are a subset of the irrationals. It's not loosely! Rational numbers are those that can be described, accurately, as a ratio, ie: fraction. Irrationals are those that cannot. Therefore transcendentals are irrational. But, not all irrational numbers are transendental. The square root of 2, for example is not transendental. It is algebraic: the solution to the equation X*X-2=0. If it is not algebraic, and it is irrational, then it is transcendental. Johann Heinrich Lambert conjectured that e and π were both transcendental numbers in his 1761 paper proving the number π is irrational. >From mathisfun.com: The number e is a famous irrational number, and is one of the most important numbers in mathematics. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Catalog re-location
John, sounds like a good idea to me and I would go for it in a test environment. But in production there are things like recovery organization. In our systems catalogs are in the same storage pool like the application data and backup is done together with them. How would you organize it when all catalogs on one volume and you are not doing a backup of the whole dasd farm? How to keep consistent or do you have an ISV product for this instance? Reiner MARKUS sysprog Germany On Mon, 3 May 2010 15:30:55 -0700, John Norgauer wrote: >We are in the process of migrating all of our DASD to Hitachi mod 9's. Our >existing catalogs are spread over many of the old 3390's >that are going. I would like to have all of the catalogs on one volume for >the sake of organization. Any issues with this approach >(performance or otherwise)? > > > >John Norgauer >Senior Systems Programmer >Mainframe Technical Support Services >University of California Davis Medical Center >2315 Stockton Blvd >ASB 1300 >Sacramento, Ca 95817 >916-734-0536 > > SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! "JN 2004 > >"Hardware eventually breaks - Software eventually works" anon > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: (may o r may not be on top i c) Float in g point ar i thme tic
On 05/05/2010 12:19 AM, john gilmore wrote: Ted MacNeil writes: | BTW, transendental numbers are a subset of irrationals If, as I think we may safely assume, 'transendental' is a misspelling of 'transcendental', this observation is incorrect. An irrational number is a non-algebraic real number. by definition transcendental means non-algebraic. this applies to real or complex numbers. An irrational number is a real number that is not rational. sqrt(2) is an irrational number and algebraic (one solution of x**2=2) And it is thus perhaps possible to say, very loosely, that real transcendentals are a subset of the irrationals. since all rationals are algebraic, i.e. not transcendental ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: recommended way to send large files from Z/os to WIN and backward
Shai, I watch the you tube videos and download the product and I know it can simplified the proccess , but for mean while I will try to perform it using FTP for reasons i can't detail. On Tue, May 4, 2010 at 12:32 PM, shai hess wrote: > HI, > detaile > MFNetDisk can emulate 3490 tape without real tape and with automatic fast > mount. > You can run DFDSS in MF with the tape data in PC using MFNetDisk? (no need > FTP). PC can be Linux or Windows. > When ever you need the data back to MF you have it using the tape > emulation which access the tape data file as input. > The tape data in PC can be backup in PC using copy and paste in PC or > other > PC backup utilities. > This is a free product. > > Shai > > On Tue, May 4, 2010 at 11:05 AM, Matan Cohen >wrote: > > > MFnetdisk was consider as an substitute options. > > The desire state is to get the Datasets when initiate the connection > using > > FTP batch from the MF. when connecting to the Mainframe FTP from my > station > > I was able to send the Dataset. > > we design a backup proccess to get rid from our 3590 tape library and > move > > our MF backp to one of our Windows server . > > the datasets will move then by the Windows Backup to tapes . > > We are now trying to avoid any dependency to a product in this process > > (such > > like MFnetdisk). we are also limit on purchesing any product. > > *DON- * as you said i also assume the windows server see the target (MF > > side) as FAT32 , but I don't familiar with a way to control this and > force > > the FTP server (windows) to send the file. > > Lizette Koehler - BLKSIZE=32760 don't solve the problem. > > we use IE8. > > there is'nt additional message in syslog. > > > > On Tue, May 4, 2010 at 8:50 AM, Peter Bishop > wrote: > > > > > On Mon, 3 May 2010 13:48:38 +0300, Matan Cohen < > matancohen...@gmail.com> > > > wrote: > > > > > > >we are trying to use an ftp client on z/os > > > >using a job to get datasets larger than 4 GB from a windows server > after > > > we > > > >succesfully send the Datasets to the windows FTP server . > > > >when trying to get the Datasets back to the Mainframe we get the > follow > > > >message : > > > >553 Cannot send file larger than 4 gigabytes. > > > >we are trying to understand if the problem is cause from the windows > > side. > > > >we do use an SMS Data class so the Datasets will be a multivolume. > > > > > > > > > > Hi, > > > > > > Have you tried FileZilla? > > > > > > Thoroughly recommended, works on Vista, and the price is right. > > > > > > http://filezilla-project.org/ if you're interested. > > > > > > cheers > > > Peter > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > > > > > > > > -- > > best regards, > > matan cohen > > MF System Administrator. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- best regards, matan cohen MF System Administrator. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
