> -----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=(xxxxx) 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
