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



Gerald Magnuson wrote:

>We are a small shop (3 programmers, 1 manager).
>We need to convince management on cost benefits of
>migrating to ILE.  (time justification is what they
>want the most)

I don't recall exactly, but here's what I *think* I did and how long it took
me:
1) Convert a familiar RPG/400 program to RPG IV:
CVTRPGSRC (comes with the compiler) logfile(*NONE)
WRKMBRPDM, edit and compile ACTGRP('QILE') 
Time: 10 minutes.

2) Add code using new syntax:
WRKMBRPDM, edit.  Use D specs to define a new standalone field with a REAL
variable name like CustARAmt, add a few lines of code to use the new op
code; eval CustArAmt = CustArAmt + CUR + OVR30 + OVR60 + OVR90.  Compile
ACTGRP('QILE')
Time: 15 minutes.  You can use the converted D specs as a template.

3) Add a subprocedure:
Scan the Midrange Archives for examples of subprocedures.  Look at the
Redbook "Who Knew You Could Do That..." for examples.  Edit code, compile,
test.
Time: 1 hour.

Time expended: call it 4 hours in case I missed some stuff.  There's no ILE
here; just RPG IV.  Now for the time gained.  Every time I'm back in that
converted program, I can add subprocedures that are very high in
reliability; e.g. I won't be back in there because I reused an indicator or
goofed up a field name.  That's because subprocedures use local storage, and
I can be certain that they don't affect other parts of the program.  That
confidence is what makes continued maintenance possible.

>We only want to take immediate advantage of a few ILE features
>right away. Long field names, max files (no, we cannot re-write
>those huge apps), change some programs to service programs that
>are called all over the place.

Long names: easy.  Fewer limits: easy.  Service programs: takes more time to
think about.  I advise you to create at least a dozen subprocedures before
you start thinking about service programs.  Your goal is to create a
subprocedure where all the results are passed out as parameters, and all the
input comes from parameters.  No global usage!

>1) the concise answer the following question.
>       "What parts of RPG3 will NOT work in ILE RPG?"

I haven't run across any practical limits.  FREE maybe.

>2) programming standards, style standards for our shop

Use your existing standards.  News/400 had a page on RPG IV style.  The only
thing that'll be really new are service programs.

>3) a tool to perform the conversion

CVTRPGSRC comes with the box.  If you use a 3rd party tool beware that it
may create some EVAL's where you have ADD/SUB/MULT/DIV.  This is an issue
only because the fixed form opcodes will truncate numeric overflow, but EVAL
will post a run time error.

>4) a complete timeline-milestone chart of the conversion project.

I advise you to take a small part of your application (5-10 programs) and
pass through it one program at a time.  Take a day or so to see what
subroutines you can convert to subprocedures (if any)  If a subroutine is
too tightly integrated with the mainline, don't waste your time trying to
reverse engineer the whole subroutine.  Pick it apart a few lines at a time,
thinking "what function do these lines of code perform?"  Don't hesitate to
make a lot of subprocedures.  Get used to them.  Experience with your code
will guide you.

>5) a benefits list.

Benefits in what regard?  For the programmer (maintenance?  development?),
for management, for run time performance? (it's better than OPM!)  Read the
preface to the RPG programmers guide or the Redbook.  What works best for
me: Local storage in subprocedures and being able to create my own callable
functions.  I can almost extend the RPG language any way I want.  (Rochester
needs to add operational descriptor support and I'll be all set... <grin>)

Here are links to threads on this a while ago:
http://archive.midrange.com/rpg400-l/200004/msg00145.html
http://archive.midrange.com/rpg400-l/199909/msg00442.html
http://archive.midrange.com/rpg400-l/200010/msg00525.html

Hope this helped,

Buck Calabro
Aptis; Albany, NY
"Nothing is so firmly believed as
 that which we least know" -- Michel Montaigne
Visit the Midrange archives at http://www.midrange.com
+---
| 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-Ups:

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.