ucx$c_full_duplex_close and Multinet BG: driver dilema - VMS

This is a discussion on ucx$c_full_duplex_close and Multinet BG: driver dilema - VMS ; Hi, Alpha VMS 7.3-1 and Multinet 5.0 and the $QIO interface to the BG: driver. When I try to set the Socket Option ucx$c_full_duplex_close (on its own, or in the same call to create the socket) I get SS$_PROTOCOL returned. ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: ucx$c_full_duplex_close and Multinet BG: driver dilema

  1. ucx$c_full_duplex_close and Multinet BG: driver dilema

    Hi,

    Alpha VMS 7.3-1 and Multinet 5.0 and the $QIO interface to the BG: driver.

    When I try to set the Socket Option ucx$c_full_duplex_close (on its own, or
    in the same call to create the socket) I get SS$_PROTOCOL returned.

    This option is obviously available in UCX, and the TCPWare docs say it's
    been supported for the last ten years but somehow it's never been included
    with Multinet. Is that correct? Is there a version later than 5.0 that
    supports it?

    I'm now having to code around the problem (by trying for FDC and if I get
    ss$_protocol then drop the option) but full_duplex_close is a pretty damned
    useful piece of functionality and I'm really curious as to the reasons
    behind the lack of support or whether there are any plans to include it in a
    future version?

    Cheers Richard Maher



  2. Re: ucx$c_full_duplex_close and Multinet BG: driver dilema

    Richard Maher wrote:
    >
    > Hi,
    >
    > Alpha VMS 7.3-1 and Multinet 5.0 and the $QIO interface to the BG: driver.
    >
    > When I try to set the Socket Option ucx$c_full_duplex_close (on its own, or
    > in the same call to create the socket) I get SS$_PROTOCOL returned.
    >
    > This option is obviously available in UCX, and the TCPWare docs say it's
    > been supported for the last ten years but somehow it's never been included
    > with Multinet. Is that correct? Is there a version later than 5.0 that
    > supports it?
    >
    > I'm now having to code around the problem (by trying for FDC and if I get
    > ss$_protocol then drop the option) but full_duplex_close is a pretty damned
    > useful piece of functionality and I'm really curious as to the reasons
    > behind the lack of support or whether there are any plans to include it in a
    > future version?


    I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC will
    respond.

    --
    David J Dachtera
    dba DJE Systems
    http://www.djesys.com/

    Unofficial OpenVMS Marketing Home Page
    http://www.djesys.com/vms/market/

    Unofficial Affordable OpenVMS Home Page:
    http://www.djesys.com/vms/soho/

    Unofficial OpenVMS-IA32 Home Page:
    http://www.djesys.com/vms/ia32/

    Unofficial OpenVMS Hobbyist Support Page:
    http://www.djesys.com/vms/support/

  3. Re: ucx$c_full_duplex_close and Multinet BG: driver dilema

    > I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC will
    > respond.


    Thanks David,

    I've been told the issue still exists in 5.1 and I couldn't find any
    SO_FULL_DUPLEX in the Multinet Docs (That seem to have all the other
    SO_NODELAY etc) so I'm resigned to making the code changes, but you never
    know something might pop-up.

    Cheers Richard Maher

    "David J Dachtera" wrote in message
    news:46A22998.AA9FBC45@spam.comcast.net...
    > Richard Maher wrote:
    > >
    > > Hi,
    > >
    > > Alpha VMS 7.3-1 and Multinet 5.0 and the $QIO interface to the BG:

    driver.
    > >
    > > When I try to set the Socket Option ucx$c_full_duplex_close (on its own,

    or
    > > in the same call to create the socket) I get SS$_PROTOCOL returned.
    > >
    > > This option is obviously available in UCX, and the TCPWare docs say it's
    > > been supported for the last ten years but somehow it's never been

    included
    > > with Multinet. Is that correct? Is there a version later than 5.0 that
    > > supports it?
    > >
    > > I'm now having to code around the problem (by trying for FDC and if I

    get
    > > ss$_protocol then drop the option) but full_duplex_close is a pretty

    damned
    > > useful piece of functionality and I'm really curious as to the reasons
    > > behind the lack of support or whether there are any plans to include it

    in a
    > > future version?

    >
    > I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC will
    > respond.
    >
    > --
    > David J Dachtera
    > dba DJE Systems
    > http://www.djesys.com/
    >
    > Unofficial OpenVMS Marketing Home Page
    > http://www.djesys.com/vms/market/
    >
    > Unofficial Affordable OpenVMS Home Page:
    > http://www.djesys.com/vms/soho/
    >
    > Unofficial OpenVMS-IA32 Home Page:
    > http://www.djesys.com/vms/ia32/
    >
    > Unofficial OpenVMS Hobbyist Support Page:
    > http://www.djesys.com/vms/support/





  4. Multinet OOB (non-inline) character processing

    Hi,

    This question's easier than the first one so please help if you've done
    this. I'd simply like to see a $QIO _BG: driver example example of a server
    (or client) receiving an OOB character (*NOT* IN-LINED) from their partner
    and displaying it. I have code that works perfectly well on UCX and TCPware
    but on Multinet the following happens: -

    My works and the AST fires as expected.
    Then I go to read the OOB character with a $qio
    plus ucx$c_msg_oob as P4 - and the results I get vary from ss$_badparam to
    ss$_suspended
    So I say great, it was a false alarm and reset the OOBATTN AST which then
    fires immediately and says "Nope there's definitely an OOB character here!
    (It's just that we're not gonna let you read it, so loop around madly for a
    while :-)"

    Has anyone else experienced this or alternatively got a working example
    they'd be willing to share?

    Is the ss$_badparam really telling me there's a bad parameter and not just a
    missing OOB?
    Would a previous io$_sensemode have interfered with the sioatmark?
    Is there some incantation or dead-chicken-waving such as
    rather than using P4 flags?
    (As a side issue and although I can't produce an example here, I am also
    open to the idea that elsewhere Multinet will return a ss$_suspended to a
    non-blocking read even if the pipe is broken, but that's one for another
    day)

    I must be doing something wrong but the fact that it's rockin' and rollin'
    on UCX is a bit off-putting.

    Thanks for any help.

    Cheers Richard Maher

    PS. Is it just me that thinks TCPware is a *whole* lot more UCX BG Driver
    compatible than Multinet?


    "David J Dachtera" wrote in message
    news:46A22998.AA9FBC45@spam.comcast.net...
    > Richard Maher wrote:
    > >
    > > Hi,
    > >
    > > Alpha VMS 7.3-1 and Multinet 5.0 and the $QIO interface to the BG:

    driver.
    > >
    > > When I try to set the Socket Option ucx$c_full_duplex_close (on its own,

    or
    > > in the same call to create the socket) I get SS$_PROTOCOL returned.
    > >
    > > This option is obviously available in UCX, and the TCPWare docs say it's
    > > been supported for the last ten years but somehow it's never been

    included
    > > with Multinet. Is that correct? Is there a version later than 5.0 that
    > > supports it?
    > >
    > > I'm now having to code around the problem (by trying for FDC and if I

    get
    > > ss$_protocol then drop the option) but full_duplex_close is a pretty

    damned
    > > useful piece of functionality and I'm really curious as to the reasons
    > > behind the lack of support or whether there are any plans to include it

    in a
    > > future version?

    >
    > I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC will
    > respond.
    >
    > --
    > David J Dachtera
    > dba DJE Systems
    > http://www.djesys.com/
    >
    > Unofficial OpenVMS Marketing Home Page
    > http://www.djesys.com/vms/market/
    >
    > Unofficial Affordable OpenVMS Home Page:
    > http://www.djesys.com/vms/soho/
    >
    > Unofficial OpenVMS-IA32 Home Page:
    > http://www.djesys.com/vms/ia32/
    >
    > Unofficial OpenVMS Hobbyist Support Page:
    > http://www.djesys.com/vms/support/




  5. Problem spec refinement (was: Re: Multinet OOB (non-inline) character processing)

    Hi,

    We can leave the red-herring io$m_nowait/ss$_suspend issue behind us; UCX
    doesn't care if the NOWAIT is dropped from the OOB Read, so I'm willing to
    concede that it was superfluous and may have only served to confuse
    Multinet. (It seems it is impossible to do an asynchronous
    and have the completion AST *only* fire when
    the OOB has arrived; if it's not there then ss$_badparam is returned) This
    is great, I can work with this!)

    The problem remains that after an interrupt has arrived and been read
    sucessfully by a $qio *or* io$readvblk with P4
    as ucx$c_msg_oob, the next setting of the OOB Attention AST
    completes immediately (next AST) with
    ss$_badparam returned to the subsequent OOB read. (And the tight CPU loop
    ensues)

    Diagnosis: a) The successful read of the OOB character is not cleaning up
    and resetting the OOB-present flag to say that it's gone or b) The
    io$setmode!io$m_oobattn function is not seeing the flag after being reset.

    I vote for a) 'cos I've done a $dclast to do the reset, in case AST
    reentrancy issues were involved, and I've toggled between
    and io$_readvblk + ucx$c_msg_oob and I just
    don't have any levers left to pull :-(

    I've got two sheep stations and an oil-rig that says Multinet is not
    resetting the OOB flag after a succesful oob read; Let's see your cards! Any
    chance someone's gonna fix this?

    Nobody using OOB functionality with Multinet? No application development
    with Multinet/ Just use the spoon-fed tools out of the box? If it ain't SSH
    it just ain't? You really need UCX if you're serious about rolling your own?

    Cheers Richard Maher

    PS. I've also tried *not* resetting the OOB AST a second time to see if
    Multinet is a set and forget type of thing, but then it only fires the once
    (as documented).

    PPS. I'm the guy that found the buffer-overflowing stack-corrupter that is
    Multinet's io$_acpcontrol (at least for inetacp$c_trans
    inetacp_func$c_gethostbyaddr).

    PPPS. I still believe Multinet is trigger-happy with ss$_suspend leading it
    to conceal a broken network connection when ss$_linkdiscon would be the
    appropriate error status, but I'll have to change my OOBATTN testing to
    READATTN testing and that issue isn't really bothering me anyway. (If I'm
    wrong I will report back)

    "Richard Maher" wrote in message
    news:f8haps$o5a$1@news-01.bur.connect.com.au...
    > Hi,
    >
    > This question's easier than the first one so please help if you've done
    > this. I'd simply like to see a $QIO _BG: driver example example of a

    server
    > (or client) receiving an OOB character (*NOT* IN-LINED) from their partner
    > and displaying it. I have code that works perfectly well on UCX and

    TCPware
    > but on Multinet the following happens: -
    >
    > My works and the AST fires as expected.
    > Then I go to read the OOB character with a $qio
    > plus ucx$c_msg_oob as P4 - and the results I get vary from ss$_badparam to
    > ss$_suspended
    > So I say great, it was a false alarm and reset the OOBATTN AST which then
    > fires immediately and says "Nope there's definitely an OOB character here!
    > (It's just that we're not gonna let you read it, so loop around madly for

    a
    > while :-)"
    >
    > Has anyone else experienced this or alternatively got a working example
    > they'd be willing to share?
    >
    > Is the ss$_badparam really telling me there's a bad parameter and not just

    a
    > missing OOB?
    > Would a previous io$_sensemode have interfered with the sioatmark?
    > Is there some incantation or dead-chicken-waving such as
    > rather than using P4 flags?
    > (As a side issue and although I can't produce an example here, I am also
    > open to the idea that elsewhere Multinet will return a ss$_suspended to a
    > non-blocking read even if the pipe is broken, but that's one for another
    > day)
    >
    > I must be doing something wrong but the fact that it's rockin' and rollin'
    > on UCX is a bit off-putting.
    >
    > Thanks for any help.
    >
    > Cheers Richard Maher
    >
    > PS. Is it just me that thinks TCPware is a *whole* lot more UCX BG Driver
    > compatible than Multinet?
    >
    >
    > "David J Dachtera" wrote in message
    > news:46A22998.AA9FBC45@spam.comcast.net...
    > > Richard Maher wrote:
    > > >
    > > > Hi,
    > > >
    > > > Alpha VMS 7.3-1 and Multinet 5.0 and the $QIO interface to the BG:

    > driver.
    > > >
    > > > When I try to set the Socket Option ucx$c_full_duplex_close (on its

    own,
    > or
    > > > in the same call to create the socket) I get SS$_PROTOCOL returned.
    > > >
    > > > This option is obviously available in UCX, and the TCPWare docs say

    it's
    > > > been supported for the last ten years but somehow it's never been

    > included
    > > > with Multinet. Is that correct? Is there a version later than 5.0 that
    > > > supports it?
    > > >
    > > > I'm now having to code around the problem (by trying for FDC and if I

    > get
    > > > ss$_protocol then drop the option) but full_duplex_close is a pretty

    > damned
    > > > useful piece of functionality and I'm really curious as to the reasons
    > > > behind the lack of support or whether there are any plans to include

    it
    > in a
    > > > future version?

    > >
    > > I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC

    will
    > > respond.
    > >
    > > --
    > > David J Dachtera
    > > dba DJE Systems
    > > http://www.djesys.com/
    > >
    > > Unofficial OpenVMS Marketing Home Page
    > > http://www.djesys.com/vms/market/
    > >
    > > Unofficial Affordable OpenVMS Home Page:
    > > http://www.djesys.com/vms/soho/
    > >
    > > Unofficial OpenVMS-IA32 Home Page:
    > > http://www.djesys.com/vms/ia32/
    > >
    > > Unofficial OpenVMS Hobbyist Support Page:
    > > http://www.djesys.com/vms/support/

    >
    >




  6. Re: Problem spec refinement

    Richard Maher wrote:

    >
    > I've got two sheep stations and an oil-rig that says Multinet is not
    > resetting the OOB flag after a succesful oob read; Let's see your cards! Any
    > chance someone's gonna fix this?


    I won't take that bet. I will bet that an upcoming UCXDRIVER ECO will contain
    a fix for this.


    >
    > Nobody using OOB functionality with Multinet? No application development
    > with Multinet/ Just use the spoon-fed tools out of the box? If it ain't SSH
    > it just ain't? You really need UCX if you're serious about rolling your own?
    >


    I can't recall a customer call that ever mentioned OOB. I don't know if any
    of the MultiNet applications make use of it, I think telnet might but it
    doesn't use BG. We try to make Multinet's UCXDRIVER compatible with UCX's
    but obviously we sometimes fail. We do try to fix things when they are reported
    to us.

    regards
    Mike





    > Cheers Richard Maher
    >
    > PS. I've also tried *not* resetting the OOB AST a second time to see if
    > Multinet is a set and forget type of thing, but then it only fires the once
    > (as documented).
    >
    > PPS. I'm the guy that found the buffer-overflowing stack-corrupter that is
    > Multinet's io$_acpcontrol (at least for inetacp$c_trans
    > inetacp_func$c_gethostbyaddr).
    >
    > PPPS. I still believe Multinet is trigger-happy with ss$_suspend leading it
    > to conceal a broken network connection when ss$_linkdiscon would be the
    > appropriate error status, but I'll have to change my OOBATTN testing to
    > READATTN testing and that issue isn't really bothering me anyway. (If I'm
    > wrong I will report back)
    >
    > "Richard Maher" wrote in message
    > news:f8haps$o5a$1@news-01.bur.connect.com.au...
    >> Hi,
    >>
    >> This question's easier than the first one so please help if you've done
    >> this. I'd simply like to see a $QIO _BG: driver example example of a

    > server
    >> (or client) receiving an OOB character (*NOT* IN-LINED) from their partner
    >> and displaying it. I have code that works perfectly well on UCX and

    > TCPware
    >> but on Multinet the following happens: -
    >>
    >> My works and the AST fires as expected.
    >> Then I go to read the OOB character with a $qio
    >> plus ucx$c_msg_oob as P4 - and the results I get vary from ss$_badparam to
    >> ss$_suspended
    >> So I say great, it was a false alarm and reset the OOBATTN AST which then
    >> fires immediately and says "Nope there's definitely an OOB character here!
    >> (It's just that we're not gonna let you read it, so loop around madly for

    > a
    >> while :-)"
    >>
    >> Has anyone else experienced this or alternatively got a working example
    >> they'd be willing to share?
    >>
    >> Is the ss$_badparam really telling me there's a bad parameter and not just

    > a
    >> missing OOB?
    >> Would a previous io$_sensemode have interfered with the sioatmark?
    >> Is there some incantation or dead-chicken-waving such as
    >> rather than using P4 flags?
    >> (As a side issue and although I can't produce an example here, I am also
    >> open to the idea that elsewhere Multinet will return a ss$_suspended to a
    >> non-blocking read even if the pipe is broken, but that's one for another
    >> day)
    >>
    >> I must be doing something wrong but the fact that it's rockin' and rollin'
    >> on UCX is a bit off-putting.
    >>
    >> Thanks for any help.
    >>
    >> Cheers Richard Maher
    >>
    >> PS. Is it just me that thinks TCPware is a *whole* lot more UCX BG Driver
    >> compatible than Multinet?
    >>
    >>
    >> "David J Dachtera" wrote in message
    >> news:46A22998.AA9FBC45@spam.comcast.net...
    >>> Richard Maher wrote:
    >>>> Hi,
    >>>>
    >>>> Alpha VMS 7.3-1 and Multinet 5.0 and the $QIO interface to the BG:

    >> driver.
    >>>> When I try to set the Socket Option ucx$c_full_duplex_close (on its

    > own,
    >> or
    >>>> in the same call to create the socket) I get SS$_PROTOCOL returned.
    >>>>
    >>>> This option is obviously available in UCX, and the TCPWare docs say

    > it's
    >>>> been supported for the last ten years but somehow it's never been

    >> included
    >>>> with Multinet. Is that correct? Is there a version later than 5.0 that
    >>>> supports it?
    >>>>
    >>>> I'm now having to code around the problem (by trying for FDC and if I

    >> get
    >>>> ss$_protocol then drop the option) but full_duplex_close is a pretty

    >> damned
    >>>> useful piece of functionality and I'm really curious as to the reasons
    >>>> behind the lack of support or whether there are any plans to include

    > it
    >> in a
    >>>> future version?
    >>> I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC

    > will
    >>> respond.
    >>>
    >>> --
    >>> David J Dachtera
    >>> dba DJE Systems
    >>> http://www.djesys.com/
    >>>
    >>> Unofficial OpenVMS Marketing Home Page
    >>> http://www.djesys.com/vms/market/
    >>>
    >>> Unofficial Affordable OpenVMS Home Page:
    >>> http://www.djesys.com/vms/soho/
    >>>
    >>> Unofficial OpenVMS-IA32 Home Page:
    >>> http://www.djesys.com/vms/ia32/
    >>>
    >>> Unofficial OpenVMS Hobbyist Support Page:
    >>> http://www.djesys.com/vms/support/

    >>

    >
    >


  7. Re: Problem spec refinement

    Hi Michael,

    Thanks for the reply and please let me take this opportunity to publicly
    thank Richard Whalen for his help and solutions with these issues.

    > I will bet that an upcoming UCXDRIVER ECO will contain
    > a fix for this.


    I fold. (Evidently a wise decision :-)

    > I can't recall a customer call that ever mentioned OOB. I don't know if

    any
    > of the MultiNet applications make use of it, I think telnet might but it
    > doesn't use BG.


    Don't feel too bad; Java Server Sockets don't even provide a way to get the
    OOB (unless inlined). But OOBs are an extremely useful server-interrupt
    mechanism and I'm willing to wager that a lot more of your customers will be
    using them in the not too distant future.

    > We try to make Multinet's UCXDRIVER compatible with UCX's
    > but obviously we sometimes fail. We do try to fix things when they are

    reported
    > to us.


    No one can question the veracity of those statements on this occasion.

    Thanks again.

    Cheers Richard Maher

    PS. I said I'd report back on the ss$_suspend issue; here 'tis: -

    1) If you specify the io$m_nowait when attemting to read an OOB then
    Multinet always returns ss$_suspend even if the OOB character is there. It
    appears that io$m_nowait is inappropriate for OOB reads as there is no such
    thing as an asynchronous/delayed OOB with sockets. (If it's there you get it
    and if it isn't you get ss$_badparam) I've changed my code to drop the
    io$m_nowait modifier and, to date, am happy but I just wanted to point out
    that UCX simply ignores it.

    2) My other guess (About read attention ASTs and ss$_suspend) turned out to
    be wrong. It's actually *ss$_shut* that is the problem :-( Please *never,
    ever, ever* return this status unless the network is shutting down. I
    observed this behaviour with 5.0: -

    When a read attention AST is outstanding and the client closes the
    connection then the AST fires just as it should (and as UCX does) but a
    subsequent (Hey, we're in a Read Attention AST so
    there should be something there to read, right?) returns ss$_shut instead of
    ss$_linkdiscon. I have had to code around this by using an asynchronous read
    (as opposed to the readattn AST) and once again, to date, am happy, but it
    is another inconsistency with UCX and the inappropriate use of the "Networks
    going down people" status is a concern.


    "Michael Corbett" wrote in message
    news:46B08B79.1040907@process.com...
    > Richard Maher wrote:
    >
    > >
    > > I've got two sheep stations and an oil-rig that says Multinet is not
    > > resetting the OOB flag after a succesful oob read; Let's see your cards!

    Any
    > > chance someone's gonna fix this?

    >
    > I won't take that bet. I will bet that an upcoming UCXDRIVER ECO will

    contain
    > a fix for this.
    >
    >
    > >
    > > Nobody using OOB functionality with Multinet? No application development
    > > with Multinet/ Just use the spoon-fed tools out of the box? If it ain't

    SSH
    > > it just ain't? You really need UCX if you're serious about rolling your

    own?
    > >

    >
    > I can't recall a customer call that ever mentioned OOB. I don't know if

    any
    > of the MultiNet applications make use of it, I think telnet might but it
    > doesn't use BG. We try to make Multinet's UCXDRIVER compatible with

    UCX's
    > but obviously we sometimes fail. We do try to fix things when they are

    reported
    > to us.
    >
    > regards
    > Mike
    >
    >
    >
    >
    >
    > > Cheers Richard Maher
    > >
    > > PS. I've also tried *not* resetting the OOB AST a second time to see if
    > > Multinet is a set and forget type of thing, but then it only fires the

    once
    > > (as documented).
    > >
    > > PPS. I'm the guy that found the buffer-overflowing stack-corrupter that

    is
    > > Multinet's io$_acpcontrol (at least for inetacp$c_trans
    > > inetacp_func$c_gethostbyaddr).
    > >
    > > PPPS. I still believe Multinet is trigger-happy with ss$_suspend leading

    it
    > > to conceal a broken network connection when ss$_linkdiscon would be the
    > > appropriate error status, but I'll have to change my OOBATTN testing to
    > > READATTN testing and that issue isn't really bothering me anyway. (If

    I'm
    > > wrong I will report back)
    > >
    > > "Richard Maher" wrote in message
    > > news:f8haps$o5a$1@news-01.bur.connect.com.au...
    > >> Hi,
    > >>
    > >> This question's easier than the first one so please help if you've done
    > >> this. I'd simply like to see a $QIO _BG: driver example example of a

    > > server
    > >> (or client) receiving an OOB character (*NOT* IN-LINED) from their

    partner
    > >> and displaying it. I have code that works perfectly well on UCX and

    > > TCPware
    > >> but on Multinet the following happens: -
    > >>
    > >> My works and the AST fires as expected.
    > >> Then I go to read the OOB character with a $qio


    > >> plus ucx$c_msg_oob as P4 - and the results I get vary from ss$_badparam

    to
    > >> ss$_suspended
    > >> So I say great, it was a false alarm and reset the OOBATTN AST which

    then
    > >> fires immediately and says "Nope there's definitely an OOB character

    here!
    > >> (It's just that we're not gonna let you read it, so loop around madly

    for
    > > a
    > >> while :-)"
    > >>
    > >> Has anyone else experienced this or alternatively got a working example
    > >> they'd be willing to share?
    > >>
    > >> Is the ss$_badparam really telling me there's a bad parameter and not

    just
    > > a
    > >> missing OOB?
    > >> Would a previous io$_sensemode have interfered with the sioatmark?
    > >> Is there some incantation or dead-chicken-waving such as
    > >> rather than using P4 flags?
    > >> (As a side issue and although I can't produce an example here, I am

    also
    > >> open to the idea that elsewhere Multinet will return a ss$_suspended to

    a
    > >> non-blocking read even if the pipe is broken, but that's one for

    another
    > >> day)
    > >>
    > >> I must be doing something wrong but the fact that it's rockin' and

    rollin'
    > >> on UCX is a bit off-putting.
    > >>
    > >> Thanks for any help.
    > >>
    > >> Cheers Richard Maher
    > >>
    > >> PS. Is it just me that thinks TCPware is a *whole* lot more UCX BG

    Driver
    > >> compatible than Multinet?
    > >>
    > >>
    > >> "David J Dachtera" wrote in message
    > >> news:46A22998.AA9FBC45@spam.comcast.net...
    > >>> Richard Maher wrote:
    > >>>> Hi,
    > >>>>
    > >>>> Alpha VMS 7.3-1 and Multinet 5.0 and the $QIO interface to the BG:
    > >> driver.
    > >>>> When I try to set the Socket Option ucx$c_full_duplex_close (on its

    > > own,
    > >> or
    > >>>> in the same call to create the socket) I get SS$_PROTOCOL returned.
    > >>>>
    > >>>> This option is obviously available in UCX, and the TCPWare docs say

    > > it's
    > >>>> been supported for the last ten years but somehow it's never been
    > >> included
    > >>>> with Multinet. Is that correct? Is there a version later than 5.0

    that
    > >>>> supports it?
    > >>>>
    > >>>> I'm now having to code around the problem (by trying for FDC and if I
    > >> get
    > >>>> ss$_protocol then drop the option) but full_duplex_close is a pretty
    > >> damned
    > >>>> useful piece of functionality and I'm really curious as to the

    reasons
    > >>>> behind the lack of support or whether there are any plans to include

    > > it
    > >> in a
    > >>>> future version?
    > >>> I've cross-posted to the Multinet newsgroup. Perhaps someone from PSC

    > > will
    > >>> respond.
    > >>>
    > >>> --
    > >>> David J Dachtera
    > >>> dba DJE Systems
    > >>> http://www.djesys.com/
    > >>>
    > >>> Unofficial OpenVMS Marketing Home Page
    > >>> http://www.djesys.com/vms/market/
    > >>>
    > >>> Unofficial Affordable OpenVMS Home Page:
    > >>> http://www.djesys.com/vms/soho/
    > >>>
    > >>> Unofficial OpenVMS-IA32 Home Page:
    > >>> http://www.djesys.com/vms/ia32/
    > >>>
    > >>> Unofficial OpenVMS Hobbyist Support Page:
    > >>> http://www.djesys.com/vms/support/
    > >>

    > >
    > >




+ Reply to Thread