Moving to RPG IV

[MCWebsite.Staff]

** This thread discusses the article: Moving to RPG IV **
** This thread discusses the Content article: Moving to RPG IV **
0

[Guest.Visitor]

Moving to RPG IV

** This thread discusses the article: Moving to RPG IV **
Is the www.mcpressonline.com site written in RPG? Provide a list of sites written without java, but with RPG. Thanks

[Guest.Visitor]

Moving to RPG IV

** This thread discusses the article: Moving to RPG IV **
I don't see the benefit of a subprocedure over a subroutine. Could you explain? Although I have written some programs using RPGIV, I am currently changing a program that uses the RPG cycle. At first I scaned the source looking for a READ statement and did not find one. I began to wonder how was data getting into the program, until it finally dawned on me to check the F spec.

[buck.calabro@commsoft.net]

Moving to RPG IV

** This thread discusses the article: Moving to RPG IV **
> I don't see the benefit of a subprocedure > over a subroutine. Could you explain? 1) Local variables. The ability to completely encapsulate the guts of a routine within a subprocedure means that you can't have accidental side-effects due to accidental name duplication. With a subroutine, all variables are global, meaning that it is easy to accidentally overwrite a variable needed by another routine. 2) Clear interface. The ability to specifically declare the parameter list to a subprocedure means that it is very clear what variables are used by that subprocedure. With a subroutine, it's hard to tell what variables are 'work fields' needed only by that subroutine or are intended to be updated and sent back outside the subroutine. 3) Coupling. In general, a subprocedure has loose coupling to the code which calls it. That means the mainline doesn't need to know anything about how a subprocedure works: no variable names, sizes, types, etc. All the caller needs to know is the PI. In a subroutine, the coupling is very close: the caller needs to know the exact name/type/size of variables the subroutine will work on, and return. That means you can change how a subprocedure works without affecting the caller, but you are unlikely to change a subroutine without changing the caller. Hope that helps get the discussion rolling... --buck

[jvalance@sprynet.com]

Moving to RPG IV

** This thread discusses the article: Moving to RPG IV **
I am doing 2 user group presentations on this very subject this week. If you are interested, I can send you the handouts which clearly describe the benefits of procedures. Email me at jvalance@sprynet.com. I agree with Bob that people need to learn this stuff. But, unfortunately, I think the majority won't unless they have to. Until more vendors start re-architecting their packages using procedures and service programs, the people whose jobs are to maintain those system will have little incentive (and few examples to learn from) to master these skills.

[Guest.Visitor]

Moving to RPG IV

** This thread discusses the article: Moving to RPG IV **
Can you defined the file (PF, WSTN, PRTF) and process in the subprocedure locally? Thanks Tiki

[buck.calabro@commsoft.net]

Moving to RPG IV

** This thread discusses the article: Moving to RPG IV **
> Can you defined the file (PF, WSTN, PRTF) > and process in the subprocedure locally? No. Files are global in scope. That doesn't mean that you can't have a subprocedure which clearly does one thing at a time, but it makes it harder because we are always tempted to minimise I/O, so when we do that CHAIN to MASTER to get the City, we also do the credit check, validate the phone number and age the A/R because 'we are already at that record.' In a lot of ways, it's really a database design problem finally coming home to roost. --buck

[jean.driscoll@hrc-cc.com]

Moving to RPG IV

** This thread discusses the article: Moving to RPG IV **
Many shops use 3rd Party Applications from Vendors who are not yet using RPGIV. In fact, PeopleSoft (JDEdwards) World application is just now starting to use RPGIV in their newest released cum. It's very difficult to change your source to RPGIV if the 3rd party vendor is not going to support it. I agree with Bob in that this is the wave of the present, but until the vendors writing AS/400 applications get on the band wagon, not too many shops will take the time to learn it.

[robberendt]

Moving to RPG IV

** This thread discusses the article: Moving to RPG IV **
While they still 'get the job done' how can you make a horse drink when they change the following code

---

Code

[robberendt]

Moving to RPG IV

** This thread discusses the article: Moving to RPG IV **
SSA's AS/SET CASE tool is supposed to generate RPGIV code now. However they still generate RPGIII code and run a CVTRPGSRC on it. They even still rename all input fields back down to 6 character names.

[Guest.Visitor]

Moving to RPG IV

** This thread discusses the article: Moving to RPG IV **
Jean Driscoll wrote: > Many shops use 3rd Party Applications from Vendors who are not yet > using RPGIV. In fact, PeopleSoft (JDEdwards) World application is > just now starting to use RPGIV in their newest released cum. It's > very difficult to change your source to RPGIV if the 3rd party vendor > is not going to support it. I agree with Bob in that this is the wave > of the present, but until the vendors writing AS/400 applications get > on the band wagon, not too many shops will take the time to learn it. We too also have a 3rd party application - which was written in RPG3. We keep any modifications to this code in RPG3, but all of our programs are in ILE and I'm even trying to drag the programming staff to free-form. Bill