Conference help::osi_appl_support

Just lucky.

On OpenVMS, you no longer own the redirected I/O channel because of the way OSI
Transport works, thus the port would be invalid after the redirect.  On UNIX the
redirect mechanism is very different and the fd that you used is still available
for additional inbound connects.  Also, at a very quick glance there are error
conditions which can cause the UNIX port to become invalid if the redirect
operation fails.

I would say that to be "safe" you should treat the port in the manner that the
documentation suggests - close it after a redirect.

--Scott

    
    This problem -- cannot close port after redirect on UNIX -- was known
    by the former OSAK team.  The description that they left is:
    
    "After issuing a successful redirect request an application cannot close
    the port (unless it specifies destructive). No transport disconnect
    indication is received."
    
    Supposedly, this problem was release-noted at some point.
    
    This problem is on our to-do list at a low priority.  If you want it
    moved up on the priority list, please enter an IPMT.
    
    Valerie Miller
    osi applications/osak engineering
    

Scott, Valerie 

	thanks for your input.

The release notes include information regarding the 'destructive' closing of 
the redirected port.

So basically what we have to in our application is to ensure that we issue
a second osak_open_responder before we close the previous port that has just
been redirected? 

I assume OSAK queues any incoming OSAK Associate-requests and passes them onto
the application with the first port # for which an OSAK_GET_EVENT is issued?

How does FTAM on Digital UNIX do it?

John

>before we close the previous port that has just
>been redirected? 

Or pre-open a number of ports.

>I assume OSAK queues any incoming OSAK Associate-requests and passes them onto
>the application with the first port # for which an OSAK_GET_EVENT is issued?

I don't remember if the mechanism is fifo or filo.  I do know that you can use
filo to make some delicious food though.

>How does FTAM on Digital UNIX do it?

The FTAM listener may not be a good example, it's hard to tell who wrote it, but
it looks like someone was learning C at the time.

Anyway, as I glance thru the code......
The ftam listener pre-opens the number of ports specified by the qlen value when
the listener is started.  Then, as each port is redirected, a new port is
opened to replace it:  The FTAM listener code is actually pretty ugly, they walk
the entire list of ports looking for an event (osak_select() w/timeout=0), and
then if no events are found, it blocks in osak_select() on the last port.  So I
guess it's a lifo queue (I'm not sure that behaviour is documented in OSAK, and
so I'd be cautious of using it - I think it would be better to simply pass all
the ports into osak_select() and then figure out which port had the event after
osak_select() returned).  Once a port with an event is found, it's given a
buffer and osak_get_event() is called - if the event is an association
indication then we fork/exec a child and redirect the association to the child;
at which point the port is destructively closed, and a new port opened.

VT on OpenVMS does a similar thing as the FTAM listener, but just passes the
entire list of ports into osak_select() and then walks the list looking for
any/all ports with an event - this removes the dependency on the lifo behaviour
and actually makes the code simpler, since the FTAM listener must poll the
entire list once to see if an event may have happened on the most recent port at
a particular point in time, when the listener was starting.

--Scott