× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.