Re: Another fine mess

[Charles Mills]

Are you SURE that your batch job on LPAR 1 is the problem? That is, are you
sure there is not some other factor outside of what you have described here?
Is it possible something else is deleting or renaming C?

The reason I ask is that it seems to me that even if you totally dropped the
ENQs the situation you described would be unlikely. I don't mean you should
drop the ENQs or that the situation would be sufficiently unlikely for
mainframe production, I just mean that you would be unlikely to hit it in
any given day, and therefore this must be something else. File N does not
exist for only a fraction of a second (rename to rename) - what's the odds
that a batch job would hit that more than once in a blue moon? (Again, too
often to go that way in production, but I am just doing a mental exercise
here.)

After BS689 fails, does C still not exist? Or has it reappeared?

Any chance that the rename in your job is failing and you are not checking
return codes correctly?

Have you checked timestamps? Have you confirmed that BS689 failed at the
exact instant that your job was doing the rename?

Charles



-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Kirk Talman
Sent: Wednesday, April 12, 2006 10:41 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Another fine mess


Our tech people can't find the source of this problem and I am looking for 
any guesses you might have.

Sysplex in question has 11 lpars on 5 CECs

zOS 1.4 with 1.7 being tested.  Sometimes this summer some of the lpars in 
this plex will be running 1.7 if all goes well.  (So far it hasn't.)

I am told GRS used to propagate ENQ in star configuration.

Batch job on lpar 1 builds VSAM file called N.  At the end of the build 
job is a step using a program to frontend IDCAMS.  The frontend issues an 
ENQ RET=NONE with scope of SYSTEMS.  It then links to IDCAMS.  IDCAMS 
renames C to O and renames N to C, effectively bringing a new version of C 
into play.  When IDCAMS ends, the frontend issues DEQ.

Meanwhile on lpar 2, a batch job using program called BT689 wants to use 
file C.  It calls a linked subroutine BS689 which issues an ENQ with the 
same scope as mentioned above.  The ENQ does not specify RET=NONE, but 
that is the default.  It does specify RNL=NO, which is not the default. 
That should not matter since both ENQ have scope of SYSTEMS.

After it obtains the ENQ, BS689 does SVC 99 to dynamically allocate the 
file.  BT689 uses the file for a few reads and then ends.

Previously the job on lpar 1 would fail periodically because the file was 
in use.

This time the program BT689 on lpar 2 failed with message in its log

R15=>0004 S99INFO=>0002 S99ERROR=>1708

IKJ56228I DATA SET C NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED

--
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: Another fine mess

[Kirk Talman]

Replies in [[ ]]

IBM Mainframe Discussion List  wrote on 04/12/2006 
02:11:13 PM:

> Are you SURE that your batch job on LPAR 1 is the problem? That is, are 
you
> sure there is not some other factor outside of what you have described 
here?
> Is it possible something else is deleting or renaming C?

[[I own C.  If at any point, there is no C, jobs begin to fail as the one 
on lpar 2 did.  At peak period, jobs can fail every minute.  As for any 
other issues, I am looking for suggestions.]]

> The reason I ask is that it seems to me that even if you totally dropped 
the
> ENQs the situation you described would be unlikely. I don't mean you 
should
> drop the ENQs or that the situation would be sufficiently unlikely for
> mainframe production, I just mean that you would be unlikely to hit it 
in
> any given day, and therefore this must be something else. File N does 
not
> exist for only a fraction of a second (rename to rename) - what's the 
odds
> that a batch job would hit that more than once in a blue moon? (Again, 
too
> often to go that way in production, but I am just doing a mental 
exercise
> here.)

[[The odds are very slim.  And it happens every so often.  It's not a big 
hole I am closing.  It is a hole.  And I can't find the mouse.  I just 
need the name of the mouse so I know whose mouse it is.]]

> After BS689 fails, does C still not exist? Or has it reappeared?

[[In human time the dataset always exists.  Only computers can see the 
hole in time the cybermouse goes through.]]

> Any chance that the rename in your job is failing and you are not 
checking
> return codes correctly?

[[If rename fails, and there is no C, subsequent jobs fail.  If rename 
fails, and there is a C, I could detect that N still existed and that 
dataset timestamps were wrong.]]

> Have you checked timestamps? Have you confirmed that BS689 failed at the
> exact instant that your job was doing the rename?

[[Timestamps the same to the second.  Both steps take less than a second.

It should be mentioned that in the past, to correct this kind of problem, 
rename was limited only to the cluster name of the KSDS since failure 
would happen between the rename of the cluster and the rename of the 
components.

This problem has been happening sporadically for several years.]]


> Charles

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On 
Behalf
> Of Kirk Talman
> Sent: Wednesday, April 12, 2006 10:41 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Another fine mess

> Our tech people can't find the source of this problem and I am looking 
for 
> any guesses you might have.

> Sysplex in question has 11 lpars on 5 CECs

> zOS 1.4 with 1.7 being tested.  Sometimes this summer some of the lpars 
in 
> this plex will be running 1.7 if all goes well.  (So far it hasn't.)

> I am told GRS used to propagate ENQ in star configuration.

> Batch job on lpar 1 builds VSAM file called N.  At the end of the build 
> job is a step using a program to frontend IDCAMS.  The frontend issues 
an 
> ENQ RET=NONE with scope of SYSTEMS.  It then links to IDCAMS.  IDCAMS 
> renames C to O and renames N to C, effectively bringing a new version of 
C 
> into play.  When IDCAMS ends, the frontend issues DEQ.

> Meanwhile on lpar 2, a batch job using program called BT689 wants to use 

> file C.  It calls a linked subroutine BS689 which issues an ENQ with the 

> same scope as mentioned above.  The ENQ does not specify RET=NONE, but 
> that is the default.  It does specify RNL=NO, which is not the default. 
> That should not matter since both ENQ have scope of SYSTEMS.

> After it obtains the ENQ, BS689 does SVC 99 to dynamically allocate the 
> file.  BT689 uses the file for a few reads and then ends.

> Previously the job on lpar 1 would fail periodically because the file 
was 
> in use.

> This time the program BT689 on lpar 2 failed with message in its log

> R15=>0004 S99INFO=>0002 S99ERROR=>1708

> IKJ56228I DATA SET C NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED



-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom
it is addressed.  The information may also constitute a legally
privileged confidential communication.  If the reader of this
message is not the intended recipient or an agent responsible for
delivering it to the intended recipient, you are hereby notified
that you have received this communication in error and that any
review, dissemination, copying, or unauthorized use of this
information, or the taking of any action in reliance on the
contents of this information is strictly prohibited.  If you have
received this communication in error, please notify us immediately
by e-mail, and delete the original message.  Thank you

--
For IB

Re: Another fine mess

[Richard Tsujimoto]

Is it possible that someone isn't using the front-end?

--
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: Another fine mess

[Gerhard Adam]

>1) Could RNL=NO be the issue that causes the ENQ to fail?

>3) Is there latency in the updating of the catalog by IDCAMS?

