In my shop I have a 3390 type 3 online DASD volume, but nothing gets allocated on that pack.
Can some one kindly let me know what can be problem, I approached the concern team they also not much sure what preventing the files getting allocated on that particular volume
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Since the volume is NOT managed by SMS, you have to specify the volume serial and UNIT when allocating a data set to that volume. You will need to post the JCL you are using and the message(s) you are getting back when attempting to allocate to the volume.
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
I would not be surprised to find that ISPF 3.2 allocation will be through SMS only unless you override the allocation on the screen.
What is not working -- what messages are you getting? Even if the job never starts executing, there should be some JES messages (if not z/OS) to indicate more about what is going on. Has the volume been varied online to JES?
I would not be surprised to find that ISPF 3.2 allocation will be through SMS only unless you override the allocation on the screen.
Yes Robert, even I override the volume in the "Volume serial . . . . CICSJ2" it is not getting allocated rather allocated on some other volume. And I get the message dataset successfully allocated.
What is not working -- what messages are you getting? Even if the job never starts executing, there should be some JES messages (if not z/OS) to indicate more about what is going on. Has the volume been varied online to JES?[
Yes the volume is Varied online to JES.
My JES messages are normal. Finally when I look at my sysmsg it tells the gdg got cataloged on some other volume.
IEF285I XXXX.XXXXX.XXXXX.G0003V00 CATALOGED
IEF285I VOL SER NOS= CICSJ1,DB0040
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
Code:
Management class . . . MCUSERSM (Blank for default management class)
Storage class . . . . SCUSER (Blank for default storage class)
Volume serial . . . . PGMRS4 (Blank for system default volume) **
Device type . . . . . (Generic unit or device address) **
Data class . . . . . . (Blank for default data class)
Space units . . . . . CYLINDER (BLKS, TRKS, CYLS, KB, MB, BYTES
or RECORDS)
Average record unit (M, K, or U)
Primary quantity . . 8 (In above units)
Secondary quantity 5 (In above units)
Directory blocks . . 75 (Zero for sequential data set) *
Record format . . . . FB
Record length . . . . 120
Block size . . . . .
Data set name type PDS (LIBRARY, HFS, PDS, LARGE, BASIC, *
EXTREQ, EXTPREF or blank)
Expiration date . . . (YY/MM/DD, YYYY/MM/DD
Enter "/" to select option YY.DDD, YYYY.DDD in Julian form
Allocate Multiple Volumes DDDD for retention period in days
or blank)
( * Specifying LIBRARY may override zero directory block)
( ** Only one of these fields may be specified)
Unless you override the default Management Class, Storage Class, and Data Class, on this screen, to NOT use SMS -- you will get an SMS allocation and the data set would not be allocatd to CICSJ2. And note that GDG allocations may be specified in your ACS routines and hence default to SMS-managed -- ours are so handled at my site.
You really, really, really need to get with your storage management group at your site and find out what the rules at your site are, and how you can allocate data sets to CICSJ2 volume. We can speculate all we want about the root cause of your problem, but only someone working at your site and able to look at the ACS routines and ISMF rules in effect at your site will ultimately be able to determine what is going on. Somebody needs to look at the storage class assignments in your SCDS file and determine what causes a data set to be non-SMS-managed.
And if you attempt allocation through a batch job, you should see something like
