Re: Allocation mystery

2012-06-01 Thread Shmuel Metz (Seymour J.) 
In <4fc7e1b0.6070...@trainersfriend.com>, on 05/31/2012
   at 03:25 PM, Steve Comstock  said:

>I'm finding an unexpected allocation situation
>that maybe someone can explain.

Are all of your datasets supposed to be SMS managed? If so, there is
an ACS issue. If not, it has always worked that way.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Allocation mystery

2012-06-01 Thread Paul Gilmartin 
On Thu, 31 May 2012 19:31:04 -0600, Steve Comstock wrote:
>
>> Something has to specify the UNIT.  Does "LIKE" establish the
>> UNIT but not the VOL?  Strange.
>
>LIKE establishes neither; UNIT comes from the system default
>unit, usually SYSALLDA; VOL is chosen from available storage
>volumes.
> 
Humph!  I tried your DD statement on 1.12, without "LIKE":

 3 //STEP EXEC  PGM=IEFBR14 
 
 4 //NEWMASTDD  DISP=(NEW,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA  
   
 IEF210I JOBCARD STEP NEWMAST - UNIT FIELD SPECIFIES INCORRECT DEVICE NAME  
 IEF272I JOBCARD STEP - STEP WAS NOT EXECUTED.  
 
... so our system default is either not specified or misspecified.

M&C says:

#2.121 "z/OS V1R12.0 MVS System Messages, Vol 8 (IEF-IGD)" IBM Libra.. (p1 of 
3) 
   Library View Topics Framed Contents Revised Topics Previous Topic Next   
 
   Topic Search Search Results Previous Topic Match Next Topic Match Notes  
 
   List Notes Print Download Download PDF Handheld Disconnected Handheld
 
   Connected Help   
 
 ___
 

 
2.121 IEF210I   


 
   Explanation: In a DD statement, the unit name subparameter in the UNIT   
 
   parameter was incorrect: 
 

 
 * The unit is not defined to the current system configuration, or a
 
   demand request for a unit being added to the configuration occurred  
 
   prior to the dynamic configuration change completing.
 
 * If the DD statement specified a cataloged data set, the unit field   
 
   in the catalog entry is incorrect.   
 
 * The DD statement did not contain a UNIT parameter for a  
 
   non-cataloged, non-passed data set.  
 
 * The DD statement did not contain a DISP parameter, indicating a new  
 
   data set, and did not contain a UNIT parameter, indicating an old
 
   data set. 

It would be helpful if the message identified the incorrect unit name
and its provenance, and distinguished among the 4 cases (5, actually:
the first represents 2) in the bullets.  But that would be a step toward
self-explanatory messages, and I know the modal view on this forum
is that messages should _not_ be self-explanatory.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Allocation mystery

2012-05-31 Thread Steve Comstock 

On 5/31/2012 4:13 PM, Thomas Conley wrote:

On 5/31/2012 5:26 PM, Steve Comstock wrote:

I'm finding an unexpected allocation situation
that maybe someone can explain.

I run a job that creates a new data set using
this DD statement:

//NEWMAST DD DISP=(NEW,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA,
// LIKE=STNT329.TRAIN.ZINPUTA

Job runs fine and creates the new file.

Now I run it again; I expect it to fail with 'DUPLICATE
DATA SET NAME' - but it doesn't. Instead, it goes ahead
and allocates the file on a storage volume and gives me
a zero completion code; just doesn't catalog the data
set.

I find this a change (but maybe it's been that way for
some time). And potentially disasterous:

suppose a multi-step job creates a file in the first
step, and it gets created but not cataloged; but
the completion code is zero. Second step references
the new dataset, but it gets the old version because
that's what's in the catalog.

Any hints or insights here?




Steve,

Check out the ALLOCxx member, the duplicate dataset parms are in there.

Tom



I'll check it out. Thanks.


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Allocation mystery

2012-05-31 Thread Steve Comstock 

