Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 03/13/2008
   at 09:18 AM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>So, in deleting a VSAM data set HDELETE apparently exploited information
>which this thread earlier alleged is available only after the data set is
>recalled.

No, it alleged that the data were unavailable *to IDCAMS*.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Rick Fochtman]

-


Thank you for improving my understanding.

But still ...

It appears that the consensus of this thread is that in the absence
of the NONVSAM option, IDCAMS converts a DELETE request for a migrated
data set to HDELETE.  If IDCAMS doesn't know whether the migrator is
HSM, FDRABR, or some other product, how does it know what component
to issue the converted DELETE to?
 


-
I would estimate, with absolutely NO facts to back my estimate, that 
rather than issuing a true "HDELETE" command, that IDCAMS is using smoe 
sort of subsystem interface call. That being the case, a mnigrator, 
whether HSM, ABR or whatever, would also accept the request via the same 
mechanism. As for knowing whether the target is a VSAM cluster or a 
non-VSAM dataset, what difference does it make, as long as the 
"migrator" can locate the name, and thus the data to be deleted?


--


If the interfaces are compatible and, as I still believe, the migrator
must know the VSAM-ness in order to perform the deletion without recall,
it could as well return that characteristic in response to an HLIST or
equivalent API query.  There's considerable value in avoiding recall
of an entire data set in order to obtain one bit of information.
 



All things considered, what difference does it make? You're still going 
to need to HRECALL (or equivalent) that dataset before you can do 
anything with the contents; we don't, as yet, have a direct I/O 
interface to the migrated form.


HSM and ABR do excellent jobs of storage management; let the "black box" 
do what it does best. :-)


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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 03/12/2008
   at 10:21 PM, "Chase, John" <[EMAIL PROTECTED]> said:

>Perhaps Allocation could be "educated" to issue HDELETE iff the dataset
>is migrated *AND* DISP=(,DELETE) *AND* PGM=IEFBR14.

Bletch! I hope that was intended as a joke.
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Scott Rowe]

In the case of the generic DELETE (without NONVSAM), FDRABR intercepts the 
HDELETE issued by IDCAMS, and it works fine (IIRC).  The interfaces are not 
compatible, I agree that it would be beneficial, but someone (IBM) would have 
to define such an API - and share it with the ISVs - in order to have it work 
that way.

>>> Paul Gilmartin <[EMAIL PROTECTED]> 3/13/2008 12:53 PM >>>
On Thu, 13 Mar 2008 10:59:37 -0400, Scott Rowe wrote:
It appears that the consensus of this thread is that in the absence
of the NONVSAM option, IDCAMS converts a DELETE request for a migrated
data set to HDELETE.  If IDCAMS doesn't know whether the migrator is
HSM, FDRABR, or some other product, how does it know what component
to issue the converted DELETE to?

If the interfaces are compatible and, as I still believe, the migrator
must know the VSAM-ness in order to perform the deletion without recall,
it could as well return that characteristic in response to an HLIST or
equivalent API query.  There's considerable value in avoiding recall
of an entire data set in order to obtain one bit of information.

-- gil

Note that my email domain has changed from jo-annstores.com to joann.com.  
Please update your address book and other records to reflect this change.

CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Paul Gilmartin]

On Thu, 13 Mar 2008 10:59:37 -0400, Scott Rowe wrote:

>I think you are a bit confused, HDELETE does not have a NONVSAM option, IDCAMS 
>does.  At the time of a delete, IDCAMS cannot assume that HSM is the migrator, 
>it could just as easily be FDRABR or some other product.
>
Thank you for improving my understanding.

But still ...

It appears that the consensus of this thread is that in the absence
of the NONVSAM option, IDCAMS converts a DELETE request for a migrated
data set to HDELETE.  If IDCAMS doesn't know whether the migrator is
HSM, FDRABR, or some other product, how does it know what component
to issue the converted DELETE to?

If the interfaces are compatible and, as I still believe, the migrator
must know the VSAM-ness in order to perform the deletion without recall,
it could as well return that characteristic in response to an HLIST or
equivalent API query.  There's considerable value in avoiding recall
of an entire data set in order to obtain one bit of information.

-- gil

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Pommier, Rex R.]

