SV: Archaic allocation in JCL (Was: Physical record size query)
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Gibney, Dave Skickat: den 13 februari 2012 22:31 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, February 13, 2012 5:11 AM To: IBM-MAIN@bama.ua.edu Subject: SV: Archaic allocation in JCL (Was: Physical record size query) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Lizette Koehler Skickat: den 13 februari 2012 12:43 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) I can't understand why we STILL need to specify SPACE= (etc) for an allocation of a dataset. You normally don't do that in other OS (platforms), You always (both principally and in practice) want to allocate as much as is needed during execution If for backward compatibility it can't be done automatically, why not introduce a new keyword like e g SPACE=ANY ? Thomas, IIRC - if you force a DATACLAS on a dataset in SMS, you can specify the Space requirements there. Then the JCL does not require Space. Have you looked at that? However, then that makes your storage admin responsible for ensuring the space is enough. And if needed alter the dataclass if there are space issues. And it would require all such datasets be SMS managed. Lizette Hi Lizette, In practice it's not a viable alternative. Besides the need (if doing it that way) to communicate frequently with the space gang, it's to many variants of datasetnames and to many different needs for space depending on time, date and subgrouping within applications. But, this is precisely what SMS and DATACLAS are for. It does accomplish, for the most part, SPACE=ANY. Not fully using SMS is so 80s' If so, do You really see everyone that creates and submits JCLs to create/change DATACLAS/STORCLAS instead of editing the SPACE= parms ? Or do You envision DATACLAS/STORCLAS's with very generous SPACE allocations (for every allocation) ? Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
Paul Gilmartin paulgboul...@aim.com wrote in message news:2205241542597622.wa.paulgboulderaim@bama.ua.edu... On Mon, 13 Feb 2012 16:23:14 +0100, R.S. wrote: The only application I know that manages extent size - that means using some algorithm for extent increase - is MQ Series aka Wbesphere MQ (since version 6 AFAIR). It would be nice to have such facility in DATACLASS. Nice indeed. And someone else suggested DB2 as another good performer. And now I may add to my list another example or two of IBM's having a good idea but implementing it in the wrong layer. This should have been done not in MQ and/or DB2, but in allocation where all applications could take advantage of it. All this could have been done without changing the specification of the VTOC and DSCB nor making incompatible changes to them. Conway's Law. -- gil There is no 'IBM', there is the z/OS lab, the MQ lab and the DB2 lab. If the DB2 lab needs something or has a good idea and the z/OS lab is not willing to implement it, the DB2 lab implements it itself (assuming they at least talk to each other). Kees. 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...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Archaic allocation in JCL (Was: Physical record size query)
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Lizette Koehler Skickat: den 14 februari 2012 13:27 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) But, this is precisely what SMS and DATACLAS are for. It does accomplish, for the most part, SPACE=ANY. Not fully using SMS is so 80s' If so, do You really see everyone that creates and submits JCLs to create/change DATACLAS/STORCLAS instead of editing the SPACE= parms ? Or do You envision DATACLAS/STORCLAS's with very generous SPACE allocations (for every allocation) ? Regards, Thomas Berg So the question becomes where to define space? The system cannot think like a human. It usually needs a place to start. So IBM provided some solutions. Please! Requirement of space do not need any thinking. It answers itself during the execution. The LIKE parm in JCL If You have and remember the appropriate dataset. And this is not much better than using SPACE=. The SMS DataClas functions Se my post above. The JCL SPACE parm Which caused my choice of subject: Archaic... I think it was amazing that IBM was able to eliminate the need for DCB=(x) and just let us use the subparms. For SPACE you are looking at old code that needs to be altered in CONVERTER, JES, ALLOCATION, IOS and probably more. It is old code and not likely to change in our lifetimes. AFAICS, what needs to be changed is just the interpretation of the SPACE parm and the actual allocation on disk at the time of execution. - There have been changes in the JCL language the latest Years: LIKE, DCB subparms outside of the DCB parm, etc. This could obviously be done. - There can't be that many places that does the allocation of the space on disk. Note that there is no change of cataloging as such, just the process of adding/extending the extents as the dataset is expanding. There is no need to change the old code more than allowing a branch to the new code to handle the case of the new variant of the SPACE parm. snip Wait - we are back to your issue. Having to monitor and change something for space issues. That is where products like SRS and SRM are helpful. They monitor your system and if a space issue is about to happen, dynamically change the data allocations on the fly. Remember the old STOPX37? But, you also have issues because now you need to monitor the monitors and adjust them as space issues arise. Here we are back to how we look at the space allocation process. You seems to see it as a complicated process - or at least an intellectually demanding logic. For me it's something I can do in my sleep. (It's just a loop of changing the SPACE parms until it works = no B37 etc.) How could this be other that a VSMOP ? snip If you truly want to see this type of issue resolved, then perhaps a SHARE requirement or Change request to IBM would be more effective? Well, with more effective You seem to assume that I'm trying to get something realized. But this was/begun as an opinion from me to the ongoing discussions in this list regarding enhancements of MVS. For a realization of something like this and as working in a Swedish company (which AFAIK is not a SHARE member) I have to rely on other participants on this list that are SHARE members. (A request by me to IBM needs accompanying money...) Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
On Tue, 14 Feb 2012 11:28:58 +0100, Vernooij, CP - SPLXM wrote: Paul Gilmartin wrote in message And now I may add to my list another example or two of IBM's having a good idea but implementing it in the wrong layer. This should have been done not in MQ and/or DB2, but in allocation where all applications could take advantage of it. All this could have been done without changing the specification of the VTOC and DSCB nor making incompatible changes to them. Conway's Law. There is no 'IBM', there is the z/OS lab, the MQ lab and the DB2 lab. If the DB2 lab needs something or has a good idea and the z/OS lab is not willing to implement it, the DB2 lab implements it itself (assuming they at least talk to each other). That's a close paraphrase of my surmise of Conway's Law. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
On 2/14/2012 9:42 AM, Thomas Berg wrote: AFAICS, what needs to be changed is just the interpretation of the SPACE parm and the actual allocation on disk at the time of execution. - There have been changes in the JCL language the latest Years: LIKE, DCB subparms outside of the DCB parm, etc. This could obviously be done. - There can't be that many places that does the allocation of the space on disk. Note that there is no change of cataloging as such, just the process of adding/extending the extents as the dataset is expanding. There is no need to change the old code more than allowing a branch to the new code to handle the case of the new variant of the SPACE parm. You may think of your request as being reasonable, but a new SPACE parameter could be added in less time than this thread has been going. There is no one place where old code can be branched away from, rather space/extent processing is endemic in all DASD related code. More critically, most I/O related control blocks have physical limits, and would require major redesign to handle even static expansion, not to mention dynamic. By comparison, supporting FBA devices in zOS would have been trivial, but IBM could not justify that, either. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
Thomas, I've done this with DFSMS for a large, multi-country application where the developers simply coded UNIT=SMALL, MEDIUM, LARGE and HUGE in the JCL. The ACS routines took this UNIT value, along with some other logic and assigned a standard space allocation using the appropriate DATACLAS. The size for each DATACLAS was different for the DEV, UNIT and PROD environments, which allowed them to use the same JCL for these different environments. We did protect successful allocation with UNITCNT=5 and some ACC. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, February 13, 2012 5:11 AM To: IBM-MAIN@bama.ua.edu Subject: [IBM-MAIN] SV: Archaic allocation in JCL (Was: Physical record size query) -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Lizette Koehler Skickat: den 13 februari 2012 12:43 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) I can't understand why we STILL need to specify SPACE= (etc) for an allocation of a dataset. You normally don't do that in other OS (platforms), You always (both principally and in practice) want to allocate as much as is needed during execution If for backward compatibility it can't be done automatically, why not introduce a new keyword like e g SPACE=ANY ? Thomas, IIRC - if you force a DATACLAS on a dataset in SMS, you can specify the Space requirements there. Then the JCL does not require Space. Have you looked at that? However, then that makes your storage admin responsible for ensuring the space is enough. And if needed alter the dataclass if there are space issues. And it would require all such datasets be SMS managed. Lizette Hi Lizette, In practice it's not a viable alternative. Besides the need (if doing it that way) to communicate frequently with the space gang, it's to many variants of datasetnames and to many different needs for space depending on time, date and subgrouping within applications. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Archaic allocation in JCL (Was: Physical record size query)
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Lizette Koehler Skickat: den 13 februari 2012 12:43 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) I can't understand why we STILL need to specify SPACE= (etc) for an allocation of a dataset. You normally don't do that in other OS (platforms), You always (both principally and in practice) want to allocate as much as is needed during execution If for backward compatibility it can't be done automatically, why not introduce a new keyword like e g SPACE=ANY ? Thomas, IIRC - if you force a DATACLAS on a dataset in SMS, you can specify the Space requirements there. Then the JCL does not require Space. Have you looked at that? However, then that makes your storage admin responsible for ensuring the space is enough. And if needed alter the dataclass if there are space issues. And it would require all such datasets be SMS managed. Lizette Hi Lizette, In practice it's not a viable alternative. Besides the need (if doing it that way) to communicate frequently with the space gang, it's to many variants of datasetnames and to many different needs for space depending on time, date and subgrouping within applications. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Archaic allocation in JCL (Was: Physical record size query)
My variant is faster to write! ;) (BTW, with my idea only needed space is allocated, there is no unused preallocated space.) Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För McKown, John Skickat: den 13 februari 2012 14:21 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) Or, as the programmers at our shop would do: SPACE=EAT-EVERYTHING-IN-SIGHT-AND-CAUSE-OTHER-JOBS-TO-ABEND-BECAUSE-MY- STUFF-IS-IMPORTANT-AND-YOUR-STUFF-ISNT. Or SPACE=WHAT,ME_WORRY? Or SPACE=I-CANT-BE-BOTHERED-TO-SIZE-THIS-PROPERLY-AND-MY-PROGRAMS-NEVER-LOOP- EXCESSIVELY In many other systems, such as Winblows, everybody gets their own personal space. And if it is used up, it doesn't impact others. z/OS shares DASD space. So one bad apple can cause a major problem. Hopefully not in production. But what about for temp space? I've had production jobs go down due to no space on the work packs due to a nitwit coding up a job with 30 SORTWKnn DD statements, with SPACE=(CYL,(2000,100)). Because they kept getting SORT CAPACITY EXCEEDED and just wanted the elided job to run. This was in internal COBOL sort, so dynamic SORTWORK was not possible. IIRC, the problem was their program outputting about 30 million records (a bug). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 . N. Richland Hills . TX 76010 (817) 255-3225 phone . 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-MAIN@bama.ua.edu] On Behalf Of Thomas Berg Sent: Monday, February 13, 2012 5:28 AM To: IBM-MAIN@bama.ua.edu Subject: Archaic allocation in JCL (Was: Physical record size query) I can't understand why we STILL need to specify SPACE= (etc) for an allocation of a dataset. You normally don't do that in other OS (platforms), You always (both principally and in practice) want to allocate as much as is needed during execution If for backward compatibility it can't be done automatically, why not introduce a new keyword like e g SPACE=ANY ? Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Archaic allocation in JCL (Was: Physical record size query)
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Vernooij, CP - SPLXM Skickat: den 13 februari 2012 14:22 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) Thomas Berg thomas.b...@swedbank.se wrote in message news:a90e503c23f97441b05ee302853b0e6263ff850...@fspas01ev010.fspa.myntet. se... -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Lizette Koehler Skickat: den 13 februari 2012 12:43 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) I can't understand why we STILL need to specify SPACE= (etc) for an allocation of a dataset. You normally don't do that in other OS (platforms), You always (both principally and in practice) want to allocate as much as is needed during execution If for backward compatibility it can't be done automatically, why not introduce a new keyword like e g SPACE=ANY ? Thomas, IIRC - if you force a DATACLAS on a dataset in SMS, you can specify the Space requirements there. Then the JCL does not require Space. Have you looked at that? However, then that makes your storage admin responsible for ensuring the space is enough. And if needed alter the dataclass if there are space issues. And it would require all such datasets be SMS managed. Lizette Hi Lizette, In practice it's not a viable alternative. Besides the need (if doing it that way) to communicate frequently with the space gang, it's to many variants of datasetnames and to many different needs for space depending on time, date and subgrouping within applications. Regards, Thomas Berg Now I don't understand: if you have so many different space needs, how do you assume 'SPACE=ANY' to solve this? With SPACE=ANY, the needed space is allocated and extended during the execution. So You don't do any preallocation of a specified amount of space. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
W dniu 2012-02-13 14:28, Thomas Berg pisze: [...] With SPACE=ANY, the needed space is allocated and extended during the execution. So You don't do any preallocation of a specified amount of space. Thomas, Your idea is worth discussion, but not your requirement is off target. It is not JCL problem, it is z/OS problem. To fill the requirement the sapce should be allocated ad hoc, cluster after cluster (*). That requires total VTOC revolution. BTW: Idea of space extents is maybe archaic, but I wouldn't consider it worse. It's different and reruires different approach and tools. (*) Cluster - in this case the smallest addressable amount of disk storage. For 3390-3 it would be 1 trk, for NTFS disk in my PC it would be 4kB, for old FAT format of 2GB partition it was 32kB, for EAS on EAV device it is 21 CYL. -- 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 authorised 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. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: SV: Archaic allocation in JCL (Was: Physical record size query)
(This is an answer also to Vernooij.) Please consider what You do manually when the space is to small (e g B37 etc.), or You just is unsure: You try a bigger allocation, maybe also extend (or reduce) the secondary amount. And repeat. Often many times. Would it be a problem if this (more or less) is automated ? Hm ? Technically I suppose it's solved by an initial virtual allocation filling a buffer in memory. Then a disk allocation is done at a threshold with e g 5 cyl. If that is not enough, add 4 times the amount, 20 cyl. Repeat this until finish. Release unused space (from the last add). This is just an example, it can be done much more sophisticated by the OS. And the limit of allocation should be set by userid or datasetname properly. Or maybe by a (e g) LIMIT= keyword. (I'm using the JCL case as an illustrative example, it should of course be general system interface.) Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För R.S. Skickat: den 13 februari 2012 14:49 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: Archaic allocation in JCL (Was: Physical record size query) W dniu 2012-02-13 14:28, Thomas Berg pisze: [...] With SPACE=ANY, the needed space is allocated and extended during the execution. So You don't do any preallocation of a specified amount of space. Thomas, Your idea is worth discussion, but not your requirement is off target. It is not JCL problem, it is z/OS problem. To fill the requirement the sapce should be allocated ad hoc, cluster after cluster (*). That requires total VTOC revolution. BTW: Idea of space extents is maybe archaic, but I wouldn't consider it worse. It's different and reruires different approach and tools. (*) Cluster - in this case the smallest addressable amount of disk storage. For 3390-3 it would be 1 trk, for NTFS disk in my PC it would be 4kB, for old FAT format of 2GB partition it was 32kB, for EAS on EAV device it is 21 CYL. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: SV: Archaic allocation in JCL (Was: Physical record size query)
W dniu 2012-02-13 15:21, Thomas Berg pisze: (This is an answer also to Vernooij.) Please consider what You do manually when the space is to small (e g B37 etc.), or You just is unsure: You try a bigger allocation, maybe also extend (or reduce) the secondary amount. And repeat. Often many times. Would it be a problem if this (more or less) is automated ? Hm ? Technically I suppose it's solved by an initial virtual allocation filling a buffer in memory. Then a disk allocation is done at a threshold with e g 5 cyl. If that is not enough, add 4 times the amount, 20 cyl. Repeat this until finish. Release unused space (from the last add). This is just an example, it can be done much more sophisticated by the OS. And the limit of allocation should be set by userid or datasetname properly. Or maybe by a (e g) LIMIT= keyword. (I'm using the JCL case as an illustrative example, it should of course be general system interface.) Actually space abends in my environment are very very rare. Time and experience were needed to go there, but the experience + SMS facilities + DFSMShsm causes x37 abends almost non-existent. As I said, z/OS storage requires different approach. On Windows system programmer opens the file and writes to it. On z/OS he has to answer the question: HOW MUCH DATA DO YOU EXPECT TO BE WRITTEN. The answer can be vry imprecise, but it is required. Could it be better? I think so. What about unlimited number of extents? Or at least, let's say, 3000 per volume? What about multi-volume PDS(E)s? What about FBA disks? WAKE UP! ;-) -- 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 authorised 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. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Archaic allocation in JCL (Was: Physical record size query)
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Paul Gilmartin Skickat: den 13 februari 2012 15:48 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) On Mon, 13 Feb 2012 12:27:53 +0100, Thomas Berg wrote: I can't understand why we STILL need to specify SPACE= (etc) for an allocation of a dataset. You normally don't do that in other OS (platforms), You always (both principally and in practice) want to allocate as much as is needed during execution Can you use UNIX files (zFS) for your purposes and avoid the archaism? Not practically. But that would be a circumvention, not a solution as I see it. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
On Mon, 13 Feb 2012 14:48:57 +0100, R.S. wrote: Your idea is worth discussion, but not your requirement is off target. It is not JCL problem, it is z/OS problem. To fill the requirement the sapce should be allocated ad hoc, cluster after cluster (*). That requires total VTOC revolution. What I'd like to see as a less revolutioary implementation of SPACE=ANY is: o Primary allocation: one cluster. o Succeeding allocations are successive Fibonacci numbers (arbitrary design choice) of clusters. Since extents are not now constrained to be equal in size, this would be a relatively local change in allocation. Since (in some cases) a data set may have up to 123 extents, this would support a maximum data set size of up to 1.6 ^ 122 clusters, hardly a practical limit. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: SV: SV: Archaic allocation in JCL (Was: Physical record size query)
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För R.S. Skickat: den 13 februari 2012 15:49 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: SV: Archaic allocation in JCL (Was: Physical record size query) W dniu 2012-02-13 15:21, Thomas Berg pisze: (This is an answer also to Vernooij.) Please consider what You do manually when the space is to small (e g B37 etc.), or You just is unsure: You try a bigger allocation, maybe also extend (or reduce) the secondary amount. And repeat. Often many times. Would it be a problem if this (more or less) is automated ? Hm ? Technically I suppose it's solved by an initial virtual allocation filling a buffer in memory. Then a disk allocation is done at a threshold with e g 5 cyl. If that is not enough, add 4 times the amount, 20 cyl. Repeat this until finish. Release unused space (from the last add). This is just an example, it can be done much more sophisticated by the OS. And the limit of allocation should be set by userid or datasetname properly. Or maybe by a (e g) LIMIT= keyword. (I'm using the JCL case as an illustrative example, it should of course be general system interface.) Actually space abends in my environment are very very rare. Time and experience were needed to go there, but the experience + SMS facilities + DFSMShsm causes x37 abends almost non-existent. As I said, z/OS storage requires different approach. On Windows system programmer opens the file and writes to it. On z/OS he has to answer the question: HOW MUCH DATA DO YOU EXPECT TO BE WRITTEN. The answer can be vry imprecise, but it is required. Could it be better? I think so. What about unlimited number of extents? Or at least, let's say, 3000 per volume? What about multi-volume PDS(E)s? What about FBA disks? WAKE UP! ;-) I refuse! :) (In my life space abends occurs regularly, often caused by circumstances beyond my control.) BTW, You latter suggestions is not bad - but You didn't go far enough! There should unlimited number of *everything*! Don't make artificial limits. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
W dniu 2012-02-13 16:14, Paul Gilmartin pisze: On Mon, 13 Feb 2012 14:48:57 +0100, R.S. wrote: Your idea is worth discussion, but not your requirement is off target. It is not JCL problem, it is z/OS problem. To fill the requirement the sapce should be allocated ad hoc, cluster after cluster (*). That requires total VTOC revolution. What I'd like to see as a less revolutioary implementation of SPACE=ANY is: o Primary allocation: one cluster. o Succeeding allocations are successive Fibonacci numbers (arbitrary design choice) of clusters. Since extents are not now constrained to be equal in size, this would be a relatively local change in allocation. Since (in some cases) a data set may have up to 123 extents, this would support a maximum data set size of up to 1.6 ^ 122 clusters, hardly a practical limit. The only application I know that manages extent size - that means using some algorithm for extent increase - is MQ Series aka Wbesphere MQ (since version 6 AFAIR). It would be nice to have such facility in DATACLASS. However using DVC and 123 ext/vol and space constraint relief + reduce allocation is not bad also. -- 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 authorised 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. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.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.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: SV: SV: Archaic allocation in JCL (Was: Physical record size query)
On 02/13/12 10:20, Thomas Berg wrote: snip I refuse! :) (In my life space abends occurs regularly, often caused by circumstances beyond my control.) BTW, You latter suggestions is not bad - but You didn't go far enough! There should unlimited number of *everything*! Don't make artificial limits. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK TANSTAAFL. Whether we like it or not economics is a fact of life, everything can't be unlimited. There are always costs involved both for widgets and for the management of said widgets. -- Mark Jacobs Time Customer Service Tampa, FL Learn from yesterday, live for today, hope for tomorrow. The important thing is to not stop questioning. - Albert Einstein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
On Mon, 13 Feb 2012 16:13:48 +0100, Thomas Berg wrote: Can you use UNIX files (zFS) for your purposes and avoid the archaism? Not practically. But that would be a circumvention, not a solution as I see it. When something doesn't work as desired, and it's impractical to fix it (R.S. appears to understand the design constraints), and you discard it and get a new one with more satisfactory design, I don't see why you see that as a circumvention as opposed to a solution. Suppose z/OS were to provide an entirely new DSORG that met your requirement of SPACE=ANY. Would you see that also as a circumvention? Tne customers' perennial but impossible demand: Make it work, but don't change anything! E.g.: allow volumes larger than 54 GB, but don't change the 3390 geometry! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: SV: Archaic allocation in JCL (Was: Physical record size query)
Thomas Berg thomas.b...@swedbank.se wrote in message news:a90e503c23f97441b05ee302853b0e6263ff850...@fspas01ev010.fspa.myntet.se... -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För R.S. Skickat: den 13 februari 2012 15:49 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: SV: Archaic allocation in JCL (Was: Physical record size query) W dniu 2012-02-13 15:21, Thomas Berg pisze: (This is an answer also to Vernooij.) Please consider what You do manually when the space is to small (e g B37 etc.), or You just is unsure: You try a bigger allocation, maybe also extend (or reduce) the secondary amount. And repeat. Often many times. Would it be a problem if this (more or less) is automated ? Hm ? Technically I suppose it's solved by an initial virtual allocation filling a buffer in memory. Then a disk allocation is done at a threshold with e g 5 cyl. If that is not enough, add 4 times the amount, 20 cyl. Repeat this until finish. Release unused space (from the last add). This is just an example, it can be done much more sophisticated by the OS. And the limit of allocation should be set by userid or datasetname properly. Or maybe by a (e g) LIMIT= keyword. (I'm using the JCL case as an illustrative example, it should of course be general system interface.) Actually space abends in my environment are very very rare. Time and experience were needed to go there, but the experience + SMS facilities + DFSMShsm causes x37 abends almost non-existent. As I said, z/OS storage requires different approach. On Windows system programmer opens the file and writes to it. On z/OS he has to answer the question: HOW MUCH DATA DO YOU EXPECT TO BE WRITTEN. The answer can be vry imprecise, but it is required. Could it be better? I think so. What about unlimited number of extents? Or at least, let's say, 3000 per volume? What about multi-volume PDS(E)s? What about FBA disks? WAKE UP! ;-) I refuse! :) (In my life space abends occurs regularly, often caused by circumstances beyond my control.) BTW, You latter suggestions is not bad - but You didn't go far enough! There should unlimited number of *everything*! Don't make artificial limits. Regards, Thomas Berg This is a huge conversion. There was a good point in your previous suggestion and in Gill's: take a primary allocation and add ever larger secondaries. With multivolume datasets, you can have a lot of extents and consequently a lot of space, all without having to change the current limits in the Dasd architecture. It only requires a new Space Constraint Releave algorithme. This is what DB2 does nowadays. Our DB2 administrators converted to this (-1,-1) allocation a year ago and happily saw problems with mis/underallocated space amounts disappear completely and we gained back a lot of unnecessarily overallocated space from the former way of database space allocation. The knife cuts on both sides this way. Kees. 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...@bama.ua.edu with the message: INFO IBM-MAIN
SV: SV: Archaic allocation in JCL (Was: Physical record size query)
-Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Paul Gilmartin Skickat: den 13 februari 2012 16:30 Till: IBM-MAIN@bama.ua.edu Ämne: Re: SV: Archaic allocation in JCL (Was: Physical record size query) On Mon, 13 Feb 2012 16:13:48 +0100, Thomas Berg wrote: Can you use UNIX files (zFS) for your purposes and avoid the archaism? Not practically. But that would be a circumvention, not a solution as I see it. When something doesn't work as desired, and it's impractical to fix it (R.S. appears to understand the design constraints), and you discard it and get a new one with more satisfactory design, I don't see why you see that as a circumvention as opposed to a solution. Suppose z/OS were to provide an entirely new DSORG that met your requirement of SPACE=ANY. Would you see that also as a circumvention? Tne customers' perennial but impossible demand: Make it work, but don't change anything! E.g.: allow volumes larger than 54 GB, but don't change the 3390 geometry! To the last question, if it required the applications to be rewritten: Yes. My intention was not to solve my immediate need, but to propose a more general solution that can be used by wider group. Regarding zFS: this would require a change in many places: procedures, JCLs and routines for administration of space (for the UNIX side). Of course, if You see UNIX as the future and MVS (or maybe just its file system) as something to leave behind, You are right. But my view is that MVS could and should be improved. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
SV: Archaic allocation in JCL (Was: Physical record size query)
I'm beginning to wondering... :) But I started in februari 1979... Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Frank Swarbrick Skickat: den 13 februari 2012 19:27 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Archaic allocation in JCL (Was: Physical record size query) Are you sure you are a mainframer? From: Thomas Berg thomas.b...@swedbank.se To: IBM-MAIN@bama.ua.edu Sent: Monday, February 13, 2012 4:27 AM Subject: Archaic allocation in JCL (Was: Physical record size query) I can't understand why we STILL need to specify SPACE= (etc) for an allocation of a dataset. You normally don't do that in other OS (platforms), You always (both principally and in practice) want to allocate as much as is needed during execution If for backward compatibility it can't be done automatically, why not introduce a new keyword like e g SPACE=ANY ? Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
On Mon, 13 Feb 2012 16:23:14 +0100, R.S. wrote: The only application I know that manages extent size - that means using some algorithm for extent increase - is MQ Series aka Wbesphere MQ (since version 6 AFAIR). It would be nice to have such facility in DATACLASS. Nice indeed. And someone else suggested DB2 as another good performer. And now I may add to my list another example or two of IBM's having a good idea but implementing it in the wrong layer. This should have been done not in MQ and/or DB2, but in allocation where all applications could take advantage of it. All this could have been done without changing the specification of the VTOC and DSCB nor making incompatible changes to them. Conway's Law. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: Archaic allocation in JCL (Was: Physical record size query)
Sent from my iPad On Feb 13, 2012, at 14:53, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 13 Feb 2012 16:23:14 +0100, R.S. wrote: The only application I know that manages extent size - that means using some algorithm for extent increase - is MQ Series aka Wbesphere MQ (since version 6 AFAIR). It would be nice to have such facility in DATACLASS. Nice indeed. And someone else suggested DB2 as another good performer. And now I may add to my list another example or two of IBM's having a good idea but implementing it in the wrong layer. This should have been done not in MQ and/or DB2, but in allocation where all applications could take advantage of it. All this could have been done without changing the specification of the VTOC and DSCB nor making incompatible changes to them. Conway's Law. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
