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
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
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
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
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: 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: 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
