|
midrange.com
Do you use QC2LE in any of your programs? Like
H Bnddir('QC2LE')
and then use system(), cosine(), etc? If so, then you are using a service
program. Now, you can make your own service program.
Your service program is composed of one or more modules. These modules
may be RPGLE, CLLE, etc.
If the module is RPGLE then instead of using CRTBNDRPG you use CRTRPGMOD
followed by CRTSRVPGM.
The member normally has a
H NOMAIN
Then it may be composed of one or more subprocedures.
For more details, I'd suggest you check out the rpg sorcerer's redbook
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 04:02 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
To
<rpg400-l@xxxxxxxxxxxx>
cc
Subject
Prototyped Procedures
A number of you have mentioned service programs
I have started to create prototyped procedures but not service programs
What are the differences (Coding, Calling, Compiling)
Thank You
Mike
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
rpg400-l-request@xxxxxxxxxxxx
Sent: Tuesday, February 01, 2005 3:52 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RPG400-L Digest, Vol 4, Issue 135
Send RPG400-L mailing list submissions to
rpg400-l@xxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/rpg400-l
or, via email, send a message with subject or body 'help' to
rpg400-l-request@xxxxxxxxxxxx
You can reach the person managing the list at
rpg400-l-owner@xxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific than
"Re: Contents of RPG400-L digest..."
Today's Topics:
1. RPG read loops (Paul Morgan)
2. RE: (Jeff Crosby)
3. RE: Prototyped Procedures (Alan Campin)
4. RE: Leave / Iter (was: Suggested Technique) (Alan Campin)
5. RE: RPG read loops (Bob Cozzi)
6. RE: Submitting jobs with a higher priority (Alan Campin)
7. RE: Prototyped Procedures (rob@xxxxxxxxx)
----------------------------------------------------------------------
message: 1
date: Tue, 1 Feb 2005 15:27:01 -0500
from: "Paul Morgan" <pmorgan@xxxxxxxxxxxxxx>
subject: RPG read loops
Almost all of the code in the current Leave / Iter thread showed a loop
like:
DoU F3 or F12
exfmt
If Not (F3 or F12)
// do something
EndIf
EndDo
This only has one exfmt statement inside a DoU loop. A similar file
read loop would be:
DoU %EoF
Read
If Not %Eof
// do something
EndIf
EndDo
which has one read statement inside of a DoU loop. Isn't there a better
way of coding loops with more than one read/exfmt like:
exfmt
DoW Not (F3 or F12)
// do something
exfmt
EndDo
or
Read
DoW Not %Eof
// do something
Read
EndDo
or
SetLL
ReadE
DoW Not %Eof
// do something
ReadE
EndDo
Most programmers seem to code with the single read/exfmt style which
IMHO complicates the code. In a DoU/Read loop the body of the loop is
nested two deep inside the DoU and an If statement. In a Read/DoW/Read
loop the body of the loop is nested one deep inside a DoW. Doesn't this
reduction in the nesting of the body of the loop improve the program?
Readability is improved. Performance is also improved (although minor)
with the removal of one test against the end of loop.
Other programmers I work with are adamant about not coding more than one
read statement. Why is coding more than one read statement such a
problem?
Paul
--
Paul Morgan
Senior Programmer Analyst - Retail
J. Jill Group
100 Birch Pond Drive, PO Box 2009
Tilton, NH 03276-2009
Phone: (603) 266-2117
Fax: (603) 266-2333
------------------------------
message: 2
date: Tue, 1 Feb 2005 15:27:14 -0500
from: "Jeff Crosby" <jlcrosby@xxxxxxxxxxxxxxxx>
subject: RE: Prototyped Procedures
> 1 other responder used QPROTOSRC. :-)
I use QPROTOSRC. But then I'm just an ordinary everyday guy.
--
Jeff Crosby
Dilgard Frozen Foods, Inc.
P.O. Box 13369
Ft. Wayne, IN 46868-3369
260-422-7531
The opinions expressed are my own and not necessarily the opinion of my
company. Unless I say so.
------------------------------
message: 3
date: Tue, 1 Feb 2005 13:31:37 -0700
from: Alan Campin <Alan.Campin@xxxxxxx>
subject: 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.
------------------------------
message: 4
date: Tue, 1 Feb 2005 13:34:08 -0700
from: Alan Campin <Alan.Campin@xxxxxxx>
subject: RE: Leave / Iter (was: Suggested Technique)
I would agree. The function does one thing, control. Lower level
functions implement actions. Beautiful clean code.
-----Original Message-----
From: Bob Cozzi [mailto:cozzi@xxxxxxxxx]
Sent: Tuesday, February 01, 2005 12:01 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Leave / Iter (was: Suggested Technique)
Beautiful!
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of MWalter@xxxxxxxxxxxxxxx
Sent: Tuesday, February 01, 2005 12:45 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Leave / Iter (was: Suggested Technique)
I agree. If you keep your looping constructs within manageable boundries
using subprocedures and/or subroutines, using leave or iter, to me, is
just as intuitive as not using them.
I often code display loops like this:
dow 1 = 1;
exfmt prompt;
select;
when f3Key;
leave;
when f6Key;
add();
when f5Key;
doSomethingElse();
endsl;
enddo;
return;
Thanks,
Mark
Mark D. Walter
Senior Programmer/Analyst
CCX, Inc.
mwalter@xxxxxxxxxx
http://www.ccxinc.com
"Bob Cozzi"
<cozzi@xxxxxxxxx>
Sent by:
To
rpg400-l-bounces@ "'RPG programming on the AS400 /
midrange.com iSeries'" <rpg400-l@xxxxxxxxxxxx>
cc
02/01/2005 01:26
Subject
PM RE: Leave / Iter (was: Suggested
Technique)
Please respond to
RPG programming
on the AS400 /
iSeries
<rpg400-l@midrang
e.com>
What's the real difference from a maintenance perspective if I use:
EXIT_MODE = QUIT
or if I use:
LEAVE or LEAVESR
It just seems strange that someone would advocate (and I'm not say you
Joel)
avoiding Leave/LeaveSR and then use *IN03 in their code illustrating the
point.
-Bob
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Joel Fritz
Sent: Tuesday, February 01, 2005 12:12 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Leave / Iter (was: Suggested Technique)
Well... You could code it something like:
exit_mode = STAY;
//STAY is a constant--others defined for different possible states dow
exit_mode = STAY;
select;
when *in03;
exit_mode = QUIT;
when cond_1;
exit_mode = proc_cond_1(....);
................
endsl;
enddo;
In an event loop it's very likely that there is more than one condition
that will end the loop. It may be cleaner to examine the state,
especially since you may need to know the state after the loop ends.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of
antoine.contal@xxxxxxx
Sent: Tuesday, February 01, 2005 2:23 AM
To: RPG programming on the AS400 / iSeries
Subject: Leave / Iter (was: Suggested Technique)
Using an indicator variable cannot be the best solution. I'm not saying
leave/iter is the best, but your solution leads to code duplication. And
we all know what code duplication leads to in the long run, from both
theoretical and practical perspectives. :-(
Regards.
--
Antoine CONTAL
*****************************
NOTICE:
All e-mail sent to or from this e-mail address will be received or
otherwise recorded by The Sharper Image corporate e-mail system and is
subject to archival, monitoring, and review by and/or disclosure to
Sharper Image security and other management. This message is intended
only for the use of the addressee and may contain information that is
privileged and confidential.
The contents of this message may contain personal views which are not
the views of The Sharper Image. If you are not the intended recipient,
dissemination of this communication is prohibited.
*****************************
--
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.
------------------------------
message: 5
date: Tue, 1 Feb 2005 14:39:06 -0600
from: "Bob Cozzi" <cozzi@xxxxxxxxx>
subject: RE: RPG read loops
Yes there is a better way...
I will only tell you the answer, however, after you send me a diagram
illustrating how, in the figure below, to connect the top row of 3 dots
with the bottom row of 3 dots using a line drawn with a pen or pencil
WITHOUT ever allowing any of the lines to intersect. This has to be
accomplished on a two-dimensional surface. You have ten minutes... Go!
* * *
* * *
-Bob Cozzi
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Paul Morgan
Sent: Tuesday, February 01, 2005 2:27 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RPG read loops
Almost all of the code in the current Leave / Iter thread showed a loop
like:
DoU F3 or F12
exfmt
If Not (F3 or F12)
// do something
EndIf
EndDo
This only has one exfmt statement inside a DoU loop. A similar file
read loop would be:
DoU %EoF
Read
If Not %Eof
// do something
EndIf
EndDo
which has one read statement inside of a DoU loop. Isn't there a better
way of coding loops with more than one read/exfmt like:
exfmt
DoW Not (F3 or F12)
// do something
exfmt
EndDo
or
Read
DoW Not %Eof
// do something
Read
EndDo
or
SetLL
ReadE
DoW Not %Eof
// do something
ReadE
EndDo
Most programmers seem to code with the single read/exfmt style which
IMHO complicates the code. In a DoU/Read loop the body of the loop is
nested two deep inside the DoU and an If statement. In a Read/DoW/Read
loop the body of the loop is nested one deep inside a DoW. Doesn't this
reduction in the nesting of the body of the loop improve the program?
Readability is improved. Performance is also improved (although minor)
with the removal of one test against the end of loop.
Other programmers I work with are adamant about not coding more than one
read statement. Why is coding more than one read statement such a
problem?
Paul
--
Paul Morgan
Senior Programmer Analyst - Retail
J. Jill Group
100 Birch Pond Drive, PO Box 2009
Tilton, NH 03276-2009
Phone: (603) 266-2117
Fax: (603) 266-2333
--
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.
------------------------------
message: 6
date: Tue, 1 Feb 2005 13:41:01 -0700
from: Alan Campin <Alan.Campin@xxxxxxx>
subject: RE: Submitting jobs with a higher priority
If you are using ILE and modules, just use the language that does it
best. Do it in CLLE. Create a module for CL to receive the parms and do
a submit job. Then just bind them to the RPG. The CL does it's job and
the RPG does it's job and you have one program object. That is why I
love ILE.
Of course my boss hates it. He wants everything done in one big monolith
program.
-----Original Message-----
From: JMBauman@xxxxxxxxxxxxxxxx [mailto:JMBauman@xxxxxxxxxxxxxxxx]
Sent: Tuesday, February 01, 2005 8:00 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Submitting jobs with a higher priority
I want to submit jobs to a job queue at a run priority of 20. Any clue
on how to do this? I am submitting job from an RPG program using
QCMDEXEC.
Thanks
John M. Bauman
Project Manager - Lead Programmer/Analyst
Ward Trucking
Second Avenue & Seventh Street, Greenwood
Altoona, PA 16603
Direct Voice (814) 947-1284
Fax (814) 944-5470
www.wardtrucking.com
------------------------------
message: 7
date: Tue, 1 Feb 2005 15:51:38 -0500
from: rob@xxxxxxxxx
subject: RE: Prototyped Procedures
bad manners and the fact that you have to give it different names. Like
the _PR example previously noted.
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 03:23 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
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.
--
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) digest
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.
End of RPG400-L Digest, Vol 4, Issue 135
****************************************
--
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.
