Joined: 23 Nov 2006 Posts: 19270 Location: Inside the Matrix
From what i've seen, when people get "mainframe training" at some education facility, SMS is not included - i suppose it is not in the scope of cobol, jcl, vsam, database, utilities, etc. When they go to work and are not told how to allocate SMS-managed datasets at their employment site, the datasets follow all of the old rules. I've been to a few sites where people who had been developers there for several years, did not that the reason they "lost" datasets sometimes because they were allocated on transient volumes rather than SMS-managed volumes. When the "scratch & clean" was run over the weekend or whenever, their test files went away. . .
The biggest reason that i've seen for not using SMS is fear of change and ignorance of what SMS is and what it does. It has been a while since i've gone into a place that did not use SMS at all. For my $.02, not going to SMS is a management problem - individual projects should not determine whether to use SMS or not (again IMHO).
Joined: 14 Mar 2007 Posts: 8620 Location: Back in jolly old England
SMS is no great user of resource. I've never seen a system grind to a halt because SMS had grabbed all of the CPU.
SMS may be used to allocate default space parameters but only if it is set up to. This is obviously a site specific thing, where they have chosen not to. This assumes that this is an SMS managed allocation.
Unfortunately SMS will accept a BLKSIZE from the JCL if coded, so the JCL would win that one. I do try and post rewrites of OP JCL to remove BLKSIZE and let the operating system define it.
As to why your dataset needs to be restored every week, well, one suggestion has already been put forward by Dick. If the dataset is SMS managed then go talk to your storage group and tell them that it can not be deleted so quickly. Of course there's always the possibility that somewhere in the scheme of the application path that someone has coded DISP=(xxx,DELETE)