Something New For IDCAMS?

(Repost from January 24, 2013)

I try to have IDCAMS do what I want, is that too much to ask?

I like single-screen blog entries, so I can get through them quickly.  I wish this was one of those.  This is a two-screen mini-vent on something that is probably insignificant, but I hate it when I see these things...

Every once in a while I come across something pretty basic that until then I haven't cared about or  haven't noticed.  This is made even worse by my pretty extensive set of JCL I've gathered over the years.  I keep hearing that JCL is reused to the point that no one writes their own anymore, and I think that's pretty true.  There's very little I have to look up in the books anymore, since I've probably got a job to do it in my 830 member JCL data set.

This one, however, got me a little surprised.  Maybe because I just wasn't going to give up and try another one of my jobs that I knew would work (IEHPROGM), or maybe because I thought it was time that I actually look at the book and learn something new. (Please don't append back with "you should have know that IDCAMS doesn't work that way". )  This is just about my surprise about NOT being able to do it with IDCAMS, and my stubbornness.

I was really glad to see that we've been "modernizing" IDCAMS in z/OS R11 and R12 with little enhancements.  Maybe this is also something that we could "modernize", although I'm sure that the good IDCAMS folks are not looking around for stuff to do.             

What I wanted to do:  rename an uncataloged, non-SMS, PDS data set.  I know that IDCAMS is recommended for use with SMS-managed data sets, which is not what I was doing - still for some reason I decided IDCAMS was the way I'd try it.  Round peg, square hole. Call me obstinate. I was going to give it a shot and this was a simple request.  

IDCAMS  SYSTEM SERVICES       

ALTER -                                                                   

IBMUSER.TEST -                                                        

FILE(DASD) NEWNM(IBMUSER.TEST.OLD)                           

IDC3012I ENTRY IBMUSER.TEST NOT FOUND                                  

IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42 

IDC0532I **ENTRY IBMUSER.TEST NOT ALTERED                              

IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8  

 42  Explanation: The catalog record for the requested entry could not be found.    Programmer Response: Ensure that the entry name specified on the access method services command is in the catalog specified.

Catalog?  I didn't want to use no stinking catalog.  I gave it a FILE (volume) to use!  So I looked into this more.  What got me worried was that this restriction I didn't remember reading before:

Restriction: While the FILE parameter can preallocate a volume where the data set resides, it does not direct the ALTER request to the data set to be altered. Instead, a catalog search is done to locate the data set to be altered.

First thought: NextGen'ers are going to love this.  You specify a FILE that has the volume you "associate" with the data set, and your rename doesn't use it - it goes to the catalog to see what to rename.  Really helpful, huh?  

Wouldn't it be nice if we had a NOCATALOG parm (to be used with FILE in the way that is more obvious), so that we could ditch that restriction?  I'll cease my mini-vent now.  I know of a dozen more things that really are important, but this annoyance happened to occur when a "Musing" was due.  Peace out.