SMS NONSMS difference

[Miklos Szigetvari]

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 ?

--
Miklos Szigetvari

Development Team
ISIS Information Systems Gmbh
tel: (+43) 2236 27551 570
Fax: (+43) 2236 21081

E-mail: miklos.s...@isis-papyrus.com

Info: in...@isis-papyrus.com
Hotline: +43-2236-27551-111

Visit our Website: http://www.isis-papyrus.com
---------------------------------------------------------------
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
---------------------------------------------------------------

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

[Vernooij, CP - SPLXM]

"Miklos Szigetvari" <miklos.s...@ISIS-PAPYRUS.COM> 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 ?
>
> --
> Miklos Szigetvari

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.

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.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
**********************************************************************

[Miklos Szigetvari]

Hi

The SMS managed dataset also unblocked, and the ACS routine does here
nothing (seems to me).
The DCB has RECFM=F LRECL=133, altough with ditto I see 165 byte length
blocks (?) .

--
Miklos Szigetvari

Development Team
ISIS Information Systems Gmbh
tel: (+43) 2236 27551 570
Fax: (+43) 2236 21081

E-mail: miklos.s...@isis-papyrus.com

Info: in...@isis-papyrus.com
Hotline: +43-2236-27551-111

Visit our Website: http://www.isis-papyrus.com
---------------------------------------------------------------
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS accepts
no responsibility for malicious or inappropriate content.
---------------------------------------------------------------

----------------------------------------------------------------------

[Paul Gilmartin]

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:

int P[ 2 ], pid;
...
pipe( P );
spawn( "/bin/cp", "/dev/fd/"P[ 0 ], "//'OUTPUT.DATA.SET'", ... )
...
Then, in each thread:

F = fdopen( P[ 1 ], ... );

(obviously very schematic and untested; I could emulate this
in a shell script.)

... gets a stream in each thread that you can write to. You
might do yet better by using snprintf() and write() in each
thread to have better control.

Of course, if you can use a Unix file rather than a Classic
data set, you don't need the /bin/cp to redirect, and it
becomes much simpler.

-- gil