When I was a Storage Admin I fixed or changed the Management Class for
datasets that had this problem. If the batch window is blowing out because
of this problem then there is something wrong with the SMS policies. IEFBR14
and DFSMShsm are just innocent bystanders.
I fear we're losing the
Edward Jaffe wrote:
snip
Such assumptive, non-canonical, lazy programming seems to work in most
cases, but can lead to failure and confusion in others. I eliminate it
whenever I can. I regard such code as inelegant, yet convenient,
short-cuts that work most of the time. Kludge.
I fear we're
On Mon, 7 Dec 2009 09:08:28 -0500, John Eells wrote:
- A change control record must be opened, and the change justified and
approved.
- The change has to be made, tested, and documented.
- The documentation has to be reviewed and accepted by production control.
- The job has to be changed in the
John Eells wrote:
Edward Jaffe wrote:
snip
Such assumptive, non-canonical, lazy programming seems to work in
most cases, but can lead to failure and confusion in others. I
eliminate it whenever I can. I regard such code as inelegant, yet
convenient, short-cuts that work most of the time.
Well, I disagree about the kluge part, (it solves the problem for which
the requirements were written), but disgarding that ...
It is, in my opinion, too special a case.
IF PGM=='IEFBR14' VOL(DSN) == 'MIGRAT' THEN DO;
COMMAND(HDEL DSN);
END;
ELSE DO;
ACTION(ALLOCATE DSN);
END;
On Sat, 5 Dec 2009 23:57:23 -0800, Edward Jaffe wrote:
The kludge in this case is the hard-coded checking for PGM=IEFBR14 with
the presumption that this program is always the IBM-supplied utility;a
reliance on common practice rather than certainty; the establishment of
(what I believe to be) a
Paul Gilmartin wrote:
I understand. But would you propose an alternative?
-- gil
How about adding support for DISP=(REPLACE,DELETE) or DISP=(DELETE,DELETE)?
Either would essentially delete the dataset exists, and then allocate
the dataset as new. This would also allow the construct
On Sun, 6 Dec 2009 12:35:32 -0800, Jim Phoenix wrote:
How about adding support for DISP=(REPLACE,DELETE) or DISP=(DELETE,DELETE)?
What effect would these have on JFCB, TIOT, etc.?
Either would essentially delete the dataset exists, and then allocate
the dataset as new. This would also allow
A little plug for z/OS V1R11:
It contains a new setting in ALLOCxx to tell Allocation to not recall a
data set before deletion, when the program name is IEFBR14 and the
DISP=(OLD,DELETE) or DISP=(MOD,DELETE). Look for the
IEFBR14_DELMIGDS(NORECALL) setting in Initialization and Tuning
A little plug for z/OS V1R11:
It contains a new setting in ALLOCxx to tell Allocation to not recall a
data set before deletion, when the program name is IEFBR14 and the
DISP=(OLD,DELETE) or DISP=(MOD,DELETE). Look for the
IEFBR14_DELMIGDS(NORECALL) setting in Initialization and Tuning
error.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of McKown, John
Sent: Friday, December 04, 2009 11:39 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IDCAMS Delete via DD
Why do you even want to do that??? Use IEFBR14 instead
PM
Newsgroups: bit.listserv.ibm-main
Subject: Re: IDCAMS Delete via DD
A little plug for z/OS V1R11:
It contains a new setting in ALLOCxx to tell Allocation to not recall a
data set before deletion, when the program name is IEFBR14 and the
DISP=(OLD,DELETE) or DISP=(MOD,DELETE). Look
IF MAXCC = 8 THEN SET MAXCC = 0
just in case some totally unexpected error happens in IDCAMS.
You can sometimes get an RC=4 -- not necessarily for delete.
So I do:
IF MAXCC 9 THEN SET MAXCC = 0
-
Too busy driving to stop for gas!
Well, I disagree about the kluge part, (it solves the problem for which
the requirements were written), but disgarding that ...
How often does this very big hole occur? Does it make the function
unusable? (I'm really curious, not being argumentative). When the data
set is not deleted and
DanD wrote:
Yes Ted, it`s a very big kluge with a very big hole.
I am waiting to see what they do to correct the issue.
For those that don`t know what the hole is...
If the job goes into allocation recovery or for whatever other reason the
DISP=(OLD,DELETE) migrated data set gets recalled prior
I'm drawing a blank here;
when deleting sequential files (non-vsam) is it possible to use a DD
reference in the IDCAMS cards instead of coding the actual dataset name
in the DELETE statement? The example below doesn't seem to work for
me.
Note: it's been awhile since I've had to use IDCAMS
, December 04, 2009 1:34 PM
To: IBM-MAIN@bama.ua.edu
Subject: IDCAMS Delete via DD
I'm drawing a blank here;
when deleting sequential files (non-vsam) is it possible to use a DD
reference in the IDCAMS cards instead of coding the actual
dataset name
in the DELETE statement? The example below
Subject: Re: IDCAMS Delete via DD
Why do you even want to do that??? Use IEFBR14 instead, with
DISP=(MOD,DELETE). Or, as I do:
//STEP1 EXEC PGM=IKJEFT01,
// PARM='DEL DSN'
//SYSTSIN DD DUMMY
//SYSTSPRT DD SYSOUT=*
If your reason is to pass the DSN via a PROC parm or a JCL SET symbol.
Use IKJEFT1B
, December 04, 2009 1:51 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IDCAMS Delete via DD
Because I won't know if the dataset will be cataloged or not,
hence the
use of IDCAMS to avoid a JCL error.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu
OK, cool. I'll try it.
Thanks
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of McKown, John
Sent: Friday, December 04, 2009 12:05 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IDCAMS Delete via DD
Using DISP=(MOD,DELETE) will work
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
McKown, John
Sent: Friday, December 04, 2009 14:39
To: IBM-MAIN@bama.ua.edu
Subject: Re: IDCAMS Delete via DD
Why do you even want to do that??? Use IEFBR14 instead, with DISP=(MOD,DELETE).
Or, as I do
21 matches
Mail list logo
