info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Help with a catalog problem
833 views
Skip to first unread message
Dave Day
Oct 31, 2011, 4:27:34 PM10/31/11
to
In moving data from one z/OS system to another, I have somehow hosed up a catalog. The orignal system was at z/Os 1.10, the new system is at 1.12. I moved 8 3390 volumes using ADRDSSU dump and restore, and this looked like it worked well. One of the 3390's I moved had a user catalog on it that contained the catalog entries for the datasets on the moved volumes. I executed an IMPORT CONNECT to connect the ADCD system's master to the user, then did DEFINE ALIAS for the alias entries. Everything looked good at this point. I could find my existing datasets on the volumes using the catalog. Up until then I was working as IBMUSER.
I logged off and logged back on with one of the new TSO userid's defined on the 1.12 system. The logon id was the same as one defined on the 1.10 system. Almost immediately started getting various errors when trying to allocate new datasets using ISPF 3.2 with a hlq that would match one of the alias entries in the user catalog. The errors would occur if I did not specify a volser on the allocate. If I directed it towards a volume, as long as space was on the volume, everything was ok. The goofy part about this is that I would get error messages on my TSO terminal indicating an error while trying to allocate, but after hitting the enter key, the dataset would get allocated.
My thought was that a 1.10 catalog was not compatible with 1.12, and that I had screwed up by just doing the IMPORT CONNECT on the existing catalog that came with the volume restore. But I can't get rid of it. Everything I try fails. Early on I did an EXPORT of the catalog, and that worked fine. I then tried an IMPORT, since the manual states the catalog is deleted and re-defined in this operation, but the IMPORT
fails. Error says it cannot open the catalog.
I then deleted the alias entries for the user cat, and did an EXPORT DISCONNECT of the user cat from the master cat. Return code 0 from both. I then defined another user cat on a different volume, and tried an IMPORT of the exported copy. Job got errors. The original user cat was named UCAT.CATALOG1 on volume VPWRKF. The new user cat is UCAT.CATALOG on volume SCSYS1. Am getting these errors from the job:
IEC614I CREATE FAILED - RC 192, DIAGNOSTIC INFORMATION IS (04160055) ,
STEP1,VPWRKF,UCAT.CATALOG1
Idcams output is:
IMPORT INFILE(RECEIVE) OUTDATASET(UCAT.CATALOG) ALIAS -
INTOEMPTY -
CATALOG(CATALOG.Z112S.MASTER)
0IDC0604I DATA SET BEING IMPORTED WAS EXPORTED ON 10/31/11 AT 10:27:45
0IDC3020I UNABLE TO ALLOCATE SPACE ON USER VOLUME
IDC3009I ** VSAM CATALOG RETURN CODE IS 68 - REASON CODE IS IGG0CLEW-192
0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
When I look these messages up, its not making any sense to me. I tried the user cat on two different volumes and got the same error. The volume SCSYS1 has loads of space on it.
I need to get a user catalog on this 1.12 system with entries in it pointing to my datasets on the 3390's. What is the best way to proceed? I've got a volume backup of the volume with the 1.10 user cat on it, and could do a volume restore again. I could go back to the 1.10 system and do an EXPORT there, then move the exported copy to the 1.12 system. What works? Any help or advice would be appreciated.
--Dave Day
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
I logged off and logged back on with one of the new TSO userid's defined on the 1.12 system. The logon id was the same as one defined on the 1.10 system. Almost immediately started getting various errors when trying to allocate new datasets using ISPF 3.2 with a hlq that would match one of the alias entries in the user catalog. The errors would occur if I did not specify a volser on the allocate. If I directed it towards a volume, as long as space was on the volume, everything was ok. The goofy part about this is that I would get error messages on my TSO terminal indicating an error while trying to allocate, but after hitting the enter key, the dataset would get allocated.
My thought was that a 1.10 catalog was not compatible with 1.12, and that I had screwed up by just doing the IMPORT CONNECT on the existing catalog that came with the volume restore. But I can't get rid of it. Everything I try fails. Early on I did an EXPORT of the catalog, and that worked fine. I then tried an IMPORT, since the manual states the catalog is deleted and re-defined in this operation, but the IMPORT
fails. Error says it cannot open the catalog.
I then deleted the alias entries for the user cat, and did an EXPORT DISCONNECT of the user cat from the master cat. Return code 0 from both. I then defined another user cat on a different volume, and tried an IMPORT of the exported copy. Job got errors. The original user cat was named UCAT.CATALOG1 on volume VPWRKF. The new user cat is UCAT.CATALOG on volume SCSYS1. Am getting these errors from the job:
IEC614I CREATE FAILED - RC 192, DIAGNOSTIC INFORMATION IS (04160055) ,
STEP1,VPWRKF,UCAT.CATALOG1
Idcams output is:
IMPORT INFILE(RECEIVE) OUTDATASET(UCAT.CATALOG) ALIAS -
INTOEMPTY -
CATALOG(CATALOG.Z112S.MASTER)
0IDC0604I DATA SET BEING IMPORTED WAS EXPORTED ON 10/31/11 AT 10:27:45
0IDC3020I UNABLE TO ALLOCATE SPACE ON USER VOLUME
IDC3009I ** VSAM CATALOG RETURN CODE IS 68 - REASON CODE IS IGG0CLEW-192
0IDC3003I FUNCTION TERMINATED. CONDITION CODE IS 12
When I look these messages up, its not making any sense to me. I tried the user cat on two different volumes and got the same error. The volume SCSYS1 has loads of space on it.
I need to get a user catalog on this 1.12 system with entries in it pointing to my datasets on the 3390's. What is the best way to proceed? I've got a volume backup of the volume with the 1.10 user cat on it, and could do a volume restore again. I could go back to the 1.10 system and do an EXPORT there, then move the exported copy to the 1.12 system. What works? Any help or advice would be appreciated.
--Dave Day
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
McKown, John
Oct 31, 2011, 4:37:58 PM10/31/11
to
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT2R1A0/6.9.1
04160055 on the CREATE appears to be the answer:
<quote>
Verify that SMS flags passed by the caller match those in the FMT4 DSCB; FMT4 DSCB indicates volume is SMS-managed, but data set is not SMS-managed.
</quote>
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Lizette Koehler
Oct 31, 2011, 4:43:02 PM10/31/11
to
>In moving data from one z/OS system to another, I have somehow hosed up a catalog. The orignal system was at z/Os 1.10, the new system is at 1.12. I moved 8 3390 volumes using ADRDSSU dump and restore, and this looked like it worked well. One of the 3390's I moved had a user catalog on it that contained the catalog entries for the datasets on the moved volumes. I executed an IMPORT CONNECT to connect the ADCD system's master to the user, then did DEFINE ALIAS for the alias entries. Everything looked good at this point. I could find my existing datasets on the volumes using the catalog. Up until then I was working as IBMUSER.
>
>I logged off and logged back on with one of the new TSO userid's defined on the 1.12 system. The logon id was the same as one defined on the 1.10 system. Almost immediately started getting various errors when trying to allocate new datasets using ISPF 3.2 with a hlq that would match one of the alias entries in the user catalog. The errors would occur if I did not specify a volser on the allocate. If I directed it towards a volume, as long as space was on the volume, everything was ok. The goofy part about this is that I would get error messages on my TSO terminal indicating an error while trying to allocate, but after hitting the enter key, the dataset would get allocated.
>
>My thought was that a 1.10 catalog was not compatible with 1.12, and that I had screwed up by just doing the IMPORT CONNECT on the existing catalog that came with the volume restore. But I can't get rid of it. Everything I try fails. Early on I did an EXPORT of the catalog, and that worked fine. I then tried an IMPORT, since the manual states the catalog is deleted and re-defined in this operation, but the IMPORT
>fails. Error says it cannot open the catalog.
>
>I then deleted the alias entries for the user cat, and did an EXPORT DISCONNECT of the user cat from the master cat. Return code 0 from both. I then defined another user cat on a different volume, and tried an IMPORT of the exported copy. Job got errors. The original user cat was named UCAT.CATALOG1 on volume VPWRKF. The new user cat is UCAT.CATALOG on volume SCSYS1. Am getting these errors from the job:
>
I would look at the esoterics, acs routines.
>
>I logged off and logged back on with one of the new TSO userid's defined on the 1.12 system. The logon id was the same as one defined on the 1.10 system. Almost immediately started getting various errors when trying to allocate new datasets using ISPF 3.2 with a hlq that would match one of the alias entries in the user catalog. The errors would occur if I did not specify a volser on the allocate. If I directed it towards a volume, as long as space was on the volume, everything was ok. The goofy part about this is that I would get error messages on my TSO terminal indicating an error while trying to allocate, but after hitting the enter key, the dataset would get allocated.
>
>My thought was that a 1.10 catalog was not compatible with 1.12, and that I had screwed up by just doing the IMPORT CONNECT on the existing catalog that came with the volume restore. But I can't get rid of it. Everything I try fails. Early on I did an EXPORT of the catalog, and that worked fine. I then tried an IMPORT, since the manual states the catalog is deleted and re-defined in this operation, but the IMPORT
>fails. Error says it cannot open the catalog.
>
>I then deleted the alias entries for the user cat, and did an EXPORT DISCONNECT of the user cat from the master cat. Return code 0 from both. I then defined another user cat on a different volume, and tried an IMPORT of the exported copy. Job got errors. The original user cat was named UCAT.CATALOG1 on volume VPWRKF. The new user cat is UCAT.CATALOG on volume SCSYS1. Am getting these errors from the job:
>
Does the Ucat on 1.10 have the same esoteric name in the 1.12 system? Does it define the same volume type that it was backed up from?
Does the ACS code on 1.10 provide the same elements under 1.12?
Did you indicate NOSMS in the DFDSS restore? NULLMGMTCLAS or NULLSTORCLAS or BYPASSACS(dsn{,dsn...})}
Lizette
Dave Day
Oct 31, 2011, 4:54:23 PM10/31/11
to
I don't understand. What needs to be done with SMS? SMS was active on the
originating 1.10 system, and is active on the 1.12 system. The 1.12 system
is an ADCD system supplied by IBM, but I haven't done anything to SMS on
that 1.12 system yet. I had thought I could get my 3390's moved and set up
on the new system, and then worry about SMS.
--Dave
originating 1.10 system, and is active on the 1.12 system. The 1.12 system
is an ADCD system supplied by IBM, but I haven't done anything to SMS on
that 1.12 system yet. I had thought I could get my 3390's moved and set up
on the new system, and then worry about SMS.
--Dave
McKown, John
Oct 31, 2011, 5:03:13 PM10/31/11
to
Sounds like the volumes are indicated as SMS managed in the VTOC, but you likely have not added them to a STORAGE GROUP in your new SMS environment. If they were previously SMS managed, they have an SMS indicator in the VTOC. When you try to allocate to them now, if the dataset is not SMS managed, and your z/OS doesn't have the volume listed in an existing Storage Group, then DADSM allocation gets upset. Bottom line: put the previously managed SMS volumes into a storage group on your current system. I don't know which one because I've never worked with ADCD (or ACDC <grin>).
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Staller, Allan
Oct 31, 2011, 5:04:42 PM10/31/11
to
This message, which is pretty explicit, seems to indicate that the
source volume is SMS managed and the target volume is not (or
vice-versa).
You might want to do a LISTCAT ALL on the source system to verify the
correct MGMTCLAS, STORCLAS, DATACLAS and ensure the same
MGMTCLAS, STORCLAS, DATACLAS are available on the target system.
Even easier, Import connect the source catalog on the target system
(forget about the dump/restore).
HTH,
<snip>
I don't understand. What needs to be done with SMS? SMS was active on
the
originating 1.10 system, and is active on the 1.12 system. The 1.12
system
is an ADCD system supplied by IBM, but I haven't done anything to SMS on
that 1.12 system yet. I had thought I could get my 3390's moved and set
up
on the new system, and then worry about SMS.
</snip>
<snip>
</snip>
source volume is SMS managed and the target volume is not (or
vice-versa).
You might want to do a LISTCAT ALL on the source system to verify the
correct MGMTCLAS, STORCLAS, DATACLAS and ensure the same
MGMTCLAS, STORCLAS, DATACLAS are available on the target system.
Even easier, Import connect the source catalog on the target system
(forget about the dump/restore).
HTH,
<snip>
I don't understand. What needs to be done with SMS? SMS was active on
the
originating 1.10 system, and is active on the 1.12 system. The 1.12
system
is an ADCD system supplied by IBM, but I haven't done anything to SMS on
that 1.12 system yet. I had thought I could get my 3390's moved and set
up
on the new system, and then worry about SMS.
<snip>
Dave Day
Oct 31, 2011, 5:14:07 PM10/31/11
to
Thank you for the response. Now it makes more sense. Heading for the SMS
manuals now. Thanks again.
manuals now. Thanks again.
Shmuel Metz , Seymour J.
Nov 1, 2011, 9:35:47 AM11/1/11
to
In <DA318920B9244C388DAFF6C0D16D6E12@duke1>, on 10/31/2011
>I had thought I could get my 3390's moved and set up
>on the new system, and then worry about SMS.
Not if you flag the volumes as SMS managed. Make them non-SMS and give
them appropriate mount attributes until you're ready to set up SMS.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
at 03:51 PM, Dave Day <davi...@CONSOLIDATED.NET> said:
>I don't understand. What needs to be done with SMS? SMS was active
>on the originating 1.10 system, and is active on the 1.12 system.
Active with what ACS and storage groups?
>I don't understand. What needs to be done with SMS? SMS was active
>on the originating 1.10 system, and is active on the 1.12 system.
>I had thought I could get my 3390's moved and set up
>on the new system, and then worry about SMS.
them appropriate mount attributes until you're ready to set up SMS.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)
0 new messages