Has anyone successfully used $SNDOPR from VAX/DEC C using the structure in OPCDEF.H?

[Mark_Corcoran]

I was adding code to support alerting us to a condition with a PLC stuck in a loop, and initially used $BRKTHRU code I wrote 10+ years ago, but when I came to test it, I found it didn't do what I thought/remembered it did - simply sends a message to all logged in terminals, rather than an OPCOM message to particular operator classes.

So I set about using $SNDOPR, and in the OpenVMS System Services Reference Manual Volume II, there is an example C program.

The manual I had been referring to was for OpenVMS v8.3, and we are some way behind this (OpenVMS/VAX v6.2), but the v8.3 version of the manual gives the structure name as OPC

The v8.4 manual gives the structure name as _opcdef, but when I extract the OPCDEF module from SYS$LIBRARY:DECC$RTLDEF.TLB (we have DEC C v5.5-02), the structure is named as opcdef

I tried using the example from the v8.3 manual (but changing the structure name to opcdef) and - my memory is a little hazy on this now - it wasn't initially working, then it was, then when I increased the size of the message to be delivered, it seemed to stop working entirely (even when I changed it back to the original message size).

After some testing & analysis, it seemed to me that the DEC C-defined structure was not capable of coping with the length of message that $SNDOPR should support (the manual says a condition of SS$_BADPARAM indicates a message length of <0 or >956 bytes, implying that it supports 956 bytes;  HELP REPLY at DCL indicates that up to 511 characters may be specified, and $BRKTHRU (a not entirely dissimilar service) supports up to 16350 bytes).

The example in v8.3 truncates any messages greater than 128 bytes/characters in length, and sizeof(opcdef) was reported as 158 bytes (the opcdef structure is a myriad of unions to cater for different message types, but it includes unsigned int opc$l_ms_otext [32] which would account for 128 bytes/characters (hence perhaps the truncation, but supporting fewer bytes/characters than you could specify from the REPLY command in DCL)).

After setting the opc$b_ms_target element to OPC$M_NM_OPER8 and examining it afterwards, i found that it wasn't set to OPC$M_NM_OPER8 (0x80000 IIRC), but was set to zero...

The v8.4 manual shows the dsc$_btype and dsc$b_class descriptor structure elements being initialised (whereas the v8.3 manual does not), and it also shows the operator class(es) being selected by assignment of values to the opc$z_ms_target_classes[0] through [2] elements of the _opcdef structure (rather than using the opc$b_ms_target structure element that the v8.3 manual uses (the v8.4 example also uses malloc to allocate memory in a manner that looks like it would cate for messages greater than 128 bytes in length)).

[When I tried to use opc$z_ms_target_classes[], I deliberately set them to be [0] = 0x12, [1]=0x34 and [2]=0x56, but I only ended up seeing the 0x56 being set when I subsequently checked the structure values after assigning them]

I've ended up going back to basics, and created a 264-byte buffer (8 bytes to cover the preamble required by $SNDOPR, and 256 bytes for a NULL-terminated 255-character string (I think that $SNDOPR doesn't require the NULL terminator, I'm just lazily taking the original 256-byte NULL-terminated buffer in C that the string is originally formulated in).

I then populate it according to the ZK-1725-GE diagram ("Message Buffer Format for OPC$_RQ_RQST") on page SYS2-538 of the v8.3 manual (order number BA554-90010, July 2006), and this works without problem.

Is one or more versions of the code examples in various version of the manual wrong, or is the C structure definition in OPCDEF.H wrong?

At the time I originally posted this message*, I was only able to find one example online of $SNDOPR being used outside of the example in the system services manual:

https://github.com/openssl/openssl/blob/master/crypto/bio/bss_log.c

I'm not sure whether or not that code had actually ever been used in anger, or was merely a theoretical "the manual says it should work this way".

*I've now edited it to update & correct some typos;  curiously, the original message was subsequently pulled by HPE because the subject or content apparently matched spam filters, though they have fixed/fudged it to get it posted;  whether or not this edited version of the message will similarly fall foul of the filters, I don't know...

[Maybe it was my redacting of vowels in naming other O/Ses that it didn't like]

Mark

[TonyMcGrath]

Whenever you want examples of System Services or RTL functions, the one-stop shop is here: http://www.eight-cubed.com/examples.shtml