|
View previous topic :: View next topic
|
| Author |
Message |
Marsellas Wallace
New User
Joined: 18 May 2010
Posts: 3
Location: Bangalore
|
|
|
|
How to allocate a PS file on DASD with a particular Volume serial number?
I tried the below thing but its not working
| Code: |
DISP=(NEW,CATLG,DELETE),UNIT=DASD,SPACE=(CYL,(1,1),RLSE),
DCB=(BUFNO=10,LRECL=80,BLKSIZE=0,RECFM=FB),
VOL=SER=ASH221 |
|
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| You need to be authorised to use the GUARANTEED SPACE storage class set up by your storage management team. |
|
| Back to top |
|
|
Marsellas Wallace
New User
Joined: 18 May 2010
Posts: 3
Location: Bangalore
|
|
|
|
| Yes i am authorised to that, but after that also the file is getting created with volume ASH224 instead of ASH221( as i specified). |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| Yes, but if the ACS routines allocate a STORCLAS to the dataset, that will be the allocated STORCLAS, so to override the ACS routines, you will need to code the guaranteed space STORCLAS in your JCL. |
|
| Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1742
Location: Tirupur, India
|
|
|
|
I tried out the JCL with Management class & Storage class but it just gets to a random volume, I have access to allocate datasets onto ABCD01 - ABCD99,
| Code: |
// DISP=(NEW,CATLG,DELETE),UNIT=DASD,SPACE=(CYL,(1,1),RLSE),
// DCB=(BUFNO=10,LRECL=80,BLKSIZE=0,RECFM=FB),
// VOL=(SER=ABCD06),MGMTCLAS=XXXX,STORCLAS=XXXX |
But the allocated file goes into ABCD09 however ABCD06 was specified on JCL.  |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
You need to contact your site support group for assistance. Depending upon how your SMS routines are set up, it may or may not be possible for you to allocate a data set on volume ABCD06. Only your space management people can tell you for sure.
The more important question is, why do you think you need to do this? SMS manages space within storage pools and as long as the data set is allocated why do you care which volume is used? Answer: unless you're doing something extremely rare or extremely stupid, you don't care. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
Yep, you are correct Robert. My brain is still getting back to work mode after a nice long weekend up in north Yorkshire. They will need to contact the storage people.
As I said so many times in the past, if the ACS routines are correctly set up, you may be allowed to code a particular STORCLAS in the JCL but this does not mean that it will be honoured. I usually go that route, so unless the user is authorised to use that STORCLAS my ACS routines will ignore what is coded and set the default. However it will issue a message to the user telling them what has happened.
Oh, how nice to be back at work  |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| Quote: |
Answer: unless you're doing something extremely rare or extremely stupid, you don't care.
|
Robert,
why is that? How about dedicated volumes for special datasets? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
As a system programmer, I allocate to specific volumes far more frequently than an application person. And I do so maybe half a dozen times a year, maximum -- SYSRES data sets, mostly, that are not SMS-managed. If I were setting up a brand new LPAR, I might need a couple of dozen data sets on specific volumes (JES data sets for example), but again it is rare to set up a completely new LPAR (at least here).
From the posts already made by the o/p, it is obvious the data set allocation is being done to a storage pool -- and it would be very rare that allocation to a specific volume within that storage pool would be needed since the whole point of the concept of the storage pool is that you don't care which volume the data set is on. The only other reason I can think of wanting to allocate a data set on a specific volume within a storage pool would be to be able to find it without the catalog (which makes no sense for SMS-managed data sets). Furthermore, as soon as HSM has migrated and restored the data set, it could be on any volume of the storage pool -- so why try to put it on a specific volume anyway? |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Robert,
thanks for the explanation. Thats the way i see it too.
But im still not sure how you and expat made the conclusion that
the TS was defining a dataset on a SMS volume, but then if i wanted to
do something like that my storage friends helped my out. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
But im still not sure how you and expat made the conclusion that
the TS was defining a dataset on a SMS volume, |
Peter: the JCL Vasanth posted is definitely using SMS-managed storage -- MGMTCLAS and STORCLAS indicate that. The o/p JCL doesn't explicitly indicate SMS management, but the fact that the volume-specific allocation failed but allocated to a different volume is a pretty good sign the SMS management routines were affecting the allocation. If the allocation had just failed without going to a different volume, I'd think of space issues. But with the behavior indicated, it's almost always going to be SMS determining the allocation volume. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| Mmmmmmmm, in the past I have moved datasets onto specific volumes for performance reasons, but with the speed of modern DASD, additional cahing and things, DFW it is a rare occasion when that is needed. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Robert, expat
thanks for the answers.
And because i missed the MGMTCLAS and STORCLAS post of the TS
i made the mistake of bothering you so much. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Peter: it's no bother. Better to clarify doubts now than possibly having an answer misunderstood some years from now! I'm not a storage expert like expat, but I am a jack-of-all-trades for my site (CICS, PGP, FTP, and operational CA-7 issues so far this week)!  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Expat,
| Quote: |
| in the past I have moved datasets onto specific volumes for performance reasons |
When a specific volume was really a specific volume . . . Not some magic set of bits carved from multiple non-3390 dasd (striped/raid) acting like it is a 3390.
Ah, remember device and channel separation? Remember allocating near the center of the platter rather than the "front" or "back" to reduce head motion. . .
And removable dasd media. . .
And. . .
 |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| diskettes Dick? |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
Aaaah Dick, Nostalgia just isn't the same these days 
Even with the RAID DASD we put certain datasets on certain volumes within a STORGRP which was spread across multiple subsystems. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Peter,
We had dasd in the 60's (2311's and 2314's on IBM and some kind of non-removable, sealed drives on Burroughs)
In my world diskettes weren't part of the system until the '70's. And our first ones were 8-inch. . .
d |
|
| Back to top |
|
|
|
|
