Re: How much testing required after CVTRPGSRC?

[Dan <dan27649@xxxxxxxxx>]

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