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.mck...@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

 

> -----Original Message-----
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Dave Day
> Sent: Monday, October 31, 2011 3:51 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Help with a catalog problem
> 
> 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
> ----- Original Message ----- 
> From: "McKown, John" <john.mck...@healthmarkets.com>
> Newsgroups: bit.listserv.ibm-main
> To: <IBM-MAIN@bama.ua.edu>
> Sent: Monday, October 31, 2011 3:36 PM
> Subject: Re: Help with a catalog problem
> 
> 
> >> -----Original Message-----
> >> From: IBM Mainframe Discussion List
> >> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Dave Day
> >> Sent: Monday, October 31, 2011 3:21 PM
> >> To: IBM-MAIN@bama.ua.edu
> >> Subject: Help with a catalog problem
> >>
> >> 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
> >>
> > From:
> > 
> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DGT
> 2R1A0/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.mck...@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
> >
> >
> >
> > 
> ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: GET 
> IBM-MAIN INFO
> > Search the archives at http://bama.ua.edu/archives/ibm-main.html 
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> 
> 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to