Apparently there is a bit of both going on here.  HSM knows that the
VSAM components are in fact components of a cluster, but if you do a
LISTCAT of a migrated VSAM dataset, whether you LISTCAT the CLUSTER name
or one of the components, it shows the entry is of a nonvsam dataset
type.  LISTCATting the CLUSTER name doesn't show anything about any of
the underlying components.  

Rex 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Paul Gilmartin
Sent: Thursday, March 13, 2008 9:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

On Thu, 13 Mar 2008 04:17:40 -0700, Edward Jaffe wrote:

>Dave Cartwright wrote:
>> No, a VSAM cluster is turned into a flat file on migration and is 
>> cataloged as a NONVSAM dataset on volume MIGRAT.  If its device type 
>> is tape it shows as MIGRAT2, else it's MIGRAT1.
>
>Too bad. That seems like a poor design choice in hindsight given the 
>current topic.
>
Yah.  One would think it would be a single flag bit in either the
catalog or the MCDS well invested.

Why is there a NONVSAM option on HDELETE?  Wouldn't some programmers
find it similarly useful to have NONPDS and NONHFS, etc.?

But, needing to delete several VSAM data sets last night, I HMIGRATED
them first.  I find:

o All 3 components continue to appear in DSLIST, now as volume MIGRAT1.

o An attempt to HDELETE the DATA or INDEX component fails, telling me
  that the operation is prohibited for a component of a VSAM data set.

o HDELETEing the primary entry deletes all 3 components.

So, in deleting a VSAM data set HDELETE apparently exploited information
which this thread earlier alleged is available only after the data set
is recalled.  So, must all VSAM data sets be recalled to be deleted;
and, in fact, all data sets recalled in order to determine whether
they're VSAM on NONVSAM?  I earnestly hope not.  Perhaps inspecting the
first very few blocks suffices to determine whether the data set is
VSAM, in which case HDELETE NONVSAM should be able to exploit a similar
shortcut.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Scott Rowe]

I think you are a bit confused, HDELETE does not have a NONVSAM option, IDCAMS 
does.  At the time of a delete, IDCAMS cannot assume that HSM is the migrator, 
it could just as easily be FDRABR or some other product.

>>> Paul Gilmartin [EMAIL PROTECTED]> 3/13/2008 10:18 AM >> ( mailto:[EMAIL 
>>> PROTECTED]> )
Yah.  One would think it would be a single flag bit in either the
catalog or the MCDS well invested.

Why is there a NONVSAM option on HDELETE?  Wouldn't some programmers
find it similarly useful to have NONPDS and NONHFS, etc.?

But, needing to delete several VSAM data sets last night, I HMIGRATED
them first.  I find:

o All 3 components continue to appear in DSLIST, now as volume MIGRAT1.

o An attempt to HDELETE the DATA or INDEX component fails, telling me
  that the operation is prohibited for a component of a VSAM data set.

o HDELETEing the primary entry deletes all 3 components.

So, in deleting a VSAM data set HDELETE apparently exploited information
which this thread earlier alleged is available only after the data set
is recalled.  So, must all VSAM data sets be recalled to be deleted;
and, in fact, all data sets recalled in order to determine whether
they're VSAM on NONVSAM?  I earnestly hope not.  Perhaps inspecting
the first very few blocks suffices to determine whether the data set
is VSAM, in which case HDELETE NONVSAM should be able to exploit a
similar shortcut.

-- gil



Note that my email domain has changed from jo-annstores.com to joann.com.  
Please update your address book and other records to reflect this change.

CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Paul Gilmartin]

On Thu, 13 Mar 2008 04:17:40 -0700, Edward Jaffe wrote:

>Dave Cartwright wrote:
>> No, a VSAM cluster is turned into a flat file on migration and is cataloged 
>> as a
>> NONVSAM dataset on volume MIGRAT.  If its device type is tape it shows as
>> MIGRAT2, else it's MIGRAT1.
>
>Too bad. That seems like a poor design choice in hindsight given the
>current topic.
>
Yah.  One would think it would be a single flag bit in either the
catalog or the MCDS well invested.

Why is there a NONVSAM option on HDELETE?  Wouldn't some programmers
find it similarly useful to have NONPDS and NONHFS, etc.?

But, needing to delete several VSAM data sets last night, I HMIGRATED
them first.  I find:

o All 3 components continue to appear in DSLIST, now as volume MIGRAT1.

o An attempt to HDELETE the DATA or INDEX component fails, telling me
  that the operation is prohibited for a component of a VSAM data set.

