Something New for IDCAMS?

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.  


ALTER -                                                                   

IBMUSER.TEST -                                                        

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

IDC3012I ENTRY IBMUSER.TEST NOT FOUND                                  


IDC0532I **ENTRY IBMUSER.TEST NOT ALTERED                              


 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.

1 Like


January 24, 2013 02:24 PM by Mary Anne Matyaz

So what the heck good is the FILE dd on an alter then? Making sure that the volume is available? :(


January 24, 2013 03:59 PM by Marna Walle

I have no idea.  Even if I put another volume on the FILE that had nothing to do with the rename, it didn't care.  It just made sure it could get to that volume. (FILE actually is optional, which I guess says something.) I could dig into it and find out from DFSMS what exactly it was *supposed* to do, but that would be just learning about history with nothing I could use today.  On today's systems, though, I can't imagine it doing anything but giving me false hope and causing confusion.


January 25, 2013 10:55 AM by James Lund

Isn't FILE kinda like the cross-walk buttons? People *really* aren't sure they do anything, but keep pushing them anyway?!


January 25, 2013 01:55 PM by Mary Anne Matyaz

Great analogy James. :)

830 members in your JCL?

January 25, 2013 04:50 PM by M. Ray Mullins

I thought my 700+ was a lot. Some of them have ISPF stats with dates going back into the last millennium.

My 830 Members...

January 28, 2013 01:50 PM by Marna Walle

Ray -- Well, to be honest, several of them are not really JCL jobs, but REXX EXECs and some source that I didn't want to lose.  Still, there are 830 and I'm pretty good at finding what I need!  They date back to Nov 1989, and I was hired by IBM out of college in July 1989 :).

Recent Stories
Newer z/OS github additions

Do you have any thoughts on IBM Z resiliency?

New Function APARs are great to follow - case in point.