× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Wed, 6 Nov 2002, Paul Tykodi wrote:
>
> I am performing some debug tests with lp5250d and certain OS/400 host
> generated error conditions. I have viewed the source (in utility.c) for the
> tn5250_daemon process that is activated by lp5250d and I am having some
> trouble following the logic that activates the sa_flag known as SA_RESTART
> (found under the definition for variable ignsigcld).

When you do a fork() (which we must do to become a daemon) the result
is 'parent' and 'child' processes.  Normally, whenever the child process'
status changes, a signal is sent to the parent process.

The sigaction call in tn5250_daemon() is there to tell the system that
the sig_action() function (also in utility.c) is to be called whenever we
receive this child status signal.

Why do we do this?  Because, normally, once a child process ends, the
system keeps the process active (as a "zombie" process) until the parent
has checked it's status, etc.  So, this sig_child() function does that,
it calls waitpid() to get the child's status so that the child can
exit normally.  In other words, it "cleans up zombie processes".

The SA_RESTART flag says that after the call to the sig_child() process
has completed, we want it to restart the system call.  Why?  Signals are
delivered to a process only when it enters the operating system.  For
example, when the process makes a system call (calls a routine in the
kernel) or when a clock interrupt occurs, etc.   The signal can cause that
system call to be interrupted, and never be executed.  So, we're saying
restart that system call after you've delivered the signal.

In reality, however, this code is never executed in lp5250d.  It is only
executed if ignsigcld is true.  But, when we call tn5250_daemon() we
always pass a zero for that argument.


>
> Specifically I am trying to learn more about the conditions, created
> external to the machine where lp5250d is running, that it will accept as a
> final termination of a connection that was previously established between
> its tn5250_daemon and a host and those that it will perceive as an error in
> which the solution is to perform a restart to try and re-establish a
> connection to the same host with the same lp5250d arguements on a new TCP
> socket connection.
>

AFIAK, lp5250d never re-establishes the connection.  If the socket gets
closed, lp5250d ends.

>
> If anyone could direct me to where in the code the restart logic
> decision process is located, I would appreciate the assistance.
>

The connection is established by calling tn5250_stream_open().  This
appears to only be done in lp5250d.c, and not in any sort of a loop.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.