RE: Prototyped Procedures

I am not sure what your question is concerning prototypes. Prototypes are just 
copies of the procedure definition to tell the compiler what the procedure 
looks like so they are just copies but I have a hunch that is not your question.

As to subprocedure in a source member, to me, the central rule is still the 
same, encapsulation, in other words, you group together things that belong 
together to hide them. For example, I have a common functions service program. 

In XVCMNF_M01, I have error message handling. 
In XVCMNF_M02, I have ILE Condition Handling.
In XVCMNF_M03, I have String Functions, 
etc. 

They all get bound together to become XVCMNF. I just put like functions in the 
same module. I then have one source member, XVCMNF_PR that contain the 
prototypes for the service program. 

I am looking at program now where I want message processing in one module and 
IFS I/O in another.

What I am always trying to do is information hiding. In a module that is doing 
message processing, I don't need to have functions that do IFS I/O. I can hide 
them away. I don't need the complexity in that module. Do I really need to know 
how IFS I/O works? No, I just need to call a function to read or write. How it 
works is immaterial to me. 

That, to me, is the whole purpose of having subprocedure and modules. 
Encapsulate complexity and hide it away. I then can focus on the problem I am 
trying to solve and when I work on the IFS I/O, I can test it separately and 
concentrate on it without worrying about anything else. 

The other issue that comes up is global variables. In my XVCMNF_M01 module, I 
have certain global(static) variables. The only functions that I want acting on 
those variables are error message handling functions. If I mix together String 
functions with error message handling, something from string functions could 
screw up the variables for error handling by accident. Putting the error 
handling in a separate module means I protect those variables so I am always 
looking at a module to see if their are global variables that should be hidden 
in a separate module so I naturally group together any functions that work on a 
static variable in a separate module. 

Also, on source file names. Why do we insist on using multiple source file 
names? I prefer to use one source file, QSRCF. I than have everything together 
in one source files and do not have to constantly be shifting between source 
files. My boss forces me to use multiple source files and I end up using 4 or 5 
different source files for a project. What a waste of time. 

Anyway, my two cents. 

-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
Sent: Tuesday, February 01, 2005 11:59 AM
To: RPG programming on the AS400 / iSeries
Subject: Re: Prototyped Procedures


Traditionally prototypes are saved in a source file named QPROTOSRC.  And
they would have the same name as the subprocedure or program they are the
prototype for.  For example
D/COPY MYLIB/QCPYSRC,GETGRP_PR
becomes
D/COPY MYLIB/QPROTOSRC,GETGROUP

The advantages to setting up multiple subprocedures in one source member
are the same for setting up multiple subroutines in a source member.

However, if you are talking about subprocedures you are planning on using
in a service program then that's a different story.  I suppose a lot of
that is style.  Some may be because the subprocedures are written in
different languages.  But whether you:
- Keep each subprocedure in it's own source member and in it's own service
program.
- Keep subprocedures grouped by function (like date, or bill of material,
etc) in multiple source members but one service program
- Keep subprocedures grouped by function in one source member and one
service program
- Keep all subprocedures in separate source members, but one service
program
- Keep all subprocedures in one source member and one service program
is largely a matter of style.

I will caution you that one monolithic general copy member will drive the
anal retentive people who's goal is to not have one unreferenced variable
in their program into a foaming at the mouth fit.  They will end up
chopping out what they need and physically copying in to each desired
member.  And I am not talking /copy here.
If you still want the monolith it's better to
- use /include instead of /copy, (but they work the same on V5R3)
(imbedded SQL programmers understand the difference between /include and
/copy)
- and nest the members
For example your monolith becomes merely a string of /include statements.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Ala, Michael A" <michael.ala@xxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
02/01/2005 01:28 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
<rpg400-l@xxxxxxxxxxxx>
cc

Subject
Prototyped Procedures






What is the best way to perform Procedure prototyping
I would like some rules
I am not sure if I am performing any steps that are unecessary
This is in the caller
D/COPY MYLIB/QCPYSRC,GETGRP_PR

This is what is copied in
D GetGroup        PR             1A   EXTPROC('GETGROUP')
D  $Group                       10A
D  $Cust#                        8S 0 CONST OPTIONS(*OMIT)
D  $Item#                       25A   OPTIONS(*NOPASS)


Here is the call for the Procedure (um Function)
EVAL      $CustGrp=GETGROUP($Group:CUST#)

Here is what is in the called Procedure
D/COPY MYLIB/QCPYSRC,GETGRP_PR
PGETGROUP         B                   EXPORT
D GetGroup        PI             1A
D  $Group                       10A
D  $Cust#                        8S 0 CONST OPTIONS(*OMIT)
D  $Item#                       25A   OPTIONS(*NOPASS)
D  $Found         S              1A   INZ('N')


Also what are the advantages to setting up multiple sub-procedures in a
single source member
What limitations does this have



I am always doing things I can't do; that's how I get to do them.

 -Pablo Picasso


--
This is the RPG programming on the AS400 / 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.