What makes you think the ENQ has failed?  There is certainly latency in 
updating the catalog between the catalog address spaces on the different 
systems.  Are you using the coupling facility within a plex?  Are you relying 
on each LPAR to detect the change and update it's own catalog address space?  
Does the problem ever happen within the same LPAR? or only is it when sharing 
between LPAR's?

Anyway ... those are some of the questions I have.

Adam

--
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: Another fine mess

[Vernooy, C.P. - SPLXM]

<[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> Our tech people can't find the source of this problem and I am looking for 
> any guesses you might have.
> 
> Sysplex in question has 11 lpars on 5 CECs
> 
> zOS 1.4 with 1.7 being tested.  Sometimes this summer some of the lpars in 
> this plex will be running 1.7 if all goes well.  (So far it hasn't.)
> 
> I am told GRS used to propagate ENQ in star configuration.
> 
> Batch job on lpar 1 builds VSAM file called N.  At the end of the build > job 
> is a step using a program to frontend IDCAMS.  The frontend issues an 
> ENQ RET=NONE with scope of SYSTEMS.  It then links to IDCAMS.  IDCAMS > 
> renames C to O and renames N to C, effectively bringing a new version of C 
> into play.  When IDCAMS ends, the frontend issues DEQ.
> 
> Meanwhile on lpar 2, a batch job using program called BT689 wants to use > 
> file C.  It calls a linked subroutine BS689 which issues an ENQ with the > 
> same scope as mentioned above.  The ENQ does not specify RET=NONE, but > that 
> is the default.  It does specify RNL=NO, which is not the default. 
> That should not matter since both ENQ have scope of SYSTEMS.
> 


You don't have CA-MIM? MIM skips ENQs with RNL=NO, in which case both ENQs are 
handled differently.

Kees.


**
For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), 
its subsidiaries and/or its employees shall not be liable for the incorrect or 
incomplete transmission of this e-mail or any attachments, nor responsible for 
any delay in receipt.
**

--
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: Another fine mess ...

[Edward E. Jaffe]

Kirk Talman wrote:
I own a piece of Assembler batch code that reads a parm member of a system 
library managed by Endeavor. This piece of code runs many times a day on 
all (10) production plexes.


The FINE Endeavor folks have chosen to compress the library on each plex 
around 5 am each day.  The collisions do not, unfortunately, cause an 
abend.  The program "reads" the member and finds garbage, causing it to 
fail in its task, returning the wrong return code.


I am wondering if I attempt to validate the parm, and finding "garbage", 
what are the conditions under which I can get the correct information?


If I wait say 10-20 seconds, do I have to close and reopen the file before 
reissuing the FIND macro for the member?  Are there any other gotchas 
lurking in the shadows?


All lpars appear to be zOS 1.4.
  


IMHO, unserialized use of a PDS that's being compressed is a big 
mistake! I suggest you a) compress the PDS with DISP=OLD (SYSDSN 
exclusive), b) use an alternate serialization mechanism of some kind, or 
c) convert the library to PDSE and stop compressing it altogether.


