Re: How much testing required after CVTRPGSRC?

[Jack Tucky <jacktucky@xxxxxxxxx>]

I've used cvtrpgsrc and never had a problem.  Doesn't  It just move columns around?  

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