Re: After a couple of weeks of SP3...

Reeve:
   you have all the valid points and good suggestions that I hope we can
soon address.

I know that there are problems with the RPG program verifier previously
causing the editor to crash, and maybe the fixes we put in have not covered
all leaks.

We are trying hard, and we do appreciate your patience and help in
especially solving problem like in your robust environment!


Hak Lui
AS/400 AD, IBM Canada Ltd.
e-mail: haklui@ca.ibm.com


"Reeve Fritchman" <reeve@ltl400.com>@midrange.com on 10/24/2001 09:24:15

Please respond to code400-l@midrange.com

Sent by:  code400-l-admin@midrange.com


To:   "CODE400-L@midrange. com" <CODE400-L@midrange.com>
cc:
Subject:  After a couple of weeks of SP3...


...I don't see any improvement at all in CODE/400.  Well, I take that back:
CPO does sort by date properly, the library list problem has gone away, and
the /COPY problem has been resolved.  Otherwise, I'm plagued by VERIFY's
that run forever then crash, normal sessions that won't let be save the
member because it's locked (I know it's locked...I downloaded from the iBox
30 minutes ago), and mysterious happenings where my communications icon is
on solid for 10 minutes until CODE/400 crashes. And every now and then,
CODE/400 works flawlessly for hours, and my joy is matched only by the kid
on TV hawking Dell computers: "Dude, you're getting' a Dell!"

No, these events are not creatable on demand.  They just happen in the
course of normal operation; most of the time it takes a reboot to clean
things up.

We need a customer version of CODE/400 with industrial-strength logging.
This is a complex, high-function product running on a platform as stable as
an upside-down bowling pin.  It's extremely difficult to reproduce many of
these errors in the lab environment (although Designer seems to be an
exception), and communications errors are basically impossible to duplicate
because they're the product of so many unique processes and events.  A
developer-level log could provide an audit trail of the internals (or
should
I say, "infernals"?) and point the developer to the piece of code where
something went awry.  I view this is proactive, not reactive, support.  IBM
Toronto, your customers believe in this product and we want to help.  Let
us!  Send me a non-disclosure; I'll sign it.  Then show me the code!

Speaking from my own experience, it's a pain to add logging code.  But I'm
happy to do it because I know I'll find the damn bug!  It takes time and
effort but it's not frustrating because I know I'm circling the wagons
around the boneheaded mistakes (plural; reality-based!) I've made.  If I
set
it up right, the logging code will define the exact situation/transaction
causing a problem while I'm off doing something else.  And then I disable
the log, but I'm happy it's in there because it becomes a great testing
tool; even my customers use these options to determine why certain complex
transactions aren't working (explanation: the program works properly, but
the user forgets to check customer options, expiration dates, ZIP code
restrictions, or data entry discrepancies).  Coding a complex program
without making provisions for finding/debugging problems seems pretty
brave,
and you can almost get away with it in ILE RPG (in a system with 2,000
programs, I have logging in three).

Just my $.03 (CAD)/$.02 (USD)...

Regards,
rf

_______________________________________________
This is the CODE/400 Discussion & Support (CODE400-L) mailing list
To post a message email: CODE400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/code400-l
or email: CODE400-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/code400-l.