steven@lakesys.UUCP (Steven Goodman) (06/30/88)
Still looking for those whom may have developed some applications for SCO's "CGI" system. From the few I have seem some very nice work has been done. -- Steven M. Goodman Lake Systems - Milwaukee, Wisconsin {ihnp4,uwvax}!uwmcsd1!lakesys!steven {rutgers,uunet}!marque!/
morgana@wayback.unm.edu (Pat Helles) (04/13/89)
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