× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Jerry,

So there are a number of ways that the tool could have handled it, user configurable, of course.

- Warning on the conversion.
- A MONITOR block.
- An OpCode extender.
- An H spec entry.
- Do it the way IBM does, just for that line or block of lines: /End-Free, /Free.
- Add in an appropriate BIF (e.g. %DEC, %INT) to control the internal representation.

Several of these need to be added with caution, but can usually be accomplished by inspecting the declared lengths and attributes for each variable in the equation. Not all options will be applicable for all situations, but the version I had of the tool did not give me any intelligent choices.

-mark


At 2/8/10 02:41 PM, you wrote:
The "result field is too small" error is one that I seriously doubt that a tool could catch, though it might be able to give a warning.

I have an RPG IV program that ran flawlessly for years. Then management decided that, instead of doing what amounted to a bin inventory for certain items, we would count discrete items. I understood why they wanted to do this, but it went right over my head until the report was run at the end of the next month - and crashed and burned (in-line printer fields). The on-hand inventory quantity fields were not increased so maybe that's why no alarm bells went off. The program was, by the way, originally an RPG II program until I converted it and changed the ADD's to EVAL's and made it /free format as well. As I said, even though most of the changes were done by me (with just a little help from CVTRPGSRC), the best that I think a tool could do would be to say, "Hey, you might want to check those EVAL's" (ADD's even in RPG IV will still overflow "properly").

I have another program that has been ILE RPG from the beginning. It blew off with the "result field too small" error (even though the logical was flawless, I might add) because someone miss keyed a price (missed the '.' and hit the '0' instead). After that, I added MONITOR's around just about every EVAL, logged the exceptions, notified the user, and printed a report of the errors immediately (you might have guessed that it's a critical program). It keeps getting reinforced into my thick skull that a good defense (in this case, MONITORing) will beat a good offense (brilliant (?) design/coding).

Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of M. Lazarus
Sent: Monday, February 08, 2010 1:03 PM
To: RPG programming on the IBM i / System i
Subject: Re: OPEN in RPGIII

Charles,

"Safe" is relative. On one project I used
their tool. The result was much prettier than
IBM's (which is safe, but can get messy), but it
did not handle cases where there was numeric
overflow in the calcs. RPG/400 techniques often
relied on overflow being ignored. In that case,
that behavior was acceptable to the client, but
the hard halt was not, even though the high order
digit might have gotten truncated.

It's possible that their newer version of the
software handles this more cleanly, but the
version I was using wreaked a bit of havoc.

-mark


At 2/4/10 03:29 PM, you wrote:
>I have to second the recommendation of Linoma's tool.
>
>It's not that expensive, it's just as safe as IBM's CVTRPGSRC but it
>does a heck of a lot more. You won't have what I would call an ILE
>RPG program, but you will have a full fledged RPG IV program.
>
>Charles
>
>
>On Thu, Feb 4, 2010 at 2:22 PM, Vern Hamberg <vhamberg@xxxxxxxxxxx> wrote:
> > Agreed - CVTRPGSRC is a pretty "stupid" line by line converter - the
> > work comes when you try to move all your data definitions out of
> > C-specs. No need for that to get the %open() functionality.
> >
> > And that's why they should get Linoma's tool to take care of more
> > advanced conversion.
> >
> > There is also a free tool called JCR4MAX by Craig Rutledge that does
> > more with the result of CVTRPGSRC - and you get the source, so you can
> > tailor it to your liking. I forget the URL - just Google on JCR4MAX. He
> > has other tools, too - very nice.
> >
> > Vern
> >
> > Charles Wilt wrote:
> >> David,
> >>
> >> I've never had CVTRPGSRC leave me with hours of work. Honestly, I
> >> can't remember it ever leaving me with _ANY_ work to do.
> >>
> >> Charles


As an Amazon Associate we earn from qualifying purchases.

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-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.