Re: Systemic use of monitor blocks

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