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


  1.  Home
  2. RPG400-L
  3. December 2013

Re: Need some ammunition (Procedures vs. Sub-routines)

Ok, so your main problem is that this guy thinks the sun revolves around
the earth...

You need to show him otherwise.

Perhaps you should point out that _every_ RPGLE program, including those
created via CRTBNDRPG DFTACTGRP(*YES) already has procedure calls bound in
by the compiler. Try doing a DSPPGM or DSPPGMREF and you'll see:
Service
Opt Program Library Activation
QRNXIE QSYS *IMMED
QRNXIO QSYS *IMMED
QRNXUTIL QSYS *IMMED
QLEAWI QSYS *IMMED

Additionally, try looking at the call stack of a running RPGLE program vs
an RPG III program...
RPGLE
Program Statement Procedure
FM010W OLSMLPRG _QRNP_PEP_FM010W
FM010W OLSMLPRG 87300 FM010W

RPG
Program Statement Procedure
FM060W OLSMLPRG .DRVRR06 /08ED

So your applications are already using procedures without issue. The
internal proc will make no difference outside the program that contains it
and you've already identified the self containing nature makes it safer for
the program that has it.

Good luck!


HTH,
Charles





On Fri, Dec 27, 2013 at 3:17 PM, RPGLIST <rpglist@xxxxxxxxxxx> wrote:

It was an "IT" directive, but the owner is a DB guy from way back and is
very hands on; changing the policy at this point would almost assuredly
require his buy off. Despite having a fantastic rep with him, he still
looks to the Director of IT and if he says no, its a no. I have to get by
him first.

Here is in essence what I was doing before I was told to revert the code:

I was adding a new procedure to an existing core app. The procedure was
and is totally self contained, does not share global variables and I even
went so far as to declare the work file locally so as to completely avoid
any possible cross contamination. Because there are no othere
"procedures" in the program this was considered going outside our "norm"
and therefore not permitted. Although this same core app has already been
modified with free format, so its moved some just not quite as much as I
would have liked.

I was told such a change, because it was going outside the "norm" would
require every program, screen, function key that was remotely associated
with the process to be fully and completely tested, despite the fact that
the entire change (outside of the procedure itself) was 1 line of
additional code. That's it, a simple call and done.

Of course this completely flies in the face of reality, changing,
modifying or using global variables and files is far more dangerous than
doing so in a self contained encapsulated procedure.

The reason I really think he pushed back, was a couple other programmers
complained about several other programs that were modified with procedures
and he's afraid of the push on this as well.

Dutch


Another point, Dutch. I had the impression that this was an "IT"
directive
from your original message; now you mentioned "owner." This can be
harder;
it can, also, be easier. Is the owner an IT/DB guy or is this just
something some @#$% consultant told him?

I ask because, when I started using ILE RPG at an employer, I was told I
couldn't because (drum roll, please) we had the 36 environment and they
didn't mix. (I hate idiots [i.e., overpaid consultants - but I've made a
lot of money fixing their stuff], but that's another issue.)

Since you're talking, I gather, internal subprocedures, depending upon
the
owner's expertise/reticence, maybe do either a code walkthrough (called
"dazzling with footwork" in that case) or a sample program with test for
his/her viewing.

Jerry C. Adams
IBM i Programmer/Analyst
Sometimes it's to your advantage for people to think you're crazy.
-Thelonius Monk
--
Home Office: 615-832-2730
email: midrange@xxxxxxxx


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:
rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of RPGLIST
Sent: Friday, December 27, 2013 12:23 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: RE: Need some ammunition (Procedures vs. Sub-routines)

External procedures is going to be a big stretch at this point Alan, I'm
just trying to get the owner to buy off on using them internally first.
Even that is difficult right now.


I like Gary's idea - but go one further Try and find 2 OR MORE
programs that have the same lines of code and show the powers that be
that if those lines of code were in a procedure, it would just be a
case of changing ONE thing (after those lines of code were replaced by
the new procedure)

Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Gary Thompson
Sent: Friday, December 27, 2013 11:59 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: RE: Need some ammunition (Procedures vs. Sub-routines)

Sounds like "sub-procedure" has been interpreted as "I plan to inject
our system with this virus I found"
so try switching the focus to "re-usable code" that once thoroughly
tested returns your investment because it is a "known and understood
function".

Yea, I bet you've already beat that drum . . .




-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of RPGLIST
Sent: Friday, December 27, 2013 9:00 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Need some ammunition (Procedures vs. Sub-routines)

I won't go into the entire lengthy and boring conversation I just had
with upper management, but I was basically told that under no
circumstances am
I to add procedures to certain applications. The justification is that
by doing so, we will be required to re-test the entire system,
payroll, dispatch, load balancing, AP, AR, etc.

I however was provided an opportunity to make my case, and I have a
list of reasons, but I need every bit of ammunition I can come up, so
any help from ya'll would be cool.

Dutch


--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.


Disclaimer: This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system. E-mail
transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive
late
or incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a result of
e-mail transmission. If verification is required please request a
hard-copy version. Any views or opinions presented are solely those of
the author and do not necessarily represent those of the company.
--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/rpg400-l.




--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To
subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.


--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...
Replies:
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.