On 5/31/2012 4:59 PM, Paul Gilmartin wrote:

On Thu, 31 May 2012 21:45:54 +, Gibney, Dave wrote:


There is a parmlib option to abend NOT CATLG 2. I recommend using it.


Would this cause the ABEND at the beginning or at the end of the job step?
The latter would be suboptimal.


IMO, SMS should be set up for all allocations and the fallback pathway to storage volumes 
blocked. Back in the "old days", we did experience the scenario you describe. 
After the same dataset name appeared on all available volumes, then the abend would occur.

I am also a strong believer in the philosophy "If it ain't cataloged, it doesn't 
exist". I feel free to whack any such I find in the application storage pools. They 
have always (so far) been the result of an error.


Sounds good.


On Thu, 31 May 2012 15:25:04 -0600, Steve Comstock wrote:


I run a job that creates a new data set using
this DD statement:

//NEWMASTDD  DISP=(NEW,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA,
//   LIKE=STNT329.TRAIN.ZINPUTA


Something has to specify the UNIT.  Does "LIKE" establish the
UNIT but not the VOL?  Strange.


LIKE establishes neither; UNIT comes from the system default
unit, usually SYSALLDA; VOL is chosen from available storage
volumes.



On occasion, when I want to create a data set if it doesn't exist
or reuse it if it does, I code, e.g.:

//ALLOCDD  DISP=(MOD,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA,
//   LIKE=STNT329.TRAIN.ZINPUTA
//*
//NEWMASTDD  DISP=SHR,DSN=*.ALLOC,VOL=REF=*.ALLOC

Would this fail if SMS-managed or "ABEND on NOT CATLGD 2" were
in effect?

I could use the well-known trick of "DISP=(MOD,DELETE)" in a
previous IEFBR14 step, but that would lose existing members if
the data set is a PDS.

-- gil




--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Allocation mystery

2012-05-31 Thread Paul Gilmartin 
On Thu, 31 May 2012 21:45:54 +, Gibney, Dave wrote:

>There is a parmlib option to abend NOT CATLG 2. I recommend using it.
> 
Would this cause the ABEND at the beginning or at the end of the job step?
The latter would be suboptimal.

>IMO, SMS should be set up for all allocations and the fallback pathway to 
>storage volumes blocked. Back in the "old days", we did experience the 
>scenario you describe. After the same dataset name appeared on all available 
>volumes, then the abend would occur.
>
>I am also a strong believer in the philosophy "If it ain't cataloged, it 
>doesn't exist". I feel free to whack any such I find in the application 
>storage pools. They have always (so far) been the result of an error.
> 
Sounds good.

>> On Thu, 31 May 2012 15:25:04 -0600, Steve Comstock wrote:
>>
>> >I run a job that creates a new data set using
>> >this DD statement:
>> >
>> >//NEWMASTDD  DISP=(NEW,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA,
>> >//   LIKE=STNT329.TRAIN.ZINPUTA
>> >
Something has to specify the UNIT.  Does "LIKE" establish the
UNIT but not the VOL?  Strange.

On occasion, when I want to create a data set if it doesn't exist
or reuse it if it does, I code, e.g.:

//ALLOCDD  DISP=(MOD,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA,
//   LIKE=STNT329.TRAIN.ZINPUTA
//*
//NEWMASTDD  DISP=SHR,DSN=*.ALLOC,VOL=REF=*.ALLOC

Would this fail if SMS-managed or "ABEND on NOT CATLGD 2" were
in effect?

I could use the well-known trick of "DISP=(MOD,DELETE)" in a
previous IEFBR14 step, but that would lose existing members if
the data set is a PDS.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Allocation mystery

2012-05-31 Thread Thomas Conley 

On 5/31/2012 5:26 PM, Steve Comstock wrote:

I'm finding an unexpected allocation situation
that maybe someone can explain.

I run a job that creates a new data set using
this DD statement:

