× 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 other responder used QPROTOSRC.  :-)

I see a lot of SUBPROCSRC in everyone's favorite redbook.  They had a 
golden opportunity to clarify this in section 2.1.6.2 but left it alone.

The redbook talked about keeping the prototypes and the data structures 
used within it in the same member.  We don't.  For example, we may put our 
prototypes for a particular api in one member and a separate member(s) for 
the data structure(s) involved.  Some sample member names:
MBRD0100
MBRD0200
MBRD0300
QUSRMBRD




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





"Bob Cozzi" <cozzi@xxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
02/01/2005 02:16 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"'RPG programming on the AS400 / iSeries'" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: Prototyped Procedures






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.




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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.