Re: start report xxxx to pipe "more" - exits all the way!!

I think this is one of the effects of bug B36291 or B13011. The short answer is not to exit from 'more' while the report is still generating data. I attach some of the notes on B36291 from the PTS database. If the bug was fixed, you would probably get a 'cannot write to report output file' error. As the notes below make clear, this is partly a result of fixing bug B13011. I include the notes on B13011 too. No final decision has been taken on what fix to use for these two bugs. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> >From: rnatesan@bactc.com (Ramki Natesan) >Date: Fri, 12 May 1995 11:29:37 -0700 (PDT) >X-Informix-List-Id: <list.6262> > >Hello everyone, > In one of my reports I am doing the following step > > >>> start report xxxx to pipe "more" <<< > > It displays nicely on the screen, but when I press <CTRL-C> or Q to > quit (when there are more to display), it exits out of my program and > comes to prompt line. Why this happens? what should I do to stay > in the program? =========================================================================== BUG NUMBER 36291 05/13/95 Product: 4GL Date: 12/30/94 Dup. Bug ID: Type: SW Submitter: recio IF BACKEND DIES 4GE PROGRAM GETS SIGPIPE AND ABORTS, INSTEAD OF -457 OR -408, ON FURTHER SQL STMTS When backend dies (for example due to a network failure when it was used to conect to a remote DB), 4ge frontend gets SIGCLD (death of child) and ignores it. Further SQL statements sent by the frontend try to write to a broken pipe, geting SIGPIPE, which is catched and generates a call to _exit(1). The right behaviour would be: 1. To catch SIGCLD and wait() for the child, in order to remove this defunct proccess from the kernel proccesses table 2. Then, to generate a -457 or -408 for any SQL stmt, except the DATABASE one, which would expand other backend, allowing to set a new DB conection PROBLEM NUMBER 34491 ASSERTIONS FOR: BUG 36291 FAMILY 4 ENVIRONMENT UNIX 151178 FYI N/A tchu 1995-01-20 01:12:50 This bug is caused by bugfix to B13011, undoing B13011 resolves it. So basically we have two irreconcilable bug reports. B13011 against 4.00.UH1 states that 'REPORT TO PIPE "<command name>"' produces -1324 error message if <command name> exits before the report finishes writing output to pipe, e.g. user types 'q' after viewing one page of the report output filtering through 'pg' or 'more'. To get rid of the error message (a nuisance according to problem description), the signal handler for SIGPIPE was modified to exit the 4GL program silently upon receipt of SIGPIPE. And only the compiler was fixed at that time; the intepreters still produce the error message. Problem arises if the 4GL frontend is writing to pipe read by the backend during execution of the SQL statements, if the backend dies for some reason, the frontend simply aborts without reporting errors; there's no way to trap such errors or continue execution like connecting to other servers under such condition. Seems like silently terminating the program is barely defensible - B13011 is the only case that justifies it. The old behavior (4.00.UH1) seems to be more nearly correct. Introducing separate SIGPIPE handlers for report execution statements (PRINT, SKIP, NEED) and the rest of the program might resolve the problem. The fact that REPORTS can call non-report functions which do SQL stuff calls for such distinction of handlers. This needs carefully looking into. 151372 FYI N/A rgilbert 1995-01-23 23:31:15 From: jyhchen@godzilla (Jyh-Chen Fang) Subject: Re: FYI Assertion: 36291 [4GL SW 4 UNIX] To: tchu@pts (Tony Chu) This is my two cents, we could choose one of the following approach: 1) Fix both bugs by introducing different SIGPIPE handlers for report execution statements. As Tony said, this need carefully look into since report statement can call SQL statements. This need more time and resource. 2) Fix both bugs by undoing the B13011 -- keep the SIGPIPE handler. This should fix the B36291. And find the another approach to fix the B13011. Since the behavior of B13011 occurs only when 'report to pipe "pg"' is used, we might be able to find a way to suppress the -1324 error message by checking the command or when the output device is stdout. This is an ad hoc approach, it might take less time to fix it, if it is possible. 3) Fix the B36291 by undoing the B13011. Modify the -1324 error message so that the users know this is correct behavior when they type 'q' on a 'report to pipe "pg"' statement. The best approach is to fix both bugs by using approach #1 or #2. However, if this is not possible because of the limited resources or any other reasons, we should consider approach #3. Although the behavior of silently exiting on B13011 is justifiable, the behavior of aborting the front-end without giving any error message to the user on B36291 is not likely to be accepted by customer. Therefore, I don't think we should choose approach #4. Well, customer doesn't like -1324 error message on B13011 either. =========================================================================== BUG NUMBER 13011 05/13/95 Product: 4GL Date: 05/22/92 Dup. Bug ID: Type: SW Submitter: bradn REPORT TO PG GIVES MESSAGE: FORMS STMT ERR -1324 WHEN USER QUITS In the 4.00 UH1 and later releases of I4gl, when an I4GL program sends output to 'report to pipe "pg"' a message of the form: FORMS statement error number -1324. A report output file cannot be written to. This message is a nuisance; it is preferable to return I4GL to its pre-4.00.UH1 behavior of terminating silently when a user quits from pg. PROBLEM NUMBER 12733 Problem 14628 is Dup of this bug. per bugdba.