|
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. -- [ Picked text/plain from multipart/alternative ] The short, flippant answer is "Yes." Dynamic calls and calls to procedures in service programs can be coded exactly the same except on the PR line in the prototype you'd use "extpgm" for the dynamic call and "extproc" for the service program procedure. Use "callp name(parms)". Personally, I'd code it as a service program, but I think the real answer is "It depends." If it gets called by OPM programs, it's probably better as a dynamic call. You can use a prototype and callp in RPGIV programs and the old call with plist in the OPM stuff. I'd definitely write the program with a prototype and procedure interface instead of a *entry plist. > -----Original Message----- > From: Booth Martin [mailto:Booth@MartinVT.com] > Sent: Thursday, August 15, 2002 9:50 AM > To: rpg400-l@midrange.com > Subject: RE: diff btw Procedures and Routines > > > -- > -- > [ Picked text/plain from multipart/alternative ] > I've been 5 years trying to get this straight and am still > confused. Lets > say I have a utility program that is a pop-up calendar. The > parm is a date. > Should this be a program or a procedure? > > > > --------------------------------------------------------- > Booth Martin http://www.MartinVT.com > Booth@MartinVT.com > --------------------------------------------------------- > > -------Original Message------- > > From: rpg400-l@midrange.com > Date: Thursday, August 15, 2002 12:45:09 > To: 'rpg400-l@midrange.com' > Subject: RE: diff btw Procedures and Routines > > A procedure is encapsulated, where a subroutine is not. > > That is, a procedure can see variables that it defines, but > not variables > that the main program defines. This makes it a lot easier to > determine what > a procedure is actually doing and where it's getting it's > return value(s). > > This makes a procedure "stand alone", and can be used in > other programs with > little modification (modification required for any File I/O > may be required) > > > It can be extremely difficult to copy a subroutine to another > program, as > you have to determine all the variables the subroutine uses, > and what these > are supposed to be set for, etc... > > I have been known to break my RPG IV program into Subroutines > when it starts > getting too large to group the logic. Whether or not these > should be broken > up into Procedures is probably a personal choice. But, > subroutines that > calculate a value or such, those I would put into Procedures. > > Regards, > > Jim Langston > > -----Original Message----- > From: MURALI DHAR [mailto:nmuralidhar@rediffmail.com] > > why do we use procedures only in modules in ILE programs?why nt > subroutines?whats the diff ...plz kindly answer me > Best regards > Murali > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) > mailing list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > > > . > -- > [ Content of type image/gif deleted ] > -- > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) > mailing list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > 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, 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. If you are not the intended recipient, dissemination of this communication is prohibited.
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.