Re: 4gl report problem

Southerne wrote: > It's some time that I've this problem : there is a big application that > launches a 4gl report piped to printer of just 1 or 2 pages (with no large > data but with just the ascii-code needed to fill a form) that interrupts > it's output randomly without an error message nor a final FF code. Since the > report runs repeatedly the successive form output starts at the point the > preceding output cut off. This happen only if the application produces a > large spool and I must bypass the problem printing a single form at time. > > As I wrote, the process don't signals any error, so I think that the problem > lies on the pipe process called by the fglgo probably due to a lack of > system memory (or resources) but I don't know how to trap the error and to > reconfigure the system. ...and, yes, I already tested the application on a > different printer. > > This is my box: > > HPUX server B. 10.20 B (HP 9000/871 D370) > 512MB Ram 890MB Swap > Informix DS 7.31.UD1 > Informix 4GL 7.30 UC2 pcode V.730 I really don't have much idea about what's wrong, and since no-one else has chipped in, it's likely they don't either. Several issues spring to mind. First, what is the printing system doing allowing any one print job to interfere with any other? If you are using a normal, civilized Unix print spooler, what you submit as a print job should be kept entirely separate from what any other print job submits. That suggests that there's something odd about your print spooler setup. Your I4GL program (a big one) runs a second I4GL program (a report program). The second program sends the output to a printer via a pipe. Are you using START REPORT x TO PRINTER or START REPORT x TO PIPE "print command and options"? It shouldn't make much odds, but... Do you have an error log created for the report program (CALL STARTLOG("...")? If not, do so - pronto. And monitor its contents. Are you sure your program executes the FINISH REPORT statement? If it doesn't, you can run into all sorts of problems. When you tested on a different printer, you got what result? The same one? A different result? Is it using the same print spooling? IDS 7.31.UD1 is a bit old - you should aim to upgrade to at least 7.31.UD7 (for reasons unconnected with this problem). Similarly, I4GL 7.30 is a bit old too - 7.32 is current (though I don't know whether that is available for HP-UX 10.20). However, it is not obvious that this has anything to do with the problem either. You think there may be resource problems - possibly memory. So, have you tried adding swap space? Why do you think that might be a problem? Have you tried reducing the workload on the system? Lots of questions - no answers in sight. If I had to guess, I'd worry about the FINISH REPORT first. But I'm not confident about that. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

"Jonathan Leffler" <jleffler@earthlink.net> wrote: > Southerne wrote: > > ... > > As I wrote, the process don't signals any error, so I think that the problem > > lies on the pipe process called by the fglgo probably due to a lack of > > system memory (or resources) but I don't know how to trap the error and to > > reconfigure the system. ...and, yes, I already tested the application on a > > different printer. > Several issues spring to mind. First, what is the printing system > doing allowing any one print job to interfere with any other? If you > are using a normal, civilized Unix print spooler, what you submit as a > print job should be kept entirely separate from what any other print > job submits. That suggests that there's something odd about your > print spooler setup. Hi Jonathan, yes, this could be the case, as I've a large number of printer installed via a different ways (lan, serial lan via dtc, local to some hosts on the network, remotely attached a win server, etc...) but the problem manifests itself only on this single program and the spool is neither the biggest nor the more sophisticated print process that we have developed. > Your I4GL program (a big one) runs a second I4GL program (a report > program). The second program sends the output to a printer via a > pipe. Are you using START REPORT x TO PRINTER or START REPORT x TO > PIPE "print command and options"? It shouldn't make much odds, but... > Do you have an error log created for the report program (CALL > STARTLOG("...")? If not, do so - pronto. And monitor its contents. Sorry, I didn't mentioned before that the application is a 4gl opcode runned by the fglgo which spawns the pipe process with the START REPORT TO PIPE "lp -s -d formname -n 1". I manually set up a raw logging: before the START REPORT statement I run "echo 'START 'id' >> /tmp/mylog" and after the FINISH REPORT - run "echo END 'id' >> /tmp/mylog" . The log showns that the function that drives the report was never interrupted. > Are you sure your program executes the FINISH REPORT statement? If it > doesn't, you can run into all sorts of problems. Yes, the 4gl execute the finish report statement and ended without errors. > When you tested on a different printer, you got what result? The same > one? A different result? Is it using the same print spooling? yes, the same system, the same printer driver, etc... > IDS 7.31.UD1 is a bit old - you should aim to upgrade to at least > 7.31.UD7 (for reasons unconnected with this problem). Similarly, I4GL > 7.30 is a bit old too - 7.32 is current (though I don't know whether > that is available for HP-UX 10.20). However, it is not obvious that > this has anything to do with the problem either. I'll try to get some information on this issues. However, we are planning to upgrade the system to HPUX 11; maybe I'll get the chance to upgrade the Informix package also. > You think there may be resource problems - possibly memory. So, have > you tried adding swap space? Why do you think that might be a > problem? Have you tried reducing the workload on the system? Yes, sometimes, when I execute the debugger on this application the fgldb stops with a Memory Fault error, so I think that I run in some sort of "out of resource": btw, the application is very large and has a big global array declared into. Supposing that the failure source is an "out of memory" in the growth of the spool filled by the repeatedly piped process, I introduced a sleep time (5 sec.) and by now there is some day that the problem don't rises. This is the case, I should try to reconfigure the application to eat less ram: sadly, this is a typical example of the growth without control of a simple program implemented with a large number of functions in the years... Thank you, S.