--
.-.
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | 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: Another fine mess ...

[Knutson, Sam]

Use PDSE

Use DISP=OLD either on your job or the compress

Change your code to do the same enqueue used by IEBCOPY

Best Regards,

Sam Knutson, GEICO
Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office)  301.986.3574

Logic is a tweeting bird in a green meadow. - Mr. Spock 

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Kirk Talman
Sent: Thursday, January 19, 2006 11:53 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Another fine mess ...

I own a piece of Assembler batch code that reads a parm member of a
system library managed by Endeavor. This piece of code runs many times a
day on all (10) production plexes.

The FINE Endeavor folks have chosen to compress the library on each plex
around 5 am each day.  The collisions do not, unfortunately, cause an
abend.  The program "reads" the member and finds garbage, causing it to
fail in its task, returning the wrong return code.

I am wondering if I attempt to validate the parm, and finding "garbage",
what are the conditions under which I can get the correct information?

If I wait say 10-20 seconds, do I have to close and reopen the file
before reissuing the FIND macro for the member?  Are there any other
gotchas lurking in the shadows?

All lpars appear to be zOS 1.4.

<>

This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

--
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: Another fine mess ...

[Mark Zelden]

On Thu, 19 Jan 2006 11:52:51 -0500, Kirk Talman <[EMAIL PROTECTED]> wrote:

>I own a piece of Assembler batch code that reads a parm member of a system
>library managed by Endeavor. This piece of code runs many times a day on
>all (10) production plexes.
>
>The FINE Endeavor folks have chosen to compress the library on each plex
>around 5 am each day.  The collisions do not, unfortunately, cause an
>abend.  The program "reads" the member and finds garbage, causing it to
>fail in its task, returning the wrong return code.
>
>I am wondering if I attempt to validate the parm, and finding "garbage",
>what are the conditions under which I can get the correct information?
>
>If I wait say 10-20 seconds, do I have to close and reopen the file before
>reissuing the FIND macro for the member?  Are there any other gotchas
>lurking in the shadows?
>
>All lpars appear to be zOS 1.4.
>
>

Opt. #1 (best opt.)  Convert to PDSE and never worry about compress

Opt. #2, change JCL to DISP=OLD

We changed Endevor libs to PDSE years ago.  The Endeavor folks used
to schedule jobs to compress our Endevor controlled JES2 proclibs and
cause problems.  PDSE resolved that and later on we converted to
dynamic proclibs after z/OS 1.2.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America and Farmers Insurance Group
mailto: [EMAIL PROTECTED]
Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: Another fine mess ...

