PDA

View Full Version : Exclusive lock on file Hanging system?



Dan OLeary
23-Jun-2005, 09:09 AM
We are replacing Dumb Terminals (Yes I said Dumb Terminals) with PC's and
Factewin terminal emulation
on a Unix Box (AIX).... We had 2 hangups (appears like exclusive lock on
sysfile) since the PC's
were added...

I am re-booting the entire system (shutdown -Fr) in order to clear the
lock....

Questions: How can I find out which station has the lock? or any other
suggestions are welcome? and
lastly What else can cause this type of hangup? I do not think cacheing in
XP and Op-Locks
play a role in this situation???? or does it?


Re-Booting the server is a terrible option.

Thanks in Advance!!!

Regards,
~Dan

Joerg Thuemmler
24-Jun-2005, 02:11 AM
Dan,

can't imagine that this is a terminal emulators work. AFAIK (and we
use terminal emulators an a linux server too) all the locking logic
doesn't depend on any terminals action, so if your servers
application got a key from the terminal, it will act and if not -
not. Inside a transaction no interaction with any input stream,
wherever it comes from, should be done.

IMHO there must be something else wrong.

joerg

Dan OLeary wrote:
> We are replacing Dumb Terminals (Yes I said Dumb Terminals) with PC's and
> Factewin terminal emulation
> on a Unix Box (AIX).... We had 2 hangups (appears like exclusive lock on
> sysfile) since the PC's
> were added...
>
> I am re-booting the entire system (shutdown -Fr) in order to clear the
> lock....
>
> Questions: How can I find out which station has the lock? or any other
> suggestions are welcome? and
> lastly What else can cause this type of hangup? I do not think cacheing in
> XP and Op-Locks
> play a role in this situation???? or does it?
>
>
> Re-Booting the server is a terrible option.
>
> Thanks in Advance!!!
>
> Regards,
> ~Dan
>
>

britk9
25-Jun-2005, 09:33 AM
Dan,

Have only worked a little with Unix stuff and it was a long time ago so take
this with a grain of salt....the dumb terminals were obviously connecting
via serial connections, correct?

Are the PCs with the terminal emulation software also connecting via the
same serial connections or have you changed over to some means of
TCP/IP-to-Serial connection at the server?

Also, if memory serves me, the pin out of a standard serial connection on a
dumb terminal is different than a serial port on a PC (DTE vs DCE). I seem
to recall being able to get a PC with terminal emulation connected but could
never get the echo back to the terminal without changing the pin out.
Shooting a little in the dark here.

Good luck,
Mike

"Dan OLeary" <dano@compadmin.com> wrote in message
news:%23hZ8Tt$dFHA.3408@dacmail.dataaccess.com...
> We are replacing Dumb Terminals (Yes I said Dumb Terminals) with PC's and
> Factewin terminal emulation
> on a Unix Box (AIX).... We had 2 hangups (appears like exclusive lock on
> sysfile) since the PC's
> were added...
>
> I am re-booting the entire system (shutdown -Fr) in order to clear the
> lock....
>
> Questions: How can I find out which station has the lock? or any other
> suggestions are welcome? and
> lastly What else can cause this type of hangup? I do not think cacheing
in
> XP and Op-Locks
> play a role in this situation???? or does it?
>
>
> Re-Booting the server is a terrible option.
>
> Thanks in Advance!!!
>
> Regards,
> ~Dan
>
>

Joerg Thuemmler
27-Jun-2005, 12:45 AM
Mike,

this should be of no influence. TCP/IP or Serial is a question of
how the dataflex application gets the input and sends the output.
Locking and unlocking as mechanics to save data should not contain
user interaction and better no screen output too.
Correct is, that if a running program contains input/output commands
(such as "accept" or "page") and lacks of input/output streams
(stdin/stdout) the program usually stops and maybe with some strange
behavior. For example, a "classic" program containing
....
page screen1
accept screen1.1
....
will break, send to background without io stream redirection:

dfrun program &

but if you have file containing all the needed input:

file1:

Y
1234
test

and the program asks for yesno, a number and a string, then

dfrun program <file1 >file2

will work properly

So out of locking discussions there may be a problem in the answer
behavior of your new terminals disturbing not the locking but the
data output and causing program to hang. I don't know what happens
if your terminal emulation or tcp connection breaks while program is
waiting for input or output. But AFAIK this should be no dataflex
problem too, because df interacts with the pseudo tty (pty) on your
terminal server if doing tcp/ip connection, so df gets no error if
the pty loses connection to the client. DF application simply
outputs all to the pty and if there is no answer it's as you are
sitting before your console - sleeping ;-)

We use "putty" terminal emulator since 1999 now and i've never seen
any problem here, network shutdown, client break, nothing did break
the df apps interacting via ptys.

regards

joerg

