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

Reply via email to