o HDELETEing the primary entry deletes all 3 components.

So, in deleting a VSAM data set HDELETE apparently exploited information
which this thread earlier alleged is available only after the data set
is recalled.  So, must all VSAM data sets be recalled to be deleted;
and, in fact, all data sets recalled in order to determine whether
they're VSAM on NONVSAM?  I earnestly hope not.  Perhaps inspecting
the first very few blocks suffices to determine whether the data set
is VSAM, in which case HDELETE NONVSAM should be able to exploit a
similar shortcut.

-- gil

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Edward Jaffe]

Dave Cartwright wrote:
No, a VSAM cluster is turned into a flat file on migration and is cataloged as a 
NONVSAM dataset on volume MIGRAT.  If its device type is tape it shows as 
MIGRAT2, else it's MIGRAT1.
  


Too bad. That seems like a poor design choice in hindsight given the 
current topic.



I guess you don't get much real HSM work in PWD - no offence intended.
  


We use DFSMShsm for migration, daily backup, and weekly full volume 
dump. However, we have very few VSAM files. And, those that we do have 
rarely get migrated.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe
> 
> [ snip ]
> 
> Hmmm. When a data set is migrated, the VTOC entry is removed. 
> But, the catalog entry is still there (though the volume ID 
> is changed to MIGRAT).
> 
> Can't IDCAMS tell from the catalog whether the migrated data 
> set is VSAM or not? And, if VSAM, what kind of VSAM data set it is??

Apparently not.  Here's a LISTCAT of a migrated VSAM dataset:

NONVSAM --- TECH.CICSTECH.DFHWSBTS
 IN-CAT --- CATALOG.SC02.TECH 
 HISTORY  
   DATASET-OWNER-(NULL) CREATION2007.168

   RELEASE2 EXPIRATION--.000

   ACCOUNT-INFO---(NULL)

 SMSDATA

   STORAGECLASS -SCDEVE MANAGEMENTCLASS---MCDEVE

   DATACLASS (NULL) LBACKUP ---.XXX.

 VOLUMES

   VOLSERMIGRAT DEVTYPE--X'78048083'
FSEQN--0 
 ASSOCIATIONS(NULL)

 ATTRIBUTES

***  

Note the NONVSAM indication on the first line.

Same dataset after HRECALL:

CLUSTER --- TECH.CICSTECH.DFHWSBTS
 IN-CAT --- CATALOG.SC02.TECH 
 HISTORY  
  DATASET-OWNER-(NULL) CREATION2007.163

  RELEASE2 EXPIRATION--.000

SMSDATA

  STORAGECLASS -SCDEVE MANAGEMENTCLASS---MCDEVE

  DATACLASS (NULL) LBACKUP ---.000.

  BWO STATUS-- BWO TIMESTAMP---0 00:00:00.0

  BWO---(NULL)

RLSDATA

  LOG --UNDO   RECOVERY REQUIRED --(NO) FRLOG
(NULL)
  VSAM QUIESCED ---(NO)RLS IN USE -(NO)

  LOGSTREAMID-(NULL)

  RECOVERY TIMESTAMP LOCAL-X''

  RECOVERY TIMESTAMP GMT---X''

PROTECTION-PSWD-(NULL) RACF(NO)

ASSOCIATIONS

  DATA-TECH.CICSTECH.DFHWSBTS.DATA

  INDEXTECH.CICSTECH.DFHWSBTS.INDEX
[ remainder snipped ]

Note this time it's a CLUSTER.

-jc-

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Walt Farrell]

On Wed, 12 Mar 2008 22:21:34 -0500, Chase, John <[EMAIL PROTECTED]> wrote:

>Indeed, how should Allocation know whether the program about to execute
>wants to "do something" with the dataset(s) before deleting it/them?
>Perhaps Allocation could be "educated" to issue HDELETE iff the dataset
>is migrated *AND* DISP=(,DELETE) *AND* PGM=IEFBR14.

And then you'll probably find some shop where they have their own version of
IEFBR14 that actually does process the data set in some way before it
terminates.  Or where another vendor has put some kind of front-end on
IEFBR14 to do something.

Also, I hope you'd want at least DISP=(OLD,DELETE) or DISP=(MOD,DELETE).   I
don't think I'd want existing data sets being deleted when referred to by a
DISP=NEW allocation like that.

