Dropped sessions - FACTS 7.5/7.6 on SCO

Has anybody encountered dropped FACTS sessions on 7.5 or 7.6 with SCO that you weren't able to attribute to networking issues? Here's a scenario:

Start a FACTS session, let it sit for some time (30 minutes, an hour).
When you come back to it, it is still on your screen but is unresponsive. You click on the window to give it focus, try to get it to respond, but nothing.
Within a few seconds after that, the window disappears.
You go to the server and your process is still there, orphaned.

We have a customer having this problem (FACTS 7.5.4, SCO 5.0.7) and we also have started having this problem on our internal FACTS 7.6.4/SCO 5.0.7. These are standard WindX client connections (not going through a Terminal Server or anything like that).

If this rings a bell with anybody, any advice/input would be appreciated!

Find more posts tagged with

Comments

Legacy Contributor

Brad,

Sounds like a router-induced timeout. Do you have keepalive turned on? See KB# 995730 for instructions.

0712131256598360.doc

salbritton

Not currently set in pvxhost. We knew that for Windows, but didn't realize applied to Unix also. We'll try that - thanks.

Legacy Contributor

How about the power settings on your PC? Make sure everything is "always on", make sure you do not have anything going into "standby". Also may want to check the NIC card, and make sure it is not going into any kind of "power save". As soon as you have any kind of disconnect to the network, you will lose your FACTS connection.

rainer-gibbert

It would be unusual to require -K for WindX sessions connecting entirely on the LAN because the router would not be involved, only hubs/switches.

I've seen this kind of behavior when there's a data storm of packets flooding the network, not allowing WindX packets to get to the PC. Usually turns out to be a bad PC NIC, bad cable, bad port on hub or switch.

Is it only certain PC's or all PC's?

salbritton

Todd,

We've noticed it in house on at least a couple PCs at our location. I work from a different location, and am connected via router to our network, and I have had it also. So, within the building/network, and external to the building/within the network.

Thanks for the insights! Maybe a hub/switch might be getting a bit flaky, but same behavior at two locations (different networks) with multiple workstations (within the LAN and external to the LAN) having the same behavior when connected to each of the two different networks led us to believe something else.

One commonality between at least two workstations is Windows 7 Pro, with updates turned on for both.

hpocius

What about the PC going to Sleep? Hibernating etc...

salbritton

Marty,

No to sleep & hibernating - both turned off.

hpocius

Battery backup that is failing? where the hub/switch is plugged in.

salbritton

Marty - no, battery backups appear to be good. Would be very ironic if both our customer's battery backup and our battery backup is going, but good things to check!

Diane - I know the file you're referring to - that fixes the "ProvideX has stopped working" message. I have that file. We'll give that a try!

BradleyBrown

We first ran into this on 7.6 installs. Our research into this problem turned up an issue where lack of activity over the link caused a TTL to timeout or something along those lines. We've never been able to nail it down though. We've looked at OS settings, network devices, etc. We've seen the problem on both LAN and WAN connections as well as on both Windows and *nix systems. This includes installs where nthost is using the -k switch.
The scenario we see is when sitting in a program there doesn't appear to be any acitivty while the program loop is waiting for an event to occur. After some time the session just seems to either die and blink off of the screen or the next click causes it to disappear. We've noticed it when a user sits in the program and doesn't do anything and also if the user is entering a lot of data (i.e. taking along time to enter it) in a text field with no tab or mouse activity... The next move they make causes the session to die. In contrast we've noticed that sitting in a menu does not have the same problem. On the server side we see the user's process still running as you've noted.
For 7.6 (and 7.7 when we've seen this problem come up) the solution was to modify SMC905 to include some code to perform some function during the event loop. Opening and closing a file is enough to provide some activity that will keep the session alive.
We didn't see this problem come up until 7.6 and haven't had it reported by any 7.5 customers.

0712131256598360.doc

BradleyBrown

Following is the solution we use on 7.6 and 7.7 systems that exhibit this behavior. Add the code to the programs and then log out of all windx sessions before loggin back in. The file activity in SMC500 is enough to keep the session alive.

START_UP.MOD:
2049 ! set a default timeout procedure for session keep alives
2050 %__timeout=30,%__timeout_proc$="prog/SM/SMC500;session_keep_alive"

SMC500:
11000 SESSION_KEEP_ALIVE:
11005 local kaf,ka_file$=fid(0)+"_ka.txt"
11010 serial ka_file$,err=*next
11020 open (hfn,err=*next)ka_file$; kaf=lfo
11030 close (kaf,err=*next)
11050 _validate_screen=0,__keep_alive=1 ! ( __keep_alive is referenced in SMC905 line 1382 to prevent cursor movement onscreen during a keep-alive action.
11099 return

SMC905:
1087 if not(nul(%__timeout_proc$)) and %__timeout>0 then _timeout=%__timeout,_timeout_proc$=%__timeout_proc$ ! (MOD - Prevent program timeout when not in a menu - BAB 20111024
1382 if __keep_alive then __keep_alive=0; goto NEXT_EVENT ! (MOD - BAB 20111117 - Keep alive

salbritton

Bradley,

Thanks very much! We'll try this also. I appreciate the response!!

Wichtige Lösungen in der Wissensdatenbank Mai 2012.pdf

skyler-williams

Recently found that current version (As of 11/2013) of Avast (firewall) will interfere with Facts7.5 client/server network connection, causing it to freeze and the window getting dropped.
This was discovered as XP PCs were upgraded to Windows 7 PCs and prepared for v7.5 to v7.7 upgrade. The 7.5 sessions in the new Win7 environment kept getting dropped.
May be related to Avast process that supposedly monitors/alerts to available software updates, but with everything on EXCEPT the firewall, the problem seemed to be resolved.

Legacy Contributor

The SMC905 code must be for 7.7. Do you have the 7.6 version? The goto Next_Event on line 1382 is not in my client's 7.6.

BradleyBrown

The code lines in SMC905 are mods. You need to add both in 7.6 and 7.7.

Legacy Contributor

My client did not have any of these three programs. So I just put down your code in new files. But your code wants to goto Next_Event, which is not in your code, and causes an error. So I was just checking to see if 7.6 had a different version.

Copyright © 2025 Infor. All rights reserved.