To avoid annoying users (or at least minimize the annoyance) I normally recommend clients use the PSSR error handling approach we recommended in the RPG Error Handling Redpaper. For green screen that includes grabbing the screen content and showing them a nice "We're sorry - can you tell us a bit about what you were doing when things went all to hell" message. That way you get the dump you need, record the error (no more users in a rush to go home forgetting to tell you it happened) etc. etc. Doesn't help as much with batch though of course.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Feb 28, 2019, at 11:50 AM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:

I tend to agree, Jon. One case in particular is exactly that - a change counter has three digits and traditionally rolls back to zero. I fix those when I see them (hurray %min!). The only trepidation I have is that users find it very annoying when hard halts occur, and often the explosions occur on edge data conditions (e.g., they accidentally enter 99.5% scrap instead of 9.95%, and suddenly their requirements start overflowing).

Since this program is in the bowels of both batch and interactive processing, it takes on added significance, because a hard halt in batch processing holds up production. (In this case, BTW, "batch" means "interactive processing offloaded to batch subsystems to get around the CFINT restrictions of a prior era".)

I'm going to present the various options to TPTB and let them decide how they'd like to handle it.


On 2/28/2019 10:34 AM, Jon Paris wrote:
Personally I'd opt for #1 Joe.

Maybe your legacy code is different to what I have experienced - but in most cases I have found that the overflow situations tend to be limited to a small range of uses. e.g. The old date conversion abomination or a (say) a 3 digit counter that is supposed to roll over to zero when it hits 1,000. Given this, I have found that a manual inspection (or chat with the programmer most familiar with the program) can often identify the potential offenders. Option 1 just catches any I miss.

In order to make option 2 work you need to identify the potential problem lines and then decide what to do if they throw an exception. If you can work out a reasonable response then often you can program round the problem.

In other words if I can't do anything sensible to pre-empt and handle the error then I let it happen and fix it.

Part of the assumption behind this is that there's no commitment control or anything going on in old programs that need to be converted. If there were then bigger Monitor blocks might make more sense.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Feb 28, 2019, at 11:11 AM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:

I scanned the Intertubes (and this list, of course) and I didn't find anything that exactly matched my question, so I thought I'd bring it to the group.

When I write new programs, I can pretty easily program for overflow and I in fact do it. %MAX and %MIN will help even more for just that sort of thing. But when I'm converting legacy RPG/400 programs it's not quite as simple. A program can have hundreds of individual math operations, and if I were to put a monitor around each one, I'd end up with a huge and less readable program.

Yes, over time I can isolate and combine mathematics into expressions, but that's more of an analysis task than a mechanical conversion, and often I can justify the latter but not the former in terms of time spent.

So I'm wondering, what is everyone else doing when converting RPG/400? It kind of boiled down to this for me:

1. Just convert and let it hard-halt on overflow
2. Put a monitor block around every overflow-capable operation
3. Put monitors around large blocks of code

Number 1 is easy and errors will definitely get attention. Number 2 allows me to put special overflow values into individual fields but the syntactic overhead is pretty large (every computation becomes five lines, more if you log errors). Number 3 is something that seems reasonable as long as I can gracefully terminate the transaction and put it in a state to be recovered.

I just don't have a good feel for the best solution, but I'm in the process of converting a program that gets called by dozens of other programs in every job stream, so it's probably a good time to do it correctly.

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com


--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com


This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].