[Paul Gilmartin]

In a recent note, Knutson, Sam said:

> Date: Thu, 19 Jan 2006 12:36:36 -0500
> 
> Use PDSE
> 
The second-best idea.  Unfortunately we can't always do it because
we share data sets beyond sysplex boundaries.  HFS/z/FS shared by
NFS might be even better.

> Use DISP=OLD either on your job or the compress
> 
Not always practical for heavily used linklibs and parameter libraries.

> Change your code to do the same enqueue used by IEBCOPY
> 
How do I find that?  A search for ENQUEUE in:

Title: z/OS V1R7.0 DFSMSdfp Utilities
Document Number: SC26-7414-03

... returns no hits.  Do the queue names and resource names involved
require APF?

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
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: Another fine mess ...

[Kirk Talman]

I thank you for your consideration.  But our operation may be compared to 
a large (40+kMips) octopus wherein the arms do not always work in sync.

Someone else owns the datasets and job.  At the moment they are consumed 
with bringing up two new plexes and at least one new Endeavor environment. 
 And they see others problems through their own eyes.

I agree IEBCOPY has no need to use an ENQUE - dataset allocation handles 
that.  And I remember working for a software vendor a decade ago that had 
a product that did ENQUEs in places where other products by other vendors 
(such as IBM) did not.  I think those products are not used now.

I would use an abend but that is politically incorrect when someone else 
is using (somewhat reluctantly and belatedly) one's code by edict.

What I was wondering is, does FIND support (SVC 18) save information about 
the directory (such as member last fetched and corresponding TTR) bewtwen 
accesses if the file remains open.  And is there anything I have not 
considered.

IBM Mainframe Discussion List wrote on 01/19/2006 
12:52:56 PM:

>In a recent note, Knutson, Sam said:

>>Use PDSE

>The second-best idea.  Unfortunately we can't always do it because we 
share data sets beyond sysplex boundaries.  HFS/z/FS shared by NFS might 
be even better.

>>Use DISP=OLD either on your job or the compress

>Not always practical for heavily used linklibs and parameter libraries.

>>Change your code to do the same enqueue used by IEBCOPY

>How do I find that?  A search for ENQUEUE in:
>Title: z/OS V1R7.0 DFSMSdfp Utilities Document Number: SC26-7414-03

>... returns no hits.  Do the queue names and resource names involved 
require APF?

>-- gil



-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom it is
addressed.  The information may also constitute a legally privileged
confidential communication.  If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited.
If you have received this communication in error, please notify us
immediately by e-mail, and delete the original message.  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: Another fine mess ...

[Richard Pinion]

Maybe you could remove the problem PDS from your JCL and add code to the ASM 
program to do a dynamic allocate of the PDS (maybe use another parmlib to hold 
the name of the PDS in case it changes in the future, thus no program changes). 
 If the dynamic allocate fails, issue the STIMER macro, wake up and try the 
dynamic allocate again.  Repeat 'x' times as necessary and if still 
unsuccessful give up.

>>> [EMAIL PROTECTED] 1/19/2006 2:12:15 PM >>>
I thank you for your consideration.  But our operation may be compared to 
a large (40+kMips) octopus wherein the arms do not always work in sync.

Someone else owns the datasets and job.  At the moment they are consumed 
with bringing up two new plexes and at least one new Endeavor environment. 
 And they see others problems through their own eyes.

I agree IEBCOPY has no need to use an ENQUE - dataset allocation handles 
that.  And I remember working for a software vendor a decade ago that had 
a product that did ENQUEs in places where other products by other vendors 
(such as IBM) did not.  I think those products are not used now.

I would use an abend but that is politically incorrect when someone else 
is using (somewhat reluctantly and belatedly) one's code by edict.

What I was wondering is, does FIND support (SVC 18) save information about 
the directory (such as member last fetched and corresponding TTR) bewtwen 
accesses if the file remains open.  And is there anything I have not 
considered.

IBM Mainframe Discussion List wrote on 01/19/2006 
12:52:56 PM:

>In a recent note, Knutson, Sam said:

>>Use PDSE

