SCO CGI under SCO Unix SysV 3.2

Yermo M. Lamers yml at grebyn.com
Tue Oct 16 00:57:17 AEST 1990


I have an application which has been running for over a year under Xenix
386 2.3 using CGI. I have to port this application over to SCO Unix 3.2.

CGI under Unix 3.2 (OPENDESKTOP) is exhibiting some flakey behavior :

1. I let my Xenix 386 binaries run over night using the ega driver.
   This application continuously updates the screen. By the next morning, the 
   application had died, the console was blank and required an /etc/clean_screen
   in order to 'get it back' to where it could be used. The identical
   binaries (which had been compiled using the Xenix 386 dev system and
   libraries) run without incident under Xenix 386.

2. I then tried to compile the code using the SCO Unix development
   system with the -x2.3 option. I noticed that openworkstation
   correctly initializes the screen before I open a pipe to another
   process. However, openworkstation never returns if I call it
   after the interprocess pipe has been established. (my application
   first establishes a pipe to a network process and then sets up
   the screen. The same code has been running under Xenix 386).
   Openworkstation just blanks out the screen (requiring an
   /etc/clean_screen to 'get it back') and causes the disk to
   thrash endlessly. Growing problem?

3. So I commented out my pipe code and managed to get my screen
   updating. I let the newly compiled binaries run for about an
   hour and I noticed that several lines of text had on one pass
   been displayed at the wrong coordinates (I've seen this same
   problem under CGI 1.0 under Xenix 286.) Some of the text had
   been rotated 90deg. Same code runs fine for days under Xenix
   386.


Does anyone have any insight into the causes of these problems? Are 
there any workarounds that anyone knows of? Any patches for CGI
available? Has anyone else at least seen some of these problems?

Replies to yml at grebyn.com will be GREATLY appreciated,

Yermo Lamers
yml at grebyn.com



More information about the Comp.unix.sysv386 mailing list