|
midrange.com
This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
And you can have a plethora of signatures. Not just one current and one
*prv. Actually my service has seven signatures. It would have had more
if I had found out about binder language earlier.
Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
rob@dekko.com
Sent by: rpg400-l-admin@midrange.com
04/19/2002 10:41 AM
Please respond to rpg400-l
To: rpg400-l@midrange.com
cc:
Fax to:
Subject: Re: Service Programs
This is a multipart message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
With a service program you can change certain parts of the service program
and not have to recompile every program using it.
Rule 1) You could change the logic within a subprocedure with no worry
about recompiling other programs.
For example if I change
x=y*2
to
x=y*3
I will not have to recompile programs using this service program.
Rule 2) Do not remove a subprocedure, or modify the number of parameters
passed to a particular subprocedure.
Instead, change deprecated subprocedures to call new ones. If you truly
feel you need more parameters add a new subprocedure and have it do what
it needs with the new parameters and try to use the old subprocedure for
the old parameters.
Rule 3) If you add a new subprocedure to the service program you had
better start learning about:
Signatures
Binder language
Simply put - If have a service program with two subprocedures I would have
the following:
mylib/qsrvsrc(mysrvpgm). This is binder language. Only 3 verbs that I
use. Pretty simple stuff.
STRPGMEXP PGMLVL(*CURRENT) LVLCHK(*YES) SIGNATURE(*GEN)
/********************************************************************/
/* *MODULE SRVPGM ROUTINES 04/11/02 14:01:00 */
/********************************************************************/
EXPORT SYMBOL("ADDDAYS")
EXPORT SYMBOL("CENTER40")
EXPORT SYMBOL("NEWSUBPROC")
ENDPGMEXP
Then if I add a new subprocedure I would have:
STRPGMEXP PGMLVL(*PRV) LVLCHK(*YES) SIGNATURE(*GEN)
/********************************************************************/
/* *MODULE SRVPGM ROUTINES 04/11/02 14:01:00 */
/********************************************************************/
EXPORT SYMBOL("ADDDAYS")
EXPORT SYMBOL("CENTER40")
ENDPGMEXP
Notice the *CURRENT and the *PRV?
CRTSRVPGM ... SRCFILE(ROUTINES/QSRVSRC) ...
Now, If I do a
DSPSRVPGM SRVPGM(ROUTINES/SRVPGM) DETAIL(*SIGNATURE)
You will see:
49D4A34A5AE6D049BA18DEB5EB4FF53E
B49D4A34A5AE60E85D74405E3288A2D7
And If I do a
DSPPGM PGM(ROB/CHECKRD) DETAIL(*SRVPGM)
You will see
Service
Program Library Signature
SRVPGM ROUTINES 49D4A34A5AE6D049BA18DEB5EB4FF53E
Notice how the signature matches one of the available signatures in my
service program?
Rob Berendt
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin
Justin Houchin <jhouchin9@charter.net>
Sent by: rpg400-l-admin@midrange.com
04/19/2002 10:04 AM
Please respond to rpg400-l
To: rpg400-l@midrange.com
cc:
Fax to:
Subject: Re: Service Programs
So let me get this straight, with a service program, I can change the its
module and I do not have to recompile the program? And what do you mean by
"signature"?
Justin Houchin
----- Original Message -----
From: <dmosley@dancik.com>
To: <rpg400-l@midrange.com>
Sent: Friday, April 19, 2002 9:59 AM
Subject: Re: Service Programs
>
> For one, if the module changes, then the Program itself has to be
> re-compiled. If the module/service program changes, no big deal. (As
long
> as the signature doesn't change)
>
> David L. Mosley, Jr.
> Systems Analyst
> 2000 CentreGreen Way
> Suite 250
> Cary, NC 27513
>
>
>
> Justin Houchin
> <jhouchin9@charte To: RPG Midrange
<rpg400-l@midrange.com>
> r.net> cc:
> Sent by: Subject: Service
Programs
> rpg400-l-admin@mi
> drange.com
>
>
> 04/19/02 10:50 AM
> Please respond to
> rpg400-l
>
>
>
>
>
>
> This is a multi-part message in MIME format.
> --
> [ Picked text/plain from multipart/alternative ]
> Hi Everyone,
> What is the advantage of creating a service program out of a module
> than just binding that module to create the program?
>
>
> Justin Houchin
> Programmer
> Reliatek, Inc
> _______________________________________________
> 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.
>
>
>
>
> _______________________________________________
> 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.
>
>
_______________________________________________
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.
_______________________________________________
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.
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.
