RE: OPEN in RPGIII

[Jerry Adams <Jerry@xxxxxxxxxxxxxxx>]

Mel,

All true.  Awhile back I was part of a team that worked on a tool to do something as "simple" as fix dates for Y2K.  Even after interrogating programs and databases, we could only say something like "Well, I'm 99% sure that X is a date."  The tool's users still had to confirm/deny (we did make it pretty easy, but I won't go into that).

I know that I wouldn't want a tool that changes, say, ADD to an EVAL to automagically put an opcode extender or MONITOR into the code without letting me confirm/deny the change (but maybe that's what you meant by "user configurable").  A warning perhaps.

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 2:16 PM
To: RPG programming on the IBM i / System i
Subject: RE: OPEN in RPGIII

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