britk9 wrote:
> Dan,
>
> Have only worked a little with Unix stuff and it was a long time ago so take
> this with a grain of salt....the dumb terminals were obviously connecting
> via serial connections, correct?
>
> Are the PCs with the terminal emulation software also connecting via the
> same serial connections or have you changed over to some means of
> TCP/IP-to-Serial connection at the server?
>
> Also, if memory serves me, the pin out of a standard serial connection on a
> dumb terminal is different than a serial port on a PC (DTE vs DCE). I seem
> to recall being able to get a PC with terminal emulation connected but could
> never get the echo back to the terminal without changing the pin out.
> Shooting a little in the dark here.
>
> Good luck,
> Mike
>
> "Dan OLeary" <dano@compadmin.com> wrote in message
> news:%23hZ8Tt$dFHA.3408@dacmail.dataaccess.com...
>
>>We are replacing Dumb Terminals (Yes I said Dumb Terminals) with PC's and
>>Factewin terminal emulation
>>on a Unix Box (AIX).... We had 2 hangups (appears like exclusive lock on
>>sysfile) since the PC's
>>were added...
>>
>>I am re-booting the entire system (shutdown -Fr) in order to clear the
>>lock....
>>
>>Questions: How can I find out which station has the lock? or any other
>>suggestions are welcome? and
>>lastly What else can cause this type of hangup? I do not think cacheing
>
> in
>
>>XP and Op-Locks
>>play a role in this situation???? or does it?
>>
>>
>>Re-Booting the server is a terrible option.
>>
>>Thanks in Advance!!!
>>
>>Regards,
>>~Dan
>>
>>
>
>
>

britk9
27-Jun-2005, 07:26 AM
Joerg,

I agree. Was just taking a shot at the problem for Dan. I too have never
experienced a problem with a tty connection of any kind with DF.

Best Regards,
Mike

"Joerg Thuemmler" <listen@vordruckleitverlag.de> wrote in message
news:g1kXrtteFHA.5304@dacmail.dataaccess.com...
> Mike,
>
> this should be of no influence. TCP/IP or Serial is a question of
> how the dataflex application gets the input and sends the output.
> Locking and unlocking as mechanics to save data should not contain
> user interaction and better no screen output too.
> Correct is, that if a running program contains input/output commands
> (such as "accept" or "page") and lacks of input/output streams
> (stdin/stdout) the program usually stops and maybe with some strange
> behavior. For example, a "classic" program containing
> ...
> page screen1
> accept screen1.1
> ...
> will break, send to background without io stream redirection:
>
> dfrun program &
>
> but if you have file containing all the needed input:
>
> file1:
>
> Y
> 1234
> test
>
> and the program asks for yesno, a number and a string, then
>
> dfrun program <file1 >file2
>
> will work properly
>
> So out of locking discussions there may be a problem in the answer
> behavior of your new terminals disturbing not the locking but the
> data output and causing program to hang. I don't know what happens
> if your terminal emulation or tcp connection breaks while program is
> waiting for input or output. But AFAIK this should be no dataflex
> problem too, because df interacts with the pseudo tty (pty) on your
> terminal server if doing tcp/ip connection, so df gets no error if
> the pty loses connection to the client. DF application simply
> outputs all to the pty and if there is no answer it's as you are
> sitting before your console - sleeping ;-)
>
> We use "putty" terminal emulator since 1999 now and i've never seen
> any problem here, network shutdown, client break, nothing did break
> the df apps interacting via ptys.
>
> regards
>
> joerg
>
> britk9 wrote:
> > Dan,
> >
> > Have only worked a little with Unix stuff and it was a long time ago so
take
> > this with a grain of salt....the dumb terminals were obviously
connecting
> > via serial connections, correct?
> >
> > Are the PCs with the terminal emulation software also connecting via the
> > same serial connections or have you changed over to some means of
> > TCP/IP-to-Serial connection at the server?
> >
> > Also, if memory serves me, the pin out of a standard serial connection
on a
> > dumb terminal is different than a serial port on a PC (DTE vs DCE). I
seem
> > to recall being able to get a PC with terminal emulation connected but
could
> > never get the echo back to the terminal without changing the pin out.
> > Shooting a little in the dark here.
> >
> > Good luck,
> > Mike
> >
> > "Dan OLeary" <dano@compadmin.com> wrote in message
> > news:%23hZ8Tt$dFHA.3408@dacmail.dataaccess.com...
> >
> >>We are replacing Dumb Terminals (Yes I said Dumb Terminals) with PC's
and
> >>Factewin terminal emulation
> >>on a Unix Box (AIX).... We had 2 hangups (appears like exclusive lock
on
> >>sysfile) since the PC's
> >>were added...
> >>
> >>I am re-booting the entire system (shutdown -Fr) in order to clear the
> >>lock....
> >>
> >>Questions: How can I find out which station has the lock? or any other
> >>suggestions are welcome? and
> >>lastly What else can cause this type of hangup? I do not think cacheing
> >
> > in
> >
> >>XP and Op-Locks
> >>play a role in this situation???? or does it?
> >>
> >>
> >>Re-Booting the server is a terrible option.
> >>
> >>Thanks in Advance!!!
> >>
> >>Regards,
> >>~Dan
> >>
> >>
> >
> >
> >