|
QPROTOS QPROTOSRC QCPYSRC QINCLUDE QINCSRC Doesn't matter to me. I think the redbook folks probably just picked a name for their file/member names that, in this case, were somewhat documenting the thing. And, can you believe IBM still names its book pages as "section 2.1.6.2"? Talk about writing for Attorneys, yuke! The best thing to do is to put the prototypes someplace other than within the procedure implementation source. Keeping it altogether in one source member is just bad manners. :) -Bob -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx Sent: Tuesday, February 01, 2005 2:10 PM To: RPG programming on the AS400 / iSeries Subject: RE: Prototyped Procedures 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. -- 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 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.