Dan:
   I'm going to ask the obvious...have you contacted IBM support?  They're
   pretty good about tracking down problems and either finding solutions or
   work-arounds.  Wally is especially good about these kinds of things.
   HTH,
   Bill
   ______________________________________________________________________

   From: Dan McGrath <dmc...@imb.com.au>
   Sent: 1/14/2009 4:21 PM
   To: u2-users@listserver.u2ug.org
   Subject: [U2][UD] Named pipe issue.

Hi all,

Just a quick introduction... I am a developer at a medium-sized
financial institution in Australia. I've being working with Unidata for
the last 2 years and have been quite surprised with the whole MultiValue
system and its flexibility.

Recently I've been tasked to determine the cause and find a solution to
an annoy intermittent issue that has been experienced by one of our
systems that links into Unidata.

The part in question is a C daemon which talks to a Phantom process via
Named pipes. Approximately every 15000 requests, the Phantom writes a
response to the C daemon, which is never received.

I've traced it down to the following lines of code and am starting to
suspect a bug in Unidata (We run 7.1)

The C daemon blocks at this line:

        Fd = open(Pipe, O_RDONLY);

(Pipe is a named pipe)

The associated lines in the Phantom that are running are:

      OSOPEN PIPE.NAME TO PIPE.HANDLE ON ERROR
                * <snip> just error handling and logging
                RETURN
        END ELSE
                * <snip> just error handling and logging
                RETURN
      END
      OSWRITE PIPE.DATA TO PIPE.NAME ON ERROR
                * <snip> just error handling and logging
                RETURN
        END
      OSCLOSE PIPE.HANDLE
        *<snip> more logging.

While the C daemon is blocking at open, the Phantom apparently
successfully opens the pipe and writes to it without error. None of the
error logging code is touched and the logging after is.

Obviously, being a named pipe, open and OSOPEN will block until they are
both at that point. It appears that open does not believe the pipe has
been opened by the Phantom. The requests that fail are exactly the same
as the requests that succeed. Both data and logging output.

This leads me to believe that either our UNIX system has a problem with
the open call or Unidata has an issue with OSOPEN/OSWRITE which is not
being caught by the ON ERROR or ELSE clauses. Using OSBWRITE makes no
difference (Apart from the whole process slowing down?).

Is there something I am missing or has any one else know of a similar
problem in Unidata?

Searching for bug reports etc for Unidata has been painful and
unsuccessful and IBM 'Support' is well... you know.

Thanks for reading!
Dan McGrath
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Reply via email to