IDC3024I VOLUME OWNED BY ANOTHER CATALOG

[patrickraths]

Hi Moshix,

Thanks for your great video. I came across an issue that it seems has caused some problems with the various INSTLIB job's. I had launched the EXEC KICKSSYS.V1R5M0.CLIST(KFIX) as indicated before launching any of the instilb jobs. However, at the first run there was an error message after enter "YES" and so I run it again and go the DONE, READY confirmation.

However, as it turned out some of the references in the jobs in the 5 INSTLIB members did not change to HERC01.KICKSSYS.V1R5M0 but stayed on the origin K.U.MURACH. At the time I executed those jobs I overlooked this matter but I found out when I tried to start KICKS and it failed.

So I went back to the various INSTLIB JCL's corrected all the references to the correct values and run the jobs again. However, I am getting Condition Code 12 and if I read this correctly then it is connected to the two other messages shown below, VOLUME OWNED BY ANOTHER CATALOG.

I had tried to delete the wrongly configured VSAM CLUSTERS by adding delete statements to the wrong K.U.MURACH and the datasets are gone, but no new ones are created under HERC01.KICKSSYS for the data of the application.

Any thoughts how to rectify this? I search on google with the below error message didn't produce much results.

IDC3024I VOLUME OWNED BY ANOTHER CATALOG
IDC3009I ** VSAM CATALOG RETURN CODE IS 148 - REASON CODE IS IGG0CLAQ-0
IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12

[moshix]

VSAM, Catalogs and volumes are intricately intertwined. Once you have a VSAM dataset on a volume, then VSAM owns that volume (because of the way it calcualtes relative disk pointers). You must first remove the VSAM dataset and put it where you want it to be.