-- 
  Walt

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Walter Marguccio]

- Original Message 
From: William Bishop <[EMAIL PROTECTED]>

> The problem is that if you perfrom an IDCAMS DELETE and specify nonvsam, 
> HSM does a recall.  Without the nonvsam, he does an HDELETE if the dataset 
> is migrated.


Correct. We have CA-Disk in place and it behaves the same.
Told our programmers to code 'DEL mydataset' *without* NVSAM.

Walter Marguccio
z/OS Systems Programmer
Munich - Germany



  __
Sent from Yahoo! Mail.
The World's Favourite Email http://uk.docs.yahoo.com/nowyoucan.html

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Dave Cartwright]

On Wed, 12 Mar 2008 22:31:38 -0700, Edward Jaffe 
<[EMAIL PROTECTED]> wrote:

>
>Hmmm. When a data set is migrated, the VTOC entry is removed. But, the
>catalog entry is still there (though the volume ID is changed to MIGRAT).
>
>Can't IDCAMS tell from the catalog whether the migrated data set is VSAM
>or not? And, if VSAM, what kind of VSAM data set it is??
>


No, a VSAM cluster is turned into a flat file on migration and is cataloged as 
a 
NONVSAM dataset on volume MIGRAT.  If its device type is tape it shows as 
MIGRAT2, else it's MIGRAT1.

I guess you don't get much real HSM work in PWD - no offence intended.

Dave

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Edward Jaffe]

Walt Farrell wrote:

On Wed, 12 Mar 2008 11:03:41 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:

  

William Bishop wrote:


The problem is that if you perfrom an IDCAMS DELETE and specify nonvsam,
HSM does a recall.  Without the nonvsam, he does an HDELETE if the dataset
is migrated.

  

This sounds APARable to me.



I don't think so, Ed.  I believe that the presence of "nonvsam" on the
command requires a recall so that IDCAMS can verify that it's a nonvsam
entry (it can't tell that while the data set is migrated).

I believe you'll find that if you had a VSAM file, and issued a DELETE ...
NONVSAM against it that the delete would fail.  Thus, with a migrated data
set IDCAMS needs it recalled or it might mistakenly delete a migrated VSAM
data set.
  


Hmmm. When a data set is migrated, the VTOC entry is removed. But, the 
catalog entry is still there (though the volume ID is changed to MIGRAT).


Can't IDCAMS tell from the catalog whether the migrated data set is VSAM 
or not? And, if VSAM, what kind of VSAM data set it is??


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Chase, John]

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Shmuel Metz (Seymour
J.)
> 
>John Mattson said:
> 
> >Programmers have been deleting for years using BR14 (MOD,DELETE), and

> >IDCAMS DELETE.
> 
> IEFBR14 doesn't delete the data set. By the time IEFBR14 gets 
> control the data set has already been recalled. [ snip ]

Indeed, how should Allocation know whether the program about to execute
wants to "do something" with the dataset(s) before deleting it/them?
Perhaps Allocation could be "educated" to issue HDELETE iff the dataset
is migrated *AND* DISP=(,DELETE) *AND* PGM=IEFBR14.

-jc-

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Arthur T.]

On 12 Mar 2008 17:52:58 -0700, in bit.listserv.ibm-main 
(Message-ID:<[EMAIL PROTECTED]>) 
[EMAIL PROTECTED] (Paul Gilmartin) wrote:


Ages ago, before TSO/IDCAMS was so nearly smart, I coded 
in

Rexx (IIRC):

   address 'TSO'
   'HDELETE ''DATA.SET.NAME'' WAIT'
   if RC<>0 then
   'DELETE ''DATA.SET.NAME'''

Crude, but effective.


 Mine was more complex, but I don't know if it was 
more effective.  There will probably be line-wrap 
problems.  "sysreasn" is an external REXX routine that 
returns the text of LISTDSI reason codes.  The first 
section is my standard entry code to allow me to specify 
variables on the command line.


/*  REXX exec to delete datasets without hrecall  */

arg dsn temp1

do while temp1 \= ''
  parse var temp1 temp2 temp1
  if right(temp2,1) = ')' then
temp2 = translate(temp2,'= ','()')
  if pos('=',temp2) = 0 then temp2 = temp2 || '= ""'
  interpret temp2
