> > > > 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. The LIKE parm in JCL The SMS DataClas functions The JCL SPACE parm 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. I am also sure that if the developers in the 60's and 70's had any clue where computing was going, they might have thought harder on their designs. Remember when this was evolving we had restrictions that needed to be spelled out to the operating system. Therefore, this process (Space Allocation) needed to be definitely set. Remember, this came to us from MFT, MVT, SVS, and then MVS. And developers had to know what they were using and conserve the space usage. Everything was expensive back then. Instead maybe you need to look at a homegrown process that generates your JCL using META Data. Then if you have space problems, you can adapt your META Data or use products like SRS (DTS Software) or BMC Mainview SRM to monitor and dynamically grow or shrink a file as needed. 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. Seems to me to be an infinite loop. Not one with a solution with today's tools. The issue of space is one of limitation of DASD space. If you have infinite storage, then over allocate everything in a Dataclass and not worry. If you have a constricted dasd environment, then keeping tight allocations will lead to space issues. So what do you want to manage - JCL or SMS code? Most shops review their allocations periodically and adjust their process. Either through SMS Dataclas or JCL. I know most shop would love to have a "human thinking universe", however the computer is still fairly rudimentary. No Star Trek environment yet. ;-D 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? Just my $0.02 worth. Lizette ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN