PTHREAD library always emit error when SYSIN comes from SYSIN dataset and unconditionally opens SYSOUT

When our C++ application code make the first thread creation call to pthread_create() the language environment implementation unconditionally goes and opens the SYSIN and SYSOUT DDnames.

Our application can, in most circumstances, already be reading input from SYSIN DDname. If the application is being run from a JCL job and the author of the JCL has used an inline SYSIN dataset definition to provide that sysin input. For example:

//SYSIN DD DATA,DLM='++'
INPUT
++

Then that SYSIN data set can only be opened and read once in the entire application. Being that we already have it opened and are reading the content the attempt that is triggered by the pthread_create() call will always fail and produce the following diagnostic message in the job log:

07.50.35 JOB00048 $HASP708 I033447 SYSIN OPEN FAILED
158 RC=03 DATA SET ALREADY OPENED
158 DSNAME=CJH.I033447.JOB00048.D0000101.?
07.50.35 JOB00048 IEC141I 013-C0,IGG0199G,I033447,WPS,SYSIN 159

This is causing confusion to our customers, who are now encountering this message and wondering what it means.

In addition to the above mentioned problem with the SYSIN DDname the pthread_create() call also unconditionally triggers an opening of the SYSOUT data set. We have customers using our application that in their client code trigger reassignment of the SYSOUT data set, as we do not generally explicitly use it in our application this was not an issue. Once the first call to pthread_create() is made their client code can no longer reassign SYSOUT as it has been opened and is in use.

We would like the pthread library to follow the established language environment policy of opening the SYSOUT DD name only when the application code causes it to need to be opened, when it first writes to the STDOUT stream. Additionally we would like to be able to inform the thread library that it will not be able to open SYSIN DD name so that it does not attempt to do it an fail, emitting a message that is causing our customers confusion.

Our application is written to use BSAM for sequential file accesses. We do not use the language environment interfaces for file accesses, since the language environment interface does not allow us full control over the interaction, that we do get with BSAM.