end
drop temp1
drop temp2
if debug = 'TRACE' then trace ?i
else if debug \= "DEBUG" then trace i

if wait= 'WAIT' then dowait = ''  /* wait for hsm to 
delete? */

else dowait = 'WAIT'

temp = listdsi(dsn "NORECALL")
select
  when temp = 0 then
"DELETE" dsn
  when temp = 16 then
if sysreason = 9 then "HDELETE" dsn dowait
else
  if quiet = "QUIET" then do
call sysreasn sysreason
say dsn "cannot be deleted this way because" 
result

if sysreason \= 5 then
  "LISTC ALL ENT("dsn
  end
  otherwise
if quiet = "QUIET" then do
  say dsn "cannot be deleted this way"
  "LISTC ALL ENT("dsn
end
end
exit 0


--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" com

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Rugen, Len]

I've got basically the same thing with a HBDELETE first.  I call it 
HBEGONE.  




Ages ago, before TSO/IDCAMS was so nearly smart, I coded in
Rexx (IIRC):

address 'TSO'
'HDELETE ''DATA.SET.NAME'' WAIT'
if RC<>0 then
'DELETE ''DATA.SET.NAME'''

Crude, but effective.  Why do some sysadmins detest
programmers who do what's expedient?

-- gil



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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Scott Ford]

Amen brother gil..thats because most of the sys admins don't really know how
to program

Scott

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Paul Gilmartin
Sent: Wednesday, March 12, 2008 8:52 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

On Wed, 12 Mar 2008 11:03:41 -0700, Edward Jaffe wrote:

>William Bishop wrote:
>> The problem is that if you perfrom an IDCAMS DELETE and specify nonvsam,
>> HSM does a recall.  Without the nonvsam, he does an HDELETE if the
dataset
>> is migrated.
>
>This sounds APARable to me.
>
... or a Requirement?  What's the rationale for the misbehavior?

What's the rationale for specifying NONVSAM if it seems only to
cause problems?

Ages ago, before TSO/IDCAMS was so nearly smart, I coded in
Rexx (IIRC):

address 'TSO'
'HDELETE ''DATA.SET.NAME'' WAIT'
if RC<>0 then
'DELETE ''DATA.SET.NAME'''

Crude, but effective.  Why do some sysadmins detest
programmers who do what's expedient?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Paul Gilmartin]

On Wed, 12 Mar 2008 11:03:41 -0700, Edward Jaffe wrote:

>William Bishop wrote:
>> The problem is that if you perfrom an IDCAMS DELETE and specify nonvsam,
>> HSM does a recall.  Without the nonvsam, he does an HDELETE if the dataset
>> is migrated.
>
>This sounds APARable to me.
>
... or a Requirement?  What's the rationale for the misbehavior?

What's the rationale for specifying NONVSAM if it seems only to
cause problems?

Ages ago, before TSO/IDCAMS was so nearly smart, I coded in
Rexx (IIRC):

address 'TSO'
'HDELETE ''DATA.SET.NAME'' WAIT'
if RC<>0 then
'DELETE ''DATA.SET.NAME'''

Crude, but effective.  Why do some sysadmins detest
programmers who do what's expedient?

-- gil

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Walt Farrell]

On Wed, 12 Mar 2008 11:03:41 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:

>William Bishop wrote:
>> The problem is that if you perfrom an IDCAMS DELETE and specify nonvsam,
>> HSM does a recall.  Without the nonvsam, he does an HDELETE if the dataset
>> is migrated.
>>
>
>This sounds APARable to me.

I don't think so, Ed.  I believe that the presence of "nonvsam" on the
command requires a recall so that IDCAMS can verify that it's a nonvsam
entry (it can't tell that while the data set is migrated).

I believe you'll find that if you had a VSAM file, and issued a DELETE ...
NONVSAM against it that the delete would fail.  Thus, with a migrated data
set IDCAMS needs it recalled or it might mistakenly delete a migrated VSAM
data set.

-- 
  Walt

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 03/12/2008
   at 09:44 AM, John Mattson <[EMAIL PROTECTED]> said:

>Programmers have been deleting for years using BR14 (MOD,DELETE), and 
>IDCAMS DELETE. 

IEFBR14 doesn't delete the data set. By the time IEFBR14 gets control the
data set has already been recalled. But I thought that AMS would issue an
HDELETE if the data set was migrated. Or did you specify the data set in
your JCL when you called IDCAMS?
 
-- 
 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Paul Peplinski]

