Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Lazy Allocate (was: SMS NONSMS difference)

4 views
Skip to first unread message

Paul Gilmartin

unread,
Dec 19, 2009, 1:32:26 AM12/19/09
to
On Fri, 18 Dec 2009 22:57:05 -0600, Paul Gilmartin wrote:

>On Fri, 18 Dec 2009 16:35:49 +0100, Vernooij, CP - SPLXM wrote:
>>
>>"Miklos Szigetvari" wrote in
>>message news:<4B2B9EFA...@isis-papyrus.com>...
>>> Hi
>>>
>>> We are writing from a multthread C/C++ application to a dataset
>>> ,allocated with (RECFM=F,LRECL=133,BUFNO=1).
>>> If it is non SMS managed we got all the outputs from the different
>>> threads, but if SMS managed the last close overwrite the previous
>>> Can we do something against this ?
>>>
>>Gee, parallel writing to a file, should this be working? Probably
>>because of the unblocked writing and BUFNO=1.
>>Check to see whether yout SMS dataset is also unblocked. If not, your
>>ACS routines might force this on your dataset.
>>
>I might suggest a paradigm shift here: take control by exploiting
>z/OS Unix at a lower level:
> ...
> ... I could emulate this
>in a shell script.)
>
I tried the following:
########################################################################
#! /bin/sh

# Code for each of the threads
#
logger()
while :; do date "+$1 %a %b %e %T %Z %Y"
sleep $2; done

# create 3 asynchronous threads, each logging to descriptor 3
{
logger "alpha" 2 &
logger "beta " 3 &
logger "gamma" 5 &

jobs
} | tee /dev/fd/2 | cp /dev/fd/0 "//TEMP.FANIN.LOG" &
########################################################################

and got some interesting results browsing TEMP.FANIN.LOG
before and while it was running:

o If TEMP.FANIN.LOG does not pre-exist, the CRTL allocates the data set
and obtains and holds an exclusive ENQ promptly. As soon as I start
running the script, Browse gives me "data set in use".

o If TEMP.FANIN.LOG prexists and I am browsing it when I issue the
script command, it appears to run normally for a couple minutes,
then it fails with:

cp: FSUM6259 target file "//TEMP.FANIN.LOG":
EDC5061I An error occurred when attempting
to define a file to the system.

The data accumulated during that interval is roughly consistent
with one BLKSIZE (6144 bytes, by default).

What might be the design rationale for deferring the ALLOCATE and
OPEN until there's a block ready to be written? I'd prefer the
failure to occur sooner rather than later.

-- gil

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

0 new messages