Conference clt::cma

.0> can I suggest that the replies are also posted there

Sorry, Cameron, but I don't monitor that conference, and since the answer that
you're asking for relates to threads and not DCE, I'll post my answer here. 
(You have my permission to cross-post this reply, if you like, but only if
you're willing to cross-post any responses to it back here and any responses to
them back there...)

.0> I'm aware that the threads standard has changed from 1003.4a
.0> (Draft 4) to the POSIX.1c final standard. I also know that
.0> this is the threads standard implemented under
[...]
.0>         Digital DCE for UNIX 2.0 or later

As far as I know, all existing versions of DCE, including V2.0, shipped by any
vendor, including Digital, use the 1003.4a/D4 threads interface.  The code comes
from a common source (the Open Software Foundation), and they have not yet
agreed to upgrade the source to use the standard interface.

.0> What I don't know, however, is (a) what threads standard
.0> I should use when programming using DCE V1.4 for OpenVMS
.0> under OpenVMS V7.0 or later 

On Digital Unix and OpenVMS, all code currently under active development should
be implemented using or migrated to use the 1003.1c standard interface.  The
1003.4a/D4 interface will be removed from these systems in an up-coming release,
and it will no longer be available for use by newly compiled or re-linked code. 
Application code using the standard interface will work together with DCE, even
though DCE is using the obsolete interface -- each separately compiled module
may use a different DECthreads interface, so long as DECthreads objects created
by one interface are not operated on in a different module using a different
interface.

.0> (b) under what circumstances, if any, I will need to change my threads code 
.0> that runs on Windows platforms.

On Windows, currently, Digital provides only the obsolete interface, and it is
packaged with the DCE product.  We are in the process of making the standard
interface available on Windows, but it's not available at this time.  Thus, on
Windows, you don't have a choice, yet -- you have only the obsolete interface.

.0> What I would really like is a document that summarises
.0> what threads standards exist now, and will exist in the
.0> future, on the various platforms, whether this depends
.0> on the DCE or O/S version, and how I should compile and
.0> link my programs on these various platforms. 

There is only one "threads standard" (at least as far as I'm concerned... ;-),
and that's the POSIX 1003.1 standard (.1c has been incorporated into .1).  The
standard interface is available in the current versions of Digital Unix and
OpenVMS.  It will soon be available on Windows, presumably as a separately
orderable product.  The implementations of the standard interface are not
connected with DCE in any way.  For instructions on building multithreaded code
on various platforms, see a current version of The Guide to DECthreads.

.0> are there predefined symbols that I can use to test what
.0> threads standard my source code is being compiled under,
.0> so I can do something like:

On platforms where the standard interface is available, DECthreads uses the
C-preprocessor symbol "_PTHREAD_USE_D4" to indicate that the compilation should
use the obsolete 1003.4a/D4 interface instead of the standard one.  In the
absence of this symbol being defined, the compilation uses the standard
interface definitions.


				Webb

>>>On Digital Unix and OpenVMS, all code currently under active development 
>>>should be implemented using or migrated to use the 1003.1c standard 
>>>interface.  The 1003.4a/D4 interface will be removed from these systems 
>>>in an up-coming release, and it will no longer be available for use by 
>>>newly compiled or re-linked code. 

So what is the the exact timeframe for the removal of the 1003.4a/D4
interface from the various platforms?  Have release(s) already been
targeted for pulling this support, if so when?

thanks
Rich

.2> So what is the the exact timeframe for the removal of the 1003.4a/D4
.2> interface from the various platforms?  Have release(s) already been
.2> targeted for pulling this support, if so when?

I would suggest that the following expectations were appropriate.

On the next functional release of OpenVMS following V7.2 (presumably V7.3)
and the next functional release of Digital Unix following V4.1 (presumably
V4.2) the obsolete POSIX 1003.4a/D4 interface will be "retired" (i.e.,
removed from the system).  You will no longer be able to compile source code
which uses the 1003.4a/D4 interface (i.e., the header files will not be
available). Furthermore, you will not be able to re-link objects which
reference the 1003.4a/D4 routines (i.e., if you're lucky, you will get
warnings, otherwise the 1003.4a/D4 references will be resolved to the
standard interface definitions and thus will not function as you expect).

The "cma_" and "cma$" interfaces will be "obsoleted" (at least on OpenVMS;
they may be "retired" on Digital Unix...).  This means that they will
continue to be available for support of existing software components.
However, they will no longer be documented, and all software under active
developement should be migrated to use the standard interface.

For the intermediate-term future, existing, linked binaries (executables and
shared images/libraries) should continue to work, even if they use the
obsolete 1003.4a/D4 interface.  Nevertheless, we expect to remove even binary
compatibility for the obsolete 1003.4a/D4 interface at some point in the
future, so you should not depend on being able to build on an older version
of the OS as a way to "get around" the removal of the 1003.4a/D4 interface.

One note:  DECthreads is committed to supporting the use of the 1003.4a/D4
interface in Digital's DCE products even after the interface is "retired".
The source code for these products is controlled by the Open Software
Foundation, and so DCE is unable to upgrade to the final standard until the
other consortium members agree.  However, DECthreads does not anticipate
extending this support to any other products nor to any DCE consumers.

We have warned people ever since we published the 1003.4a/D4 interface that
it would be "going away" with no upward compatibility.  That time is nearly
here, and any consumers of the obsolete 1003.4a/D4 interface should now be
migrating to the standard interface, if they have not already done so, now
that it is widely available.

					Webb

ACMSxp, as well as other products include DCE header files that contain 
references to pthreads.  These references are of the draft 4
variety.  In addition ACMSxp uses the DCE IDL compiler which generates
multithreaded code as well.

When the draft four standard is retired while ACMSxp may have
changed its code to use the new draft standard we will still be including
DCE header files that still use the old draft 4 standard, the code is not going 
to compile.  Evidently Transarc (which ships Encina) already tried to move
to the new draft 10 standard but were stopped by exactly this problem.

It seems to us that consumers of DCE will need the ability to compile and link
against the D4 standard until DCE ships with a version of DCE that works with 
the new draft standard.

Perhaps bundling the D4 interface with DCE is the way to handle this?

rich

.4> When the draft four standard is retired while ACMSxp may have changed its 
.4> code to use the new draft standard 

Um...it's not a "new draft standard", it's a formally accepted and official
_standard_ (no more drafts -- it's final!).

.4> we will still be including DCE header files that still use the old draft 4
.4> standard, the code is not going to compile.

While DCE uses P1003.4a/D4 internally, it's interface does not, with two
exceptions -- there are two data structures, dce_svc_prolog_t and
dce_svc_log_prolog_t, which have imbedded pthread data structures.  We will
contact the DCE folks to determine how this dependency can be removed.

Note that the IDL stubs do make free use of pthreads.  However, since the stubs
are compiled separately, they do not confer or require any dependency on threads
in the application code.  Thus, the application code can be migrated to the
standard interface and recompiled without affecting or being affected by the
stub code.  However, there -is- an issue around regenerating and recompiling the
stubs themselves (not to mention relinking them) which we will have to consider.

.4> It seems to us that consumers of DCE will need the ability to compile and 
.4> link against the D4 standard until DCE ships with a version of DCE that 
.4> works with the new draft standard.
.4> 
.4> Perhaps bundling the D4 interface with DCE is the way to handle this?

Consumers of DCE will only need special support to be able to compile and relink
RPC stubs; the rest of things should be clean (I assert).  It may indeed be that
the way to handle this is to provide the "magic" required to do this with DCE. 
That's TBD.


				Webb

> Consumers of DCE will only need special support to be able to compile and
> relink RPC stubs; the rest of things should be clean (I assert).

While I guess this (as further explained in the previous replies) satisfies
the letter of the agreement that OpenVMS DCE has with the Threads group for
support of the old interface, it's definitely not what we had in mind when
doing so.  It was my belief that the old interface would be supported not
just for DCE, but also for consumers of DCE as well.  This new view comes as
a surprise to me as Project Leader of DCE for OpenVMS.  I'm sure that this
happened due to a lack of detail in the communication between our groups,
and not because of any intent to undermine the agreement.  Certainly, we'll
need to discuss this further.

> It may indeed be that the way to handle this is to provide the "magic"
> required to do this with DCE.  That's TBD.

Ouch!  I you can provide a "magician" to help with this, if we have to go
this route.  :-)   Let's take this offline for a more complete discussion
of what needs to happen, and we'll come back and report here when we have a
plan in place.

						Wayne

.6> This new view comes as a surprise to me as Project Leader of DCE for
.6> OpenVMS.

Actually, the fact that the DCE interface includes pthread objects comes as
a shock to me!  :-}  My expectation was that DCE only used pthreads
internally, and therefore there was no need to extend special support to DCE
consumers.

.6> Certainly, we'll need to discuss this further.

Certainly.


				Webb