On Wed, 12 Mar 2008 11:03:41 -0700, Edward Jaffe
<[EMAIL PROTECTED]> wrote:

>William Bishop wrote:
>> The problem is that if you perfrom an IDCAMS DELETE and specify nonvsam,
>> HSM does a recall.  Without the nonvsam, he does an HDELETE if the dataset
>> is migrated.
>>
>
>This sounds APARable to me.
>
>--
WAD. From 

DFSMS Access Method Services for Catalogs 
Document Number SC26-7394-06  

If you delete a migrated data set without specifying the entry type,
DFSMShsm will delete the data set without recalling it. 

Paul P.

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Edward Jaffe]

William Bishop wrote:
The problem is that if you perfrom an IDCAMS DELETE and specify nonvsam, 
HSM does a recall.  Without the nonvsam, he does an HDELETE if the dataset 
is migrated.
  


This sounds APARable to me.

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Adams, Rick]

DTS has a product, ACC, that can handle these for you.  We use it and it
works great.  It cut out our recalls for BR14 deletes completely.

ThanksRick

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of John Mattson
Sent: Wednesday, March 12, 2008 11:44 AM
To: IBM-MAIN@bama.ua.edu
Subject: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

Programmers have been deleting for years using BR14 (MOD,DELETE), and 
IDCAMS DELETE.  I am finding that we are spending ever more time on HSM 
Migrated ds being recalled just to delete them.  Is there an EASY way to

convert these deletes into HSEND DELETE? 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Tom Sipusic]

John Mattson wrote:
Programmers have been deleting for years using BR14 (MOD,DELETE), and 
IDCAMS DELETE.  I am finding that we are spending ever more time on HSM 
Migrated ds being recalled just to delete them.  Is there an EASY way to 
convert these deletes into HSEND DELETE? 
CBT File 673:  A program called CCFDELET which will delete datasets  
using JCL.  In addition, CCFDELET will delete HSM  archived datasets 
without having to recall them.


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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[William Bishop]

The problem is that if you perfrom an IDCAMS DELETE and specify nonvsam, 
HSM does a recall.  Without the nonvsam, he does an HDELETE if the dataset 
is migrated.

I am trying to figure a way to convert my deletes without having to go 
thru a massive change process to remove the nonvsam entries.

Thanks

Bill Bishop

Specialist
Mainframe Support Group
Server Development & Support
Toyota Motor Engineering & Manufacturing North America, Inc.
[EMAIL PROTECTED]
(502) 570-6143



Edward Jaffe <[EMAIL PROTECTED]> 
Sent by: IBM Mainframe Discussion List 
03/12/2008 01:52 PM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@bama.ua.edu
cc

Subject
Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE






John Mattson wrote:
> Programmers have been deleting for years using BR14 (MOD,DELETE), and 
> IDCAMS DELETE.  I am finding that we are spending ever more time on HSM 
> Migrated ds being recalled just to delete them.  Is there an EASY way to 

> convert these deletes into HSEND DELETE?
> 

I thought this happened automatically -- at least for the IDCAMS case.

-- 
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[Edward Jaffe]

John Mattson wrote:
Programmers have been deleting for years using BR14 (MOD,DELETE), and 
IDCAMS DELETE.  I am finding that we are spending ever more time on HSM 
Migrated ds being recalled just to delete them.  Is there an EASY way to 
convert these deletes into HSEND DELETE?
  


I thought this happened automatically -- at least for the IDCAMS case.

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of John Mattson
> Sent: Wednesday, March 12, 2008 11:44 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Easy way to covert IEFBR14 and IDCAMS deletes to HDELETE
> 
> 
> Programmers have been deleting for years using BR14 (MOD,DELETE), and 
> IDCAMS DELETE.  I am finding that we are spending ever more 
> time on HSM 
> Migrated ds being recalled just to delete them.  Is there an 
> EASY way to 
> convert these deletes into HSEND DELETE? 

IDCAMS DELETE should automatically do an HSM delete. It does here (z/OS
1.8). As for the IEFBR14, well somebody will just need to change the job
to use IDCAMS. I don't know of any "automated" way to do this. Well, I
might be able to write a REXX exec which, when given the job, would look
for this special case and write an IDCAMS step to do it to replace the
IEFBR14 step.. 

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

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