Re: How much testing required after CVTRPGSRC?

On Nov 3, 2015, at 12:45 PM, Dan <dan27649@xxxxxxxxx> wrote:

Thanks Charles. Points well taken.

I would never attempt to convince anyone that CVTRPGSRC / different
compiler is 100% risk free, since I don't believe it myself.

But, in the grand scheme of things, life is full of risks, and there is
always a cost/benefit ratio for mitigating them. And, it's not like we're
compiling our changes directly into production. The conversion happens
because we are making some functional change to the program, so we *are*
doing QA on (at least) the changes made.

- Dan

On Tue, Nov 3, 2015 at 9:47 AM, Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

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

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