Re: Fwd: Identifying numeric string in a 4gl program

To avoid writes to the error log file when the conversion of a string to a numeric fails, you have to pepper your code with a new startlog() call in those sections where you don't wish to see the error reported; the same sections you put your "whenever any error continue" statements. main define x integer define y char(10) CALL STARTLOG("error_log.out") let y = "4.3e2" CALL STARTLOG("/dev/null") whenever any error continue let x=y whenever any error stop CALL STARTLOG("error_log.out") display y, " ", x, " ", sqlca.sqlcode, " ", status let y = "hello" CALL STARTLOG("/dev/null") whenever any error continue let x=y whenever any error stop CALL STARTLOG("error_log.out") display y, " ", x, " ", sqlca.sqlcode, " ", status let y = "4.3i2" CALL STARTLOG("/dev/null") whenever any error continue let x=y whenever any error stop CALL STARTLOG("error_log.out") display y, " ", x, " ", sqlca.sqlcode, " ", status end main Andrew Hamm wrote: > > Colin McGrath wrote in message <91trsu$d9k$1@news.xmission.com>... > > > >Because "." and "e" and such can be part of legit numeric strings, I use > >the "whenver any error continue" statement, and check the status after > >putting the character string into a numeric field. > > > > Small warning though: I did that a few years ago (V 4.1? 4GL) and it left an > endless stream of messages in the errorlog file - ie the error file you > associate with the running program using the startlog() function. > > Hopefully this has been fixed in later versions of 4GL, but I suggest you > check for it in your version. Feedback on this would be appreciated. -- Colin Any opinions I state are my own and not necessarily those of my employer

Colin McGrath wrote in message <92026u$5g0$1@news.xmission.com>... > >To avoid writes to the error log file when the conversion of a string >to a numeric fails, you have to pepper your code with a new startlog() >call in those sections where you don't wish to see the error reported; >the same sections you put your "whenever any error continue" statements. > Have you too found that this causes very noticable code slowdowns as the error log file is closed, opened, closed, opened at each place in the code? Especially in a tight loop of a data loading process for example. Unfortunately, the sober need for error reporting on all the other lines of code make me extremely reluctant to wrap the entire loop with a /dev/nul log file. When I tried that trick it caused users to be very uncomfortable, and had to abandon the approach. I'm surprised it's not "fixed" yet, for example by silencing the errlog report when a suitable WHENEVER condition is applied. Is it true? Nothing can silence the log except for pointing to a nul log file? How sad is that?