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



Istvan Rudas wrote:

>>>>Kent wrote:
>>>>We have a program running for a couple of hours (7). 
>>>>When looking into the
>>>> ... ... 
>>Well, OK, I'll try to answer it anyways.  (I'll assume that
>>this is one of only a few programs you haven't yet converted
>>to RPG IV, right? :-)
>
>This (last above) sentence in your very interesting answer to Kents
>question gives me the idea, that you may suggest for OPM-
>Programmers to convert them quickly and without major 
>changes - as the IBM CVT Command does it.
>
>(a) In a specific project, my collegue and I have only 20 Fingers for
>maintaining a 700 PGM (OPM) Package...

-snip-

Guten tag!   Wie gehts?  (Hi!  How's it going?)
Converting from RPG III to RPG IV is not the same as converting from RPG III
to Cobol, or C or Java.  RPG IV is not another language, merely a newer
version of good old RPG III.  The only difference you will find after
running CVTRPGSRC are the new D specifications.  These take he place of the
E specifications and the Data Structure specifications.  Every other line of
code is exactly the same as in RPG III.

I have found that maintaining existing, working applications is very much
easier after conversion to RPG IV for the following reasons:
1) Fewer restrictions on variable sizes - 32k character fields, etc.
2) Longer, meaningful field names in mixed case.  Which is easier to
understand: NAME or CustomerName, VendorName?

I convert each program only when I need to make changes.  In the beginning,
do not worry at all about service programs or subprocedures.  Use the same
logic you always used to decide what should go into a subroutine and what
should go into a separate program.

When you are comfortable with the D specifications (in a day or so) <grin>
think about using a subprocedure in place of a new subroutine.  Don't tear
up existing, working code - just make the new code so it can take advantage
of RPG IV's strengths.  Compile the programs containing subprocedures in the
QILE activation group so you don't have to worry about what to name your
activation groups.  Once you use subprocedures and their local variables you
will be so happy to have this support and you will wonder why it took so
long to start using RPG IV.

Even if you never use a BIF like %size, or never use an EVAL, I would very
strongly urge you to convert to RPG IV just for the subprocedure support.
If you use /COPY now to bring in subroutines you can use the exact same
philosophy with subprocedures.  
I hope this helped!

Tschuess!
Buck Calabro
Aptis; Albany, NY

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.