Beating a dead horse but
Tim Hare
"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."
I have a set of application folks who use this method for tape datasets
(reusing the dataset names, rather than making them unique for whatever
reason), and of course no one wants to change the batch application because
of testing requirements, busy with other things, etc.
I believe HSM installs a catalog locate exit, as does ABR, to handle
the 'dynamic recall' .
Why can't the exit check for this specific set of conditions:
1. jobstep program is IEFBR14
2. At offset 0 of the location of IEFBR14 in storage, we have '1BFF07FE' : SR
15,15 followed by BCR 15,14
3. Status is OLD or MOD
4. normal disposition AND conditional disposition are DELETE
If all of the above are met, then do the equivalent of HDELETE for the dataset
Seems to me that verifies in most cases that we're dealing with the real
IEFBR14 and not a replacement (although I grant it's possible to leave those
bytes in place by coding an IEFBR14 replacement with a different entry point,
I believe it in practice to be pretty unlikely), and that the dataset is intended
to be deleted no matter what (both dispositions are DELETE).
The workaround for now is to try to make sure the dataset to be deleted is
either retained until the delete reference (often the next day), OR to do
HRECALLs ahead of the job.
As I said, this is probably beating a dead horse but I didn't see this specific
proposal mentioned.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Walt Farrell
wrote:
>In a 2008 thread on people using IEFBR14 to do deletes there as this:
>...snipped...
>If all of the above are met, then do the equivalent of HDELETE for the dataset
>
>Seems to me that verifies in most cases that we're dealing with the real
>IEFBR14 and not a replacement (although I grant it's possible to leave those
>bytes in place by coding an IEFBR14 replacement with a different entry point,
>I believe it in practice to be pretty unlikely), and that the dataset is
intended
>to be deleted no matter what (both dispositions are DELETE).
>
>
>The workaround for now is to try to make sure the dataset to be deleted is
>either retained until the delete reference (often the next day), OR to do
>HRECALLs ahead of the job.
>
>As I said, this is probably beating a dead horse but I didn't see this specific
>proposal mentioned.
>
Perhaps I've misunderstood your point, but isn't this already handled by the
enhancements made in z/OS R11?
--
Walt
John Laubenheimer
<Tim....@SSRC.MYFLORIDA.COM> wrote:
>In a 2008 thread on people using IEFBR14 to do deletes there as this:
>
>"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."
>
>I have a set of application folks who use this method for tape datasets
>(reusing the dataset names, rather than making them unique for whatever
>reason), and of course no one wants to change the batch application
because
>of testing requirements, busy with other things, etc.
>
>I believe HSM installs a catalog locate exit, as does ABR, to handle
>the 'dynamic recall' .
>
>Why can't the exit check for this specific set of conditions:
>
>1. jobstep program is IEFBR14
>2. At offset 0 of the location of IEFBR14 in storage, we have '1BFF07FE' : SR
>15,15 followed by BCR 15,14
>3. Status is OLD or MOD
>4. normal disposition AND conditional disposition are DELETE
>
>If all of the above are met, then do the equivalent of HDELETE for the dataset
>
>Seems to me that verifies in most cases that we're dealing with the real
>IEFBR14 and not a replacement (although I grant it's possible to leave those
>bytes in place by coding an IEFBR14 replacement with a different entry point,
>I believe it in practice to be pretty unlikely), and that the dataset is intended
>to be deleted no matter what (both dispositions are DELETE).
>
>
>The workaround for now is to try to make sure the dataset to be deleted is
>either retained until the delete reference (often the next day), OR to do
>HRECALLs ahead of the job.
>
>As I said, this is probably beating a dead horse but I didn't see this specific
>proposal mentioned.
>
>----------------------------------------------------------------------
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
>Search the archives at http://bama.ua.edu/archives/ibm-main.html
Have you checked out z/OS 1.11 yet? EXEC PGM=IEFBR14 with DISP=
(OLD,DELETE) will no longer recall a dataset if migrated. The dataset will be
deleted (via HDELETE or equivalent interface) directly from the migration
volume, without an intervening recall. I believe that this is an installation
option if you don't want this to happen.
Donald Russell
> In a 2008 thread on people using IEFBR14 to do deletes there as this:
>
> "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."
>
//S1 EXEC PGM=IEFBR14
//FILE1 DD DSN=...,DISP=(OLD,DELETE),UNIT=(,,DEFER)
I believe this will delete a migrated dataset without recalling it, because
IIRC the DEFER option on UNIT says, don't allocate a device for this until
the dataset is opened... since IEFBR14 doesn't open the dataset, it's not
allocated to a device and there's no need to recall it.
YMMV... It's been a while. :-)
Sam Siegel
Paul Gilmartin
>This is exactly what I've recently done and it works perfect on 1.09
>
How did you verify that the data set was not recalled before it
was deleted.
>On Fri, Nov 20, 2009 at 6:29 PM, Donald Russell wrote:
>
>> //S1 EXEC PGM=IEFBR14
>> //FILE1 DD DSN=...,DISP=(OLD,DELETE),UNIT=(,,DEFER)
>>
>> I believe this will delete a migrated dataset without recalling it, because
>> IIRC the DEFER option on UNIT says, don't allocate a device for this until
>> the dataset is opened... since IEFBR14 doesn't open the dataset, it's not
>> allocated to a device and there's no need to recall it.
>>
>> YMMV... It's been a while. :-)
>>
This is partly rendered moot by changes in 1.11.
I suspect this doesn't work as you wish for a couple reasons:
o Verifiably, on 1.10. I migrated a data set, then ran the job step:
//STEP EXEC PGM=IEFBR14
//D DD DISP=OLD,UNIT=(,,DEFER),
// DSN=&SYSUID...
The data set was recalled. Even a better test: We have a test
system on which HSM is not enabled. There, I submitted the
job with DISP=(OLD,DELETE),UNIT=(,,DEFER). There, it hung on WTOR:
ARC0050A DFSMSHSM IS NOT ACTIVE - START DFSMSHSM
o Suspected; not verifiable. Delete processing in allocation may
require that the data set reside on a real volume, not merely be
defined in the MCDS.
The extent to which this is not moot is that some parsimonious
programmers choose not to add an IEFBR14 step, but to add the DD
statement with DISP=(OLD,DELETE) to some other job step. I've
done that at times.
It might have been better had z/OS design chosen to honor the
DEFER specification for DASD data sets, consistent with the
behavior for tape, leaving the programmer with control of whether
or not the data set is recalled at step allocation. This would
have supported shortcut deletion on a non-IEFBR14 step and
alleviated the phobia about misbehavior of a bogus IEFBR14.
(Doesn't the IBM-controlled prefix, "IEF" caution sites against
substituting an "IEFBR14" with unconventional behavior?)
Hmmm. If a form of DEFER were tolerated on a Unix PATH= specification,
syould it defer automount until an actual attempt to open the file?
-- gil
Donald Russell
I suspect your "better test" isn't very conclusive:
Because there's a WTOR saying to start HSM doesn't mean the data set is
going to be recalled. I would expect HSM must be running in order to delete
a migrated dataset... HSM has to be told at some level to delete it.
Your first test I assume you see messages in the job log about the dataset
being recalled?
Does it make a difference if the dataset is migrated to second level or not?
I don't know which messages you saw that lead you to believe is was
recalled.
I think a conclusive test would be ...
A - migrate a dataset
B - IEFBR14 DISP=OLD,UNIT=(,,DEFER)
C - Is dataset recalled or not?
Repeat with step A being "migrate to second level" (just for fun)
I doubt very much the DISP parm matters, either the dataset will be recalled
or it won't, based on the DEFER option.
Paul Gilmartin
>On Sat, Nov 21, 2009 at 08:08, Paul Gilmartin wrote:
>>
>> I suspect this doesn't work as you wish for a couple reasons:
>>
>> o Verifiably, on 1.10. I migrated a data set, then ran the job step:
>>
>> //STEP EXEC PGM=IEFBR14
>> //D DD DISP=OLD,UNIT=(,,DEFER),
>> // DSN=&SYSUID...
>>
>> The data set was recalled. Even a better test: We have a test
>> system on which HSM is not enabled. There, I submitted the
>> job with DISP=(OLD,DELETE),UNIT=(,,DEFER). There, it hung on WTOR:
>>
>> ARC0050A DFSMSHSM IS NOT ACTIVE - START DFSMSHSM
>>
>> o Suspected; not verifiable. Delete processing in allocation may
>> require that the data set reside on a real volume, not merely be
>> defined in the MCDS.
>>
>>
>
>I suspect your "better test" isn't very conclusive:
>Because there's a WTOR saying to start HSM doesn't mean the data set is
>going to be recalled. I would expect HSM must be running in order to delete
>a migrated dataset... HSM has to be told at some level to delete it.
>
Oops. You're right. I forgot to consider that.
>Your first test I assume you see messages in the job log about the dataset
>being recalled?
>Does it make a difference if the dataset is migrated to second level or not?
>
>I don't know which messages you saw that lead you to believe is was
>recalled.
>
>I think a conclusive test would be ...
>A - migrate a dataset
>B - IEFBR14 DISP=OLD,UNIT=(,,DEFER)
If you read carefully the quoted material you will see that I
performed this test.
>C - Is dataset recalled or not?
>
If you read carefully the quoted material you will see that I
reported the data set was recalled.
>Repeat with step A being "migrate to second level" (just for fun)
>
I have now done this. The data set was recalled, with SYSLOG messages
including:
11:13:07.26 STC05950 00000090 *TMS009 IEC501A M D413,665560,SL,,PRODHSM,H,UOP.H
11:13:07.25 STC05950 00080094 *IEC501A M D413,665560,SL,,PRODHSM,H,UOP.HMIGTAPE.
>I doubt very much the DISP parm matters, either the dataset will be recalled
>or it won't, based on the DEFER option.
>
My observations contradict your blind guess: it appears to me that
the data set is recalled regardless of the DEFER option.
-- gil
Edward Jaffe
> //S1 EXEC PGM=IEFBR14
> //FILE1 DD DSN=...,DISP=(OLD,DELETE),UNIT=(,,DEFER)
>
> I believe this will delete a migrated dataset without recalling it, because
> IIRC the DEFER option on UNIT says, don't allocate a device for this until
> the dataset is opened... since IEFBR14 doesn't open the dataset, it's not
> allocated to a device and there's no need to recall it.
>
Does implicit HRECALL happen at OPEN time? I thought it occurred at
allocation time. Otherwise, what unit/volume information would be found
in control blocks like JFCB, DSAB, TIOT, etc. for a migrated data set
that has been allocated but not yet OPENed?
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
Donald Russell
> On Sat, 21 Nov 2009 09:54:32 -0800, Donald Russell wrote:
> >
> I have now done this. The data set was recalled, with SYSLOG messages
> including:
>
> 11:13:07.26 STC05950 00000090 *TMS009 IEC501A M
> D413,665560,SL,,PRODHSM,H,UOP.H
> 11:13:07.25 STC05950 00080094 *IEC501A M
> D413,665560,SL,,PRODHSM,H,UOP.HMIGTAPE.
>
> >I doubt very much the DISP parm matters, either the dataset will be
> recalled
> >or it won't, based on the DEFER option.
> >
> My observations contradict your blind guess: it appears to me that
> the data set is recalled regardless of the DEFER option.
>
>
My grammar was poor... I didn't mean that DEFER would control recalling the
dataset; I meant that test would determine conclusively whether DEFER had an
influence.
So, theory to test: DEFER influences recall
Test: IEFBR14 DISP=OLD,UNIT w/DEFER vs UNIT w/o DEFER
Write an essay comparing and contrasting the two
Conclusion: DEFER doesn't influence recall
'nuff said. Can I have my sight back now? ;-)
Joel C. Ewing
> This is exactly what I've recently done and it works perfect on 1.09
>
> On Fri, Nov 20, 2009 at 6:29 PM, Donald Russell <russe...@gmail.com>wrote:
>
>> On Fri, Nov 20, 2009 at 10:34, Tim Hare <Tim....@ssrc.myflorida.com>
>> wrote:
>>
>>> In a 2008 thread on people using IEFBR14 to do deletes there as this:
>>>
>>> "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."
>>>
>>
>>
>> //S1 EXEC PGM=IEFBR14
>> //FILE1 DD DSN=...,DISP=(OLD,DELETE),UNIT=(,,DEFER)
>>
>> I believe this will delete a migrated dataset without recalling it, because
>> IIRC the DEFER option on UNIT says, don't allocate a device for this until
>> the dataset is opened... since IEFBR14 doesn't open the dataset, it's not
>> allocated to a device and there's no need to recall it.
>>
>> YMMV... It's been a while. :-)
>>
The "DEFER" option applies to the request to mount an unmounted volume,
not to device allocation. A device will always be allocated before
allowing the job step to execute, with or without the DEFER. For
example, this means if you use this technique to delete a tape dataset
when no drives are available, the job will still have to wait for an
available device, even though no tape will be mounted or read.
Others have already pointed out that unless you are on z/OS > 1.10, the
allocation should still be sufficient to force a recall. You can
analyze the log records (or SMF records if so configured) from DFHSM to
see for sure whether a RECALL was done before the delete.
--
Joel C. Ewing, Fort Smith, AR jREMOVEc...@acm.org