>The second-best idea.  Unfortunately we can't always do it because we 
share data sets beyond sysplex boundaries.  HFS/z/FS shared by NFS might 
be even better.

>>Use DISP=OLD either on your job or the compress

>Not always practical for heavily used linklibs and parameter libraries.

>>Change your code to do the same enqueue used by IEBCOPY

>How do I find that?  A search for ENQUEUE in:
>Title: z/OS V1R7.0 DFSMSdfp Utilities Document Number: SC26-7414-03

>... returns no hits.  Do the queue names and resource names involved 
require APF?

>-- gil



-
The information contained in this communication (including any
attachments hereto) is confidential and is intended solely for the
personal and confidential use of the individual or entity to whom it is
addressed.  The information may also constitute a legally privileged
confidential communication.  If the reader of this message is not the
intended recipient or an agent responsible for delivering it to the
intended recipient, you are hereby notified that you have received this
communication in error and that any review, dissemination, copying, or
unauthorized use of this information, or the taking of any action in
reliance on the contents of this information is strictly prohibited.
If you have received this communication in error, please notify us
immediately by e-mail, and delete the original message.  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

--
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: Another fine mess ...

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>,
on 01/19/2006
   at 12:36 PM, "Knutson, Sam" <[EMAIL PROTECTED]> said:

>Change your code to do the same enqueue used by IEBCOPY

What ENQ? AFAIK it doesn't issue one.
 
-- 
 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: Another fine mess ...

[Edward E. Jaffe]

Shmuel Metz (Seymour J.) wrote:

In <[EMAIL PROTECTED]>,
on 01/19/2006
   at 12:36 PM, "Knutson, Sam" <[EMAIL PROTECTED]> said:

  

Change your code to do the same enqueue used by IEBCOPY



What ENQ? AFAIK it doesn't issue one.
  


Probably meant the binder ...

--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | 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: Another fine mess ...

[Vernooy, C.P. - SPLXM]

<[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> I thank you for your consideration.  But our operation may be compared to > a 
> large (40+kMips) octopus wherein the arms do not always work in sync.
> 
> Someone else owns the datasets and job.  At the moment they are consumed > 
> with bringing up two new plexes and at least one new Endeavor environment. 
>  And they see others problems through their own eyes.
> 
> I agree IEBCOPY has no need to use an ENQUE - dataset allocation handles > 
> that.  And I remember working for a software vendor a decade ago that had 
> a product that did ENQUEs in places where other products by other vendors > 
> (such as IBM) did not.  I think those products are not used now.
> 
> I would use an abend but that is politically incorrect when someone else > is 
> using (somewhat reluctantly and belatedly) one's code by edict.
> 
> What I was wondering is, does FIND support (SVC 18) save information about 
> the directory (such as member last fetched and corresponding TTR) bewtwen > 
> accesses if the file remains open.  And is there anything I have not 
> considered.
> 
> IBM Mainframe Discussion List wrote on 01/19/2006 > 
> 12:52:56 PM:
> 
> >In a recent note, Knutson, Sam said:
> 
> >>Use PDSE
> 
> >The second-best idea.  Unfortunately we can't always do it because we 
> share data sets beyond sysplex boundaries.  HFS/z/FS shared by NFS might > be 
> even better.
> 
> >>Use DISP=OLD either on your job or the compress
> 
> >Not always practical for heavily used linklibs and parameter libraries.
> 
> >>Change your code to do the same enqueue used by IEBCOPY
> 
> >How do I find that?  A search for ENQUEUE in:
> >Title: z/OS V1R7.0 DFSMSdfp Utilities Document Number: SC26-7414-03
> 
> >... returns no hits.  Do the queue names and resource names involved 
> require APF?
> 
> >-- gil
> 

Another possible solution is to eliminate (more or less) the compress. Make it 
10 times its current size and try to find a quiet moment to compress the 
dataset, e.g. in the weekend.

A next solution is to bring it under PDSMAN Space Reuse control. This gives you 
automatic compress like PDSE, without the PDSE restrictions.

To clear my confusion: Gil, are you rkuebbin?

Kees.


**
For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), 
its subsidiaries and/or its employees shall not be liable for the incorrect or 
incomplete transmission of this e-mail or any attachments, nor responsible for 
any delay in receipt.
**

--
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