//NEWMAST DD DISP=(NEW,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA,
// LIKE=STNT329.TRAIN.ZINPUTA

Job runs fine and creates the new file.

Now I run it again; I expect it to fail with 'DUPLICATE
DATA SET NAME' - but it doesn't. Instead, it goes ahead
and allocates the file on a storage volume and gives me
a zero completion code; just doesn't catalog the data
set.

I find this a change (but maybe it's been that way for
some time). And potentially disasterous:

suppose a multi-step job creates a file in the first
step, and it gets created but not cataloged; but
the completion code is zero. Second step references
the new dataset, but it gets the old version because
that's what's in the catalog.

Any hints or insights here?




Steve,

Check out the ALLOCxx member, the duplicate dataset parms are in there.

Tom

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Allocation mystery

2012-05-31 Thread Gibney, Dave 
There is a parmlib option to abend NOT CATLG 2. I recommend using it.

IMO, SMS should be set up for all allocations and the fallback pathway to 
storage volumes blocked. Back in the "old days", we did experience the scenario 
you describe. After the same dataset name appeared on all available volumes, 
then the abend would occur.

I am also a strong believer in the philosophy "If it ain't cataloged, it 
doesn't exist". I feel free to whack any such I find in the application storage 
pools. They have always (so far) been the result of an error. 

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Tom Marchant
> Sent: Thursday, May 31, 2012 2:38 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Allocation mystery
> 
> On Thu, 31 May 2012 15:25:04 -0600, Steve Comstock wrote:
> 
> >I run a job that creates a new data set using
> >this DD statement:
> >
> >//NEWMASTDD  DISP=(NEW,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA,
> >//   LIKE=STNT329.TRAIN.ZINPUTA
> >
> >Job runs fine and creates the new file.
> 
> Is the data set SMS managed?
> 
> >Now I run it again; I expect it to fail with 'DUPLICATE
> >DATA SET NAME' - but it doesn't. Instead, it goes ahead
> >and allocates the file on a storage volume and gives me
> >a zero completion code; just doesn't catalog the data
> >set.
> 
> Storage volume suggests that it is allocated to a non-managed
> volume.  This is not unusual.  Did you receive a NOT CATLGD 2
> message?
> 
> --
> Tom Marchant
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Allocation mystery

2012-05-31 Thread Tom Marchant 
On Thu, 31 May 2012 15:25:04 -0600, Steve Comstock wrote:

>I run a job that creates a new data set using
>this DD statement:
>
>//NEWMASTDD  DISP=(NEW,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA,
>//   LIKE=STNT329.TRAIN.ZINPUTA
>
>Job runs fine and creates the new file.

Is the data set SMS managed?

>Now I run it again; I expect it to fail with 'DUPLICATE
>DATA SET NAME' - but it doesn't. Instead, it goes ahead
>and allocates the file on a storage volume and gives me
>a zero completion code; just doesn't catalog the data
>set.

Storage volume suggests that it is allocated to a non-managed 
volume.  This is not unusual.  Did you receive a NOT CATLGD 2 
message?

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Allocation mystery

2012-05-31 Thread Steve Comstock 

I'm finding an unexpected allocation situation
that maybe someone can explain.

I run a job that creates a new data set using
this DD statement:

//NEWMASTDD  DISP=(NEW,CATLG),DSN=&SYSUID..WORK.NEW.ZINPUTA,
//   LIKE=STNT329.TRAIN.ZINPUTA

Job runs fine and creates the new file.

Now I run it again; I expect it to fail with 'DUPLICATE
DATA SET NAME' - but it doesn't. Instead, it goes ahead
and allocates the file on a storage volume and gives me
a zero completion code; just doesn't catalog the data
set.

I find this a change (but maybe it's been that way for
some time). And potentially disasterous:

suppose a multi-step job creates a file in the first
step, and it gets created but not cataloged; but
the completion code is zero. Second step references
the new dataset, but it gets the old version because
that's what's in the catalog.

Any hints or insights here?


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN