cgi

[Pat Helles]

I've been reading the XENIX mail messages for some time, I only wish I 
had started reading them before purchasing the software.  Anyway, I have
been having trouble with SCO's CGI product and I am hoping someone somewhere
has already encountered & resolved this "slight" problem.  The problem is:
      I CANNOT get a hardcopy printout of any graphics from within a C
      program while interfacing to the CGI package.
My system is a Proteus 386, 8-slot m/c, 4Mb, 2-user system (I'm the only
user - currently), VGA Paradise Card w/VGA monitor (NEC multisync), and
an HP Laserjet Series II printer.  My basic problem is that I can't
figure out what environment variables need to be set and to what values
before running a CGI program.  My .login file has the VDIPATH variable 
set & and the DISPLAY variable (I'm using C-shell) and I have no problem
in creating a graphics image on the screen.  When I decide to attempt 
making a hardcopy output, I add the environment variable:
	setenv PRINTER laserjet
and proceed to open the printer as a workstation.  I also printed out
the returned array from v_opnwk (or whatever the damn function is) and
have examined it at length - it returns all the expected information.
Then I repeatedly call v_pline with sets of numbers followed by a 
request to print at the end.  The results for my trouble:

	The screen fills up the the escape sequences that the 
	laserjet should be getting.  Instead of sending the 
	information to /dev/lp or whatever, the program sends
	the information to the CRT.  My first impression was,
	WTF is going on.  I have invoked the the program with
	a redirection to /dev/lp and that works just like it's
	supposed to, i.e., the correct image is produced on the
	laserjet.  

While the redirection does work, I personally don't feel as though it
is a satisfactory solution -- it makes it hard to ask the user of the
graphics program any questions.  I have also tried to close stdout 
inside the C program and use dup2( ) to send the information directly to
/dev/lp, it sounded like a good idea at the time, unfortunately, the
Operating System thought it was a stupid idea and locked-up the console,
giving rise to that wonderful message:  "File system not shutdown properly."
Shall I attempt to correct?  (No, I prefer corrupted filesystems, they're
more challenging.)  In case anyone is interested in SCO's response, or 
lack of response, they informed me that it doesn't look as though their
technical people (?) are going to be able to help and that they would be 
willing to take back the CGI product.  My feeling is either take back the
entire software package or fix the CGI package.  I have the impression 
that the CGI package was sent out with major bugs and they feel that 
correcting the problem would be greater than taking back the product.
This is only my impression of the situation.  

If anyone out there has any (and I do mean any) ideas I would more than
welcome them.  I am also willing to send anyone who wants to have it a
copy of the C program (it's very short - 2 pages).  All the program does,
is reads a data file of x&y values and then plots them.

In an unrelated situation, I have been unable to copy multiple DOS files 
from a floppy disk to the XENIX hard disk using doscp - one at a time file
work ok, but wildcards, like '*' and '?', don't work.  I have corrected
this problem by writing my own program, called 'xcopy', for lack of a better
name, which accepts '*' and '?'.  If anyone is interested in this program 
I am more than willing to share it at no cost -- if you've bought SCO XENIX
you probably need help as badly as I do.  If anyone knows how to copy 
multiple DOS files from a floppy to the XENIX hard drive, please DON'T 
tell me. 

I am also glad to see there are others who 'enjoy' the SCO Technical
Support as much as I do.  In case there is anyone who is interested 
in purchasing SCO XENIX, please consider the following:
1.  SCO XENIX probably supports more third party products than
    any other UNIX-based operating system
2.  They are (almost) always friendly when you call them
3.  They do have a decent product
HOWEVER,
1.  If you are an end-user, you will not get as technical a person
    as you might need when you phone in a problem
2.  As an end-user, you have a longer turn-around time to have your
    question answered as opposed to an authorized dealer or a registered
    developer.
3.  Be prepared to wait 3-8 days before getting your questions
    answered
4.  If the answer to your question can be found somewhere in the 
    encycopedia of manuals, SCO can answer it; however, if your
    question requires thought & and the answer is not in any of
    the manuals, don't bother calling.  EX:
	I connect thru a network to another computer that 
	expects to talk to a VT100.  The system console is 
	just an ANSI terminal.  I called SCO & said I need 
	to write a program to talk thru /dev/tty1a and get
	the system console to emulate a VT100, do you have
	any ideas on how I would start such a program?
	SCO's REPLY:  You can connect a VT100 to the XENIX 
	Operating System.
	ME:  I don't have a VT100, I want the system console to
	emulate a VT100.
	SCO:  The system console is an ANSI terminal.
	ME:  (thought only):  Get a tractor & pull your head out.
	     (speaking):  I want to emulate a VT100.
	SCO:  I'll ask one of our engineers & call you later
One week later:
	SCO:  The engineer said XENIX can't emulate a VT100, you
	would have to write a program to do the emulation.
	ME:  (in thought):  Attack of the Incredible Shrinking Brain

5.  Be prepared for silly answers, such as "I don't know", "Try this
    it might work", and my favorite of all, "Why do you want to know!"
    (Oh, I don't know, I thought it might be trivia question somewhere.)

To tell a little secret, I have actually called AT&T and have asked
them for help, and to my surprise they helped without any problems, 
and what's more, I got my question answered the first time I called.


I apologize for taking so long to finish, but this is my first time.


Thanks for listening & for future help.

Pat