This problem has been resolved, it turned out to be a bug in the program
caused by the dataset being in use by another job.
Thanks for all the suggestions
Dana
--
For IBM-MAIN subscribe / signoff / archive access instructions,
s
In , on 05/19/2011
at 10:00 AM, Paul Gilmartin said:
>Grrr. I detest designs that require the programmer to use delays to
>(hopefully) resolve race conditions.
This doesn't look like a race issue in CLOSE. It looks like either an
"in use" issue or an incorrect reason code.
--
Shmuel
In , on 05/18/2011
at 09:51 AM, Dana Mitchell said:
>Does anyone know if the FREE=CLOSE process that happens in response
>to step 4 is synchronous in nature?
Yes. But I don't know what type of free is used.
>This has been working well for years. Yesterday it began to fail
>with x'0410' dec
What kind of dataset it is? Try looking at the ICF Catalog record via
processing
SMF Type 60-65 ...MXG/SAS if you have can be handy in generating
reports..also on the basis of type 15...
snapshot of type 15
Record type 15 is written for non-VSAM direct access, or VIO tape data sets
that are
:10 AM
Subject: Re: Question about Dynamic allocate
On Fri, 20 May 2011 09:32:27 -0500, Dana Mitchell
wrote:
>Thanks everyone for the ideas so far. It happened again yesterday and now
>I'm leaning more towards this being caused by the dataset being in use by
>another job.
>
On Fri, 20 May 2011 09:32:27 -0500, Dana Mitchell
wrote:
>Thanks everyone for the ideas so far. It happened again yesterday and now
>I'm leaning more towards this being caused by the dataset being in use by
>another job.
>
Dana - You could use DAF to check your SMF data to see if the dataset
On Thu, 19 May 2011 10:00:36 -0500, Paul Gilmartin
wrote:
>On Thu, 19 May 2011 08:56:49 -0500, Tim Deller wrote:
>
>>I would try coding a wait (for a few seconds at least) after the dataset
close.
>>This would allow time for the deallocate and catalog update to complete.
>>
>Grrr. I detest des
On Thu, 19 May 2011 08:56:49 -0500, Tim Deller wrote:
>I would try coding a wait (for a few seconds at least) after the dataset close.
>This would allow time for the deallocate and catalog update to complete.
>
Grrr. I detest designs that require the programmer to use delays
to (hopefully) resolv
I would try coding a wait (for a few seconds at least) after the dataset close.
This would allow time for the deallocate and catalog update to complete.
Tim
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send e
I'm not sure if it would help either, but it's an easy thing to try :-)
On 5/18/2011 11:29 AM, Dana Mitchell wrote:
On Wed, 18 May 2011 11:18:08 -0400, Jim Blalock
wrote:
Also, are you coding DYNAMNBR= on the STC's EXEC card? Might try that
first, it's easier than debugging DYNALLOCs :-)
--
On Wed, 18 May 2011 11:18:08 -0400, Jim Blalock
wrote:
>
>Also, are you coding DYNAMNBR= on the STC's EXEC card? Might try that
>first, it's easier than debugging DYNALLOCs :-)
>
>-- Jim Blalock, Clemson U.
>
Jim, I'm not sure what DYNAMNBR would help me with in this situation?
Dana
Hi Dana,
I would try coding the DYNALLOC free request (removing FREE=CLOSE) and
see what RC's you get. That may give you more clues.
Also, are you coding DYNAMNBR= on the STC's EXEC card? Might try that
first, it's easier than debugging DYNALLOCs :-)
-- Jim Blalock, Clemson U.
On 5/18/2
Hello all,
We have an inhouse written STC that processes messages from MQ and writes
them to a dataset. This processing goes like this:
1. DYNALLOC on DATA.SET.NAME
a. Request the current generation ( done by putting 0 in DALMEMBR)
b. Specify DALCLOSE (equivalent to FREE=CLOS
13 matches
Mail list logo