Re: Eliminating *MODULES with IMPORT and EXPORT parms and replacing them with Service Programs

Thanks Scott and Eric for providing your input and I apologize that it
took me a few days to respond. I will try to clarify a bit more.

When I referred to import/export parms in my original post, I was
referring to the use of those RPG keywords in D-Specs for globally defined
fields or data structures used in modules coded without a procedure
interface. I see now how this could be very confusing in terms of my
original post. My apologies.

Just FYI... CALLB doesn't call a 'module'. It calls a procedure. In
the old v3r1 examples, the main procedure of each module always had the
same name as the module itself -- so it sort of looked like you were
calling the module. But, in truth, you were calling a procedure.

CALLB works on all types of procedures (both sub-procedures and main
procedures.)

CALLP can call anything (programs, java methods, sub-procedures or main
procedures.) Note that this includes everything that CALLB can do, plus

quite a bit more.

I'm not sure if you understood that distinction or not... but I often
run into people who think 'CALLB is for modules' and 'CALLP is for
subprocedures' which is complete poppycock.

Scott - your last sentence from your nails it - I *was under the
impression that CALLB is for modules and CALLP for subprocs - thanks for
clarifying.

You can't convert a module into a service program. Service programs are

built from modules, just as programs are! But, you can bind by
reference instead of binding by copy. Is that what you mean?

Yes that is what I wanted to say. I want to get our programmers out of the
bind by copy mindset and begin to bind by reference. This was due to the
fact that we found one heavily used monolithic program that has 160+
modules bound into it - which results in a program size of 33mb. We are
attempting to rewrite that one program into a new application and I want
the programmers to avoid the 'mistakes' of the past.

Then in the programs that do the callb, change the import parms to

place

them in a data structure using the same field names and attributes

which

would be returned from the (new) service program.

Not sure that I understand this... Consider simply calling a procedure
and getting back the value of the parameter(s)."

Yes - the goal is to call the procedure and get back the value of the
parameters. Perhaps this will be a bit clearer by adding my comments
(inline) to Eric's response, which follows:

I think, if your goal is to spruce up this code, would be to create your

prototypes and PI's, and replace your CALLB's with your new prototyped
interface. This eliminates

the messy CALLB syntax which does not work with /free (if that is at all

important to you)."

Yes - My goal is to replace callb's with PI's for consistency. (We are
also converting to /free when we make any mods or write new code.)

Re: procedure exports, there should be little need to do more than to

add the EXPORT tag to your PI's in the module. Make sure to put your
prototypes for all exported procs > into a copy member, so that you can
easily import these prototypes for use in your application.

Copy members are a shop standard for PI's

Export fields? I really don't like the idea of exporting module data

this way. This becomes an "undocumented" interface to the procedures that
use this data, and is rarely > worth the trouble, imo. This is much like
using LDA to pass data between programs in a job. It works, but it's not
easy to figure out when problems occur...

Definitely undocumented. That's a good point for justifying why the PI
should be created. (I wonder if that was the reason behind IBM's change of
heart I alluded to in my original post?)

Much better to be clear about the exchange of data being passed to a

procedure. I have become a fan of template DS to describe custom "data
types", say for example

"ADDRESS". Address might consists of: NameLine, CareOf, Street1,

Street2, City, State, Postal, geocode. Now, for any procedure that
manipulates or processes an address can > pass the DS as a single data
entity (object), and the intent of the proc is crystal clear. Use good
naming practices to ensure that your code reads like a story.

Template DS - that sort of relates to what I was trying to say at the end
of my original post. My initial thought is that it would be the mechanism
to replace the globally defined D-spec fields/ds's containing the
export/import keywords.

Sorry, got off track.
HTH,

-Eric DeLong"

Not off track at all - these are the type of things I want to get my staff
(and myself) to start thinking about.

Being an old dog, new tricks are always a challenge. (And as my wife likes
to say "Change is good - but you go first".)

Thanks, Jerry

Gerald Kern - Information Technology
Programming Supervisor
IBM Certified RPG IV Developer
Lotus Notes/Domino 8.0.1 Administrator
The Toledo Clinic, Inc.
4235 Secor Road
Toledo, OH 43623
Phone 419-479-5535
gkern@xxxxxxxxxxxxxxxx


This e-mail message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized use, disclosure or distribution is
prohibited. If you are not the intended recipient, please inform the
sender by reply e-mail and destroy this and all copies of this message.