RE: Prototyped Procedures

["Bob Cozzi" <cozzi@xxxxxxxxx>]

I agree with all but one of Rob's comments.
"Traditionally prototypes are saved in a file name QPROTOSRC".
"Traditionally in Rob's shop" is probably accurate.
I have only seen prototypes in a source file with one of the following
names:

QCPYSRC
QCPYLESRC 
QINCSRC
QINCLUDE

I see QCPYSRC used the most frequently and have made that my standard.
I do see other names used in things such as CGIDEV2, but standards and
consistency when it comes to naming conventions has never been a strong
point of CGIDEV2.

-Bob


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of rob@xxxxxxxxx
Sent: Tuesday, February 01, 2005 12:59 PM
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.


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