|
István 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. > >I did not, for two or more reasons and hope, you can lead me to any source >or information if my reasons are very very wrong: > >(a) In a specific project, my collegue and I have only 20 Fingers for >maintaining a 700 PGM (OPM) Package, a CVT could only be done in a >Test-Environment (I would not dare to have PRODUCTION programs in a >"foreign language" and be dead after the first urgent customer >requirement); so I decided first to learn the RPG IV Rules and Writings by >doing some Sample Programs (=without business need) and to read/understand >the new Red Book, which was recommended by a lot of friends and this >mailing list too. My experience with RPG-IV is 2 months old with one >handfull converted OPMs (so-la-la) which do work, but are surely not "new". > >(b) I would not change to a new language just for it is new (would I, would >it not be JAVA? - No, not seriously, I tried). I would like to change with >usage of the major benefits of this language. The argument, IBM does invest >money and manpower in RPG-IV and not so much in the OPM RPG, is understood >and a good reason to change, but not to jump! I would better invest first >some brain time, how to arrange or rearrange the programs, decide, what >will become a Stored Procedure or becomes Part of a Serviceprogram (or >remains an internal Subroutine or simply an oldfashioned called OPM, if >this is not a sin or stupid). Therefore, after the simple Code-Conversion >with the IBM Command and maybe additional enhancement tools (I look for B. >V. Stone's) there are some severe changes to be done. 20 Fingers, I mentioned. > >In this part, the redesign of (good working) OPM-Programs, I have some >fears, may be I think to much of earlier IBM Machines (back to /360, why >not?). > >What fears? I give you one as an example: in RPG-III, it is common to use >F4 to call a list (a subfile program) behind a code to make selections or >give further information. We have in this package about - let's say - 100 >of such little (1.500 lines) programs. Do I make them all become one big >serviceprogram, which contains 100 modules which make in sum 150.000 lines >(just a lot of zeros, someone may say??); each of them has a DSPF of -let's >say- 1000 lines (another zeros, after a 1). Makes this sense? How does the >Main Storage act, loading the equivalent machine code of 250.000 lines, >when one finger presses the F4 Key? Is this not "baking a big pie", >resulting in bad performance, unnecesserily buying a bigger machine? Just >feeding Dollars into IBM? - Was the OPM construct not better from this >view: one fingertip on F4 loaded only the equivalent of 2500 lines? - Where >am I wrong? >I remember IBMs Chuck Stupca (great engineer! great COMMON Speaker!) once >teaching us not to worry about the machines power, it will page the chunks >in or out, faster than lightning, you will not feel any difference. On the >other hand, if I look around me, all machines (including this >.<no-no-word>.. PC I write this now) have grown in the last years like >mad, mostly caused by programs which have also grown like mad? > >..... yes, Sir, I continue to read the new Redbook. No question about this. > >Thank you for your attention >István (from Austria) Hi István! I'll be vacationing in your part of the world in a few months. Actually, just driving back and forth between Germany and Slovenia, but we'll be enjoying the scenery in Austria along the way! Regarding your concerns about migrating to ILE, the process is really not very difficult. First step, gradually convert programs from OPM to ILE using DFTACTGRP(*YES) (the default on the CRTBNDRPG command). Many shops are in the middle of this process - whenever any maintenance change needs to be done on a program, that's a good time to make the switch. You can easily run with a mixed environment with both OPM and ILE programs running in the default activation group to start taking advantage of some RPG IV features. This first step is quite painless and many shops run this way already. When all your programs have been converted to RPG IV, the next step is to use a named activation group for all your programs. This way, you can start using more advanced RPG IV features such as procedures, but otherwise, there's really not much else to this step. Finally, once you're comfortable with the ILE concepts, you can then play with restructuring code into procedures, service programs, and multiple activation groups. My point is that you don't need to dive in head-first. If you want, you can gradually change over to ILE-style program by program. Sometimes I think the redbooks and manuals make the process sound more difficult than it really is! Regarding service programs, you don't have to put everything into one service program. You can divide your 100 modules into any number of service programs if you want. And as Chuck said, don't worry too much about how the machine handles paging and memory. There are few other machines (if any) that handle memory using the advanced "single-level store" model! Cheers! Hans Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.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.