... if I would recommend the same, others did, my post would have been obvious! Making only partial use of procedures, does have nearly no benefit. Go the road to the end, or stay, where you are!
The first step one takes is progress toward the end of the road, no?
--buck
#1. I was the loner in the shop where I worked when RPG got subprocedures. Their productivity value was rather obvious, but being new, caution was the word. So, I just used them internally kind of like subroutines. And went from there. Put your toes in the pool first.
#2. In an environment like that, maybe avoid introducing it into a "core app"? (Order entry is usually like that). Might management let you try it on some program that is not so crucial? Because it sounded like this is a "core program"?
#3. Remember that redbook that addressed these and other, ahem, "new" functionality available introduced for RPG? That was a fantastic help to me in accelerating the process. The book can be shared.
#4. So some other programs have procedures? All internal, presumably. These deserve mention if they are running smoothly.
...BUT in the end, I don't know what to do about the politics programmers that are so stuck. Had a discussion with one of them at one place I worked at. I explained encapsulation benefit by another word, but he then said you get that with a CALL and parameters. Then I explained how you can do it more fine-tuned and granular than calls, performance issues, etc., but he veered the discussion to a tangent.
---And he was one who had complained about a former IT director that had refused accepting anything past RPG-2 style coding! My stay at that place ended shortly after that.
#5. There is hope. :-) You get to make your case.
(a) Request a "non-core" project, or new coding project, so you can use it there. That way, they don't have to "re-test" everything all over again. What can it hurt? With a few of those, it will grow. If other programmers have a problem, avoid the topic, because that avoids the ego defense.
(b) You're making a list and checking it twice...
---Was it Alan's suggestion to show the procedures and service programs already being used in the DFTACTGRP(*YES) compiles?
(c) Bullets? Check off each objection,
(d) emphasis on internal procedures,
(e) then check off the advantages,
(f) URL's to lists like Jon Paris' and success stories.
(G) --> Not least, compile numbers for how many RPG positions require knowledge of procedures and service programs.
--------------------------------------------------------------------------------
Confidentiality Notice: This email may contain confidential information or information covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions. It contains information that is legally privileged, confidential or otherwise protected from use or disclosure. This e-mail message, including any attachments, is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
--------------------------------------------------------------------------------
midrange.com
