Re: How much testing required after CVTRPGSRC?

100% of the time? Nope, nothing in IT life is guaranteed...

Lets call it 99.999% ;)

I really liked Buck's list on the RDi list of "comfort levels" or riskiness
requiring a complete retest. From least to most (with some additions &
re-ordering by me):

- Recompiling on a newer version of the OS (ie program was last compiled
at v4r1)
- CVTRPGSRC (source code formatting)
- Hardware upgrade (save+restore same OS/user libs)
- PTFs (they are intended to change something!)
- TRs (SQL behavior has changed)
- OS releases (all sort of stuff changes all at the same time)
- OS Release that requires a retranslate ( CISC-->RISC or v5 --> 6.1+)

You're asking for trouble trying to convince your colleagues that CVTRPGSRC
is risk free. Instead, convince them that the risk is less that some other
activities that they routinely perform without a complete retest.
Additionally, point out the benefits out-way the risk.
- RDi compatibility
- Better debugging ability
- Better foundation for rewrite

That last point is a big one in my mind. When the time comes to re-write a
program, I'd much rather have a CVTRPGSRC RPGIV program running in
production for some time rather than an RPG III one. Assuming that the
first step of your re-write is currently CVTRPGSRC.

As pointed out on the other list, CVTRPGSRC is a mechanical source
reformat. Then the source is compiled with a different compiler. IMHO,
There's little if any additional risk compared to changing one line of an
RPG III program last compiled at v4r1.

Just make sure nobody has changed the CRTBNDRPG defaults of TRUNCNBR(*YES)
DFTACTGRP(*YES) to TRUNCNBR(*NO) and/or DFTACTGRP(*NO).

Lastly, to reiterate...in 10+ years of routinely CVTRPGSRC for any change.
I've only been bit once. Memory corruption due to a parameter mismatch
that DID NOT manifest on the RPGIII version of the program but did on the
CVTRPGSRC version. Any of the above list of changes could have
theoretically caused the issue to start manifesting. But CVTRPGSRC is the
one that did.

Charles


On Mon, Nov 2, 2015 at 11:07 PM, Dan <dan27649@xxxxxxxxx> wrote:

(The following originally appeared as a response in a thread on the WDSC
(RDi) list. Someone advised off-list that I should post it here as well.)

I was searching the archives on CVTRPGSRC to see what impact / issues one
could expect to see by converting RPG-III to RPG-IV.

We're using an old ERP package written in RPG-III. I have always been of
the mindset to convert any RPG-III source to RPG-IV before I modify it.
Especially now with RDi, where the outline view doesn't work with RPG-III
and hoop-jumping necessary to debug OPM programs. Unfortunately, I'm new
here and I'm getting pushback when I need to modify an RPG-III program.
The "standard" here is to convert only when it's a major rewrite or
something that needs to be done can't be done in RPG-III. The argument is
that any such application must be completely retested, so, while the effort
to convert is minimal, the big cost is in the effort to QA the app.

It's been at least 15 years since I did any significant conversions to
RPG-IV, but I never recall anything that "broke" as a result of simply
converting an app. NOTE that this means no attempts to convert stuff like:
MMDDYY MULT 10000.01 YYMMDD
to
Eval YYMMDD = MMDDYY * 10000.01
as an example. >>> For the purpose of this discussion, I am strictly
talking about taking an RPG-III source, running CVTRPGSRC on it, checking
the conversion report, and compiling the RPG-IV program. The result should
be a functionally-identical program, 100% of the time. <<< True? False?

When I was searching a few weeks ago to refute the idea that a converted
program needed to be *completely* retested, I found a few threads on the
RPG list from 2006 where some were asking about any “gotchas” with using
CVTRPGSRC. Comments from people whose judgment I trust on this list were
unanimous in that a converted app *must* be completely retested. If this
is still the case, I will have tremendous difficulty selling the idea of
converting every RPG-III program to RPG-IV anytime we do any kind of
modification, because the QA resources are extremely tight in this shop.
It seems to me that, with ~20 years of experience with CVTRPGSRC, surely
IBM would have worked out any kinks in the conversion and/or the report
identifying potential issues.

So, my question to the group is this: Has anyone *ever* found any
functional differences or issues after doing a straight CVTRPGSRC and
getting a clean report from the conversion report?

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