Conference vaxaxp::vmsnotes

   This appears a UCX question...

   Note that a blind sys$clref(i) is entirely bogus, as it's munging
   the state of event flags potentially not "owned" by this code...

   If you're going to be using event flags and OpenVMS-isms, consider
   using the sys$qio[w] interface into BGDRIVER.

    re .0
    
    It looks like a bug in socket(). You should report it formally to
    whoever owns that routine.

  re .0:

>$! On VAX VMS V6.2 and V7.1:
>State ef's 0
>State ef's 40000000
>Wait on eventflag 63
> Interrupt
>
>$ stop
>
>$! On VMS Alpha V7.1:
>State ef's 0
>State ef's 80000000
>Wait on eventflag 63
>End wait. Status 1
>$

  As you can see from the state mask, EF 63 is set, so it's not surprising
  that you're not waiting. The flag is clear on older versions.

  Your output doesn't actually match your program (which won't compile).
  Rearranging the display of the state mask shows event flag 63 being set
  by the call to socket. Note that although you have allocated the event
  flag, it's not necessarily a fault in "socket". Any algorithm which uses
  an event flag for synchronisation should (must?) be able to deal with false
  settings, so you should pair your event flag with a status block (see
  SYS$SYNCH for a description). By convention, any use of an event flag
  should leave the event flag in SET state, to protect other users against
  missed signals.

  "socket" may be being anti-social, but not necessarily incorrect (but
  that's nothing new from unix derived code on OpenVMS). LIB$GET_EF is
  no more than a "gentleman's agreement" which is not enforced. Further,
  since event flags are a very scarce resource, it's often necessary that
  they be overloaded. If correctly coded, overloadings should not matter.

						John Gillings, Sydney CSC

I experimented with this on V6.2 (Alpha).  If you vary the number of times
you call LIB$GET_EF, then the event flag # that gets set by socket() varies.
It sure looks as if socket() calls LIB$GET_EF too.

Perhaps on V7.1 socket() is built incorrectly, such that it includes its own
copy of LIB$GET_EF, rather than referring to the one in LIBRTL.EXE.  That
would make it think that EF #63 is available when it's not.  This would be
a bug in the way socket is built, in my opinion.  But you should still write
your code in such a way as to defend against an event flag getting spuriously
set...  What is it that you're waiting for in the real application?  That is,
what is the setting of that event flag supposed to represent?

re .1:
>>  Note that a blind sys$clref(i) is entirely bogus, as it's munging
>>  the state of event flags potentially not "owned" by this code...

    Note this is just a reproducer. The customer adds this call to be sure of 
    the environment.

>>  If you're going to be using event flags and OpenVMS-isms, consider
>>  using the sys$qio[w] interface into BGDRIVER.

    Does this means that one should NOT use socket programming while using VMS 
    feature ? This is VERY important to know: this customer is currently looking 
    at various new VMS features to be used, like (kernel) threads. I believe he 
    is looking to event flag as a potential synchronization mechanism in an 
    environment mixing threads and ASTs !

re .3:
>>  Your output doesn't actually match your program (which won't compile).

    Sorry for that, a cut and paste problem. The program is in fact as:

    ...
    //Get socket
    listener = socket (AF_INET, SOCK_STREAM, 0);
    if (listener == -1)
        //cout<<"SocketError "<< listener << endl;
        fprintf( stdout, "SocketError %d \n", listener);

    //Display actual state of eventflags
    sys$readef(efNumber,&state);
    //cout << "State ef's " << hex << state << endl;
    fprintf( stdout, "State ef's %X \n", state);
    ...

    I went further with this example and it appears to me that socket() 
    effectively set the event flag #63. 

>>  Any algorithm which uses an event flag for synchronisation should (must?) 
    be able to deal with false settings, so you should pair your event flag 
    with a status block (see SYS$SYNCH for a description). ...

     I'll feedback this.

re .4:
>>  If you vary the number of times you call LIB$GET_EF, then the event flag 
>>  # that gets set by socket() varies. It sure looks as if socket() calls
>>  LIB$GET_EF too.

    It is what it is expected to do. I continued on VMS 7.1 and got always the 
    same EF 63 set by socket().

In any case, thanks a lot to all of you. I'm escalating the problem to UCX.
Best,
Mich�le.

:>>  Note that a blind sys$clref(i) is entirely bogus, as it's munging
:>>  the state of event flags potentially not "owned" by this code...
:
:    Note this is just a reproducer. The customer adds this call to be sure of 
:    the environment.

   It's still bogus -- you're "spuriously" resetting the event flags,
   which can cause problems for other (poorly-written) code.  And the
   flags can still switch states depending on other activity.  (In other
   words, keep the manipulations to these event flags you have allocated.)

:>>  If you're going to be using event flags and OpenVMS-isms, consider
:>>  using the sys$qio[w] interface into BGDRIVER.
:
:    Does this means that one should NOT use socket programming while using VMS 
:    feature ?

   No, it means that if you are going to "lace" the code with OpenVMS
   features (and are thus not highly concerned with portability), you
   may find the $qio[w] interface far more flexible, and more powerful
   than the traditional UNIX "socket" interface.  Probably the biggest
   benefit: the BGDRIVER interface has AST notification, and this is
   not available via the "socket" interface.

:    This is VERY important to know: this customer is currently looking 
:    at various new VMS features to be used, like (kernel) threads.

   Event flags provide a simple solution to many problems.  They tend
   to get restrictive as more threads are added, and as more complex
   applications are involved...  (I usually prefer to use ASTs, $hiber
   and $wake, and the interlocked primitives -- or use DECthreads...)
  
:    I believe he is looking to event flag as a potential synchronization
:    mechanism in an  environment mixing threads and ASTs !

   Check with the DECthreads folks and see what they recommend here,
   around mixing threads and ASTs.  (And this question has undoubtedly
   already been asked...)

:>>  If you vary the number of times you call LIB$GET_EF, then the event flag 
:>>  # that gets set by socket() varies. It sure looks as if socket() calls
:>>  LIB$GET_EF too.
:
:    It is what it is expected to do. I continued on VMS 7.1 and got always the 
:    same EF 63 set by socket().

   You are jumping to a conclusion based on limited data -- you will not
   always receive event flag 63, save for the simplest of test cases...

   --

   As was mentioned, spurious $wake and spurious event flags should be
   expected.  And one should be *very* careful around the specification
   of ASTs and IOSBs -- there's likely a replacement AST chapter going
   into the "Raven" OpenVMS release Programming Concepts manual...  (It
   is not quite ready, but I may be able to send you a review copy, when
   it becomes available.)

Hi Steve,

My test data are surely limitted by I modify the program to get and set 3 event
flags then call socket(). I may run this program numbers of time, it always get
event flag 63, 62 and 61.

If I don't set the flags, just get them, the socket() set it, but only flag 63.
If I have set the flags then clear then again, socket() doesn't set it ?!

Seems me really strange !

by the way, I'll surely be interested by the update version of the Programming
Concept Manual. I just receive the V7.1 one which seems already interesting.

Best,
Mich�le.

  Search for "CTI_SRC961219005807" and/or for "[DEC TCP/IP] V4.1
  Incorrectly Uses EF Not Allocated By UCX" in COMET...

  There is a patch to the UCX$IPC_SHR image either in progress,
  or available.

  COMET URL: http://comet.alf.dec.com/

Yes Steve,

I effectively found this information meanwhile and applied the patch. It solves
the problem.

Thanks for all,
Mich�le.