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