Ü
Static binding & Dynamic binding
We should be aware of the binding concept
before we proceed with Service program.
·
Dynamic binding means that neither
program knows about the other until the call takes place. In that sense it is
dynamic, because all the binding is happening right at the time the program is
called. Whenever you call one program from another using the CALL operation, you
are dynamically binding those programs.
·
Static binding, on the other hand, is
the method of binding two objects together well before they ever use each
other. This type of binding is static, in that the objects are bound together
and the relationship between those bound objects remains consistent.
Static binding
Vs. Dynamic binding
·
In dynamic binding if we have more
modules, there will be more time to do program call resolution and program
startup tasks.
·
If we don’t go for modularity then there
won’t be any overhead for program call resolution and program startup tasks,
but to maintain a single big program is not an easy task.
Ü Modules
Module is another concept that is used in Service
program.
·
Modules allow you to organize
related tasks into smaller units of code, which can then be bound together into
programs or service programs.
·
They cannot be called using the
dynamic CALL operation but are, instead, called with either the bound call
(CALLB in RPG) or a prototyped call (CALLP in RPG).
·
NOMAIN modules cannot be called
directly. Instead, the subprocedures contained inside the module are called
using prototyped call (CALLP in RPG).
Ü Service program
Service Program (*SRVPGM) can be viewed as a collection of
subroutines packaged together and accessible to the outside world. You use the
CRTSRVPGM command to create a service program.
Ü Procedures (or subprocedures)
Procedures (also known as subprocedures)
are the smallest component of static binding.
Ü Types of Static binding
There
are two types of static binding: Bind by copy and bind by reference.
¤
Bind by copy is accomplished by copying two or more modules into
a program.
Columns . . . : 6 76 Edit AMIT/QRPGLESRC
SEU==> MODULE1
FMT H HKeywords++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*************** Beginning of data *************************************
0001.00 HOPTION(*NODEBUGIO)
0002.00 DVAR1 S 5 0 EXPORT INZ(11111)
0003.00 DVAR2 S 5 0 IMPORT
0003.03 C CALLB 'MODULE2'
0003.04 C EVAL VAR1=VAR2 +33333 >>>>>>>>>>>>>>> VAR2=55555
0005.00 C VAR1 DSPLY
0006.00 C SETON LR
****************** End of data ****************************************
Columns . . . : 6 76 Edit AMIT/QRPGLESRC
SEU==> MODULE2
FMT D DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++
*************** Beginning of data *************************************
0002.00 DVAR1 S 5 0 IMPORT
0003.00 DVAR3 S 5 0 IMPORT
0003.07 DVAR2 S 5 0 EXPORT
0003.08 C CALLB 'MODULE3'
0004.00 C EVAL VAR2=VAR1+VAR3 >>>>>>>>>>>>>>> VAR2=22222
0005.00 C RETURN
****************** End of data ****************************************
Columns . . . : 6 76 Browse AMIT/QRPGLESRC
SEU==> MODULE3
FMT D DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++
*************** Beginning of data *************************************
0002.00 DVAR3 S 5 0 EXPORT
0004.00 C EVAL VAR3=11111 >>>>>>>>>> VAR3=11111 (NOT 10101)
0004.01 C RETURN
0004.02 C EVAL VAR3=10101 >>>>>>>>>> Control doesn’t reach here
****************** End of data ****************************************
CRTRPGMOD MODULE(AMIT/MODULE1) SRCFILE(AMIT/QRPGLESRC)
CRTRPGMOD MODULE(AMIT/MODULE2) SRCFILE(AMIT/QRPGLESRC)
CRTRPGMOD MODULE(AMIT/MODULE3) SRCFILE(AMIT/QRPGLESRC)
CRTPGM PGM(AMIT/PROGRAM1) MODULE(MODULE1 MODULE2 MODULE3) ENTMOD(MODULE1)
Notice that MODULE1 actually calls the other two modules, using the
CALLB operation. That's because the MODULE1 module was made the program entry
procedure (PEP) by the ENTMOD parameter in the CRTPGM command.
¤ Bind by reference works a little differently. Modules are still bound together to form
an object, but this time the object is a service
program (*SRVPGM), not a program.
- There exists only one copy of the code, but that copy is loaded
at runtime and shared with other programs or service programs that might
need it.
- A service program is not all that different from a program,
except that each module contains one or more subprocedures and those
subprocedures, not the modules, are the entry points into the service
program.
- One of the beauties of service programs is that they have
multiple entry and exit points.
- You can think of a service program as many subroutines bunched
together and made available to the outside world.
- Another thing is that the modules contained in service programs
contain no program entry procedure (PEP),
as our program did. This is accomplished by adding an H-spec (NOMAIN) entry in each module.
- NOMAIN states that there is no
PEP, and therefore much of the tasks done at program startup,
including the loading of the logic cycle, are not done. This lightens the
object significantly.
- It also means that in addition to the service program not being
able to be called directly, the modules can't be called, either.
- The only way to access the service program is through the
subprocedures. The module becomes little more than a container for its
subprocedures.
Create and use the service program
(Bind by reference)
Columns . . . : 6 76 Browse AMIT/QRPGLESRC
SEU==> MODULE_IFC
FMT H HKeywords++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*************** Beginning of data *************************************
0000.01 HNOMAIN
0000.02 *
0000.03 DPROC1 PR
0000.04 DPROC2 PR
0000.05 DPROC3 PR
0000.06 PPROC1 B EXPORT
0000.07 DPROC1 PI
0000.08 C 'PROCEDURE1' DSPLY
0000.09 PPROC1 E
0000.10 *
0000.11 PPROC2 B EXPORT
0000.12 DPROC2 PI
0000.13 C 'PROCEDURE2' DSPLY
0000.14 PPROC2 E
0001.00 *
0003.00 PPROC3 B EXPORT
0004.00 DPROC3 PI
0005.00 C 'PROCEDURE3' DSPLY
0006.00 PPROC3 E
****************** End of data ****************************************
Now create Service program SRVPGM1:
CRTRPGMOD MODULE(AMIT/MODULE_IFC) SRCFILE(AMIT/QRPGLESRC)
CRTSRVPGM SRVPGM(AMIT/SRVPGM1) MODULE(AMIT/MODULE_IFC) EXPORT(*ALL) SRCFILE(QRPGLESRC)
¤ Points
to remember here:
·
These are three entry points here into this module, meaning that any of
these 3 subprocedures can be called from outside this module, provided we
define them to be exported.
·
The EXPORT (*ALL) parameter tells which subprocedures you want to make
available to the outside world.
·
If a module is going to be called by one program and one program only,
use bind by copy. It is the best overall performer in this case, because the
code is copied right into the program at compile time.
·
However, this becomes a potential maintenance and compile nightmare if
we decide to use bind by copy and the module is going to be called by many
programs. In that case it is better to go for bind by reference.
Columns . . . : 6 76 Browse AMIT/QRPGLESRC
SEU==> CALLSRVPGM
FMT H HKeywords++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*************** Beginning of data *************************************
0001.00 HOPTION(*NODEBUGIO)
0001.01 DPROC1 PR
0001.02 DPROC2 PR
0001.03 DPROC3 PR
0003.03 C CALLP PROC1
0003.04 C CALLP PROC2
0003.05 C CALLP PROC3
0003.06 C movel 1 i 1 0
0006.00 C SETON LR
****************** End of data ****************************************
Now bind the service program
SRVPGM1 to the calling program CALLSRVPGM:
CRTRPGMOD MODULE(AMIT/CALLSRVPGM) SRCFILE(AMIT/QRPGLESRC)
CRTPGM PGM(AMIT/CALLSRVPGM) MODULE(AMIT/CALLSRVPGM) BNDSRVPGM(AMIT/SRVPGM1)
CALL PGM(AMIT/CALLSRVPGM)
O/P
DSPLY PROCEDURE1
DSPLY PROCEDURE2
DSPLY PROCEDURE3
Ü Advantages of
service programs
- They do not take up auxiliary storage space. There is only one
copy for all users.
- There is only a single copy of the read-only code in main
storage for all users in this service program is the same as a program
that you call dynamically.
- Each user of the service program has an independent work area.
- You can pass parameters to a service programs by using the
traditional parameter list (or) by importing and exporting variables.
- Service programs can be maintained independently of the
programs that use the functions. In most cases, changing a service
programs does not cause a program using the function to be changed or
re-created.
Ü Disadvantages of
service programs
·
Service programs are less
desirable for a function you may or may not need. The reason is that it is
slower to call a main program that refer to a service program
Ü Subprocedures:
Better than Subroutines
Subroutines have their limitations, two
of which are:
·
The first is that subroutines use global variables only. That is, any
variable or constant or indicator that I use in a subroutine may be used
anywhere else in the program--in the main calculations, in any subroutine, in
output specs. This can lead to undesirable side effects.
·
The other thing that bothers me is that I can't define parameters to
pass data to subroutines.
·
Subroutines are faster than subprocedures. I have never had to worry
about the performance of subprocedures, but in a heavily used program,
performance may become an issue. Using subroutines instead of subprocedures may
make a difference.
Ü Binding directory
When
you create a program or service program, you can list the modules for the
program
CRTPGM PRODLIB/MYPGM MODULE(BLDLIB/MOD1 BLDLIB/MOD2 BLDLIB/MOD3)
Or
you can list them in a “binding directory”
CRTPGM PRODLIB/MYPGM BNDDIR(BLDLIB/MYPGM)
Binding
directory listing modules to create a program
A
binding directory is just a list, containing modules and/or/service programs.
CRTBNDDIR BLDLIB/MYBNDDIR
ADDBNDDIRE BLDLIB/MYBNDDIR OBJ((BLDLIB/MOD1 *MODULE))
...
ADDBNDDIRE BLDLIB/MYBNDDIR OBJ((PRODLIB/SRVPGM1 *SRVPGM))
Specifying the service programs when creating a pgm
CRTPGM PRODLIB/MYPGM BNDDIR(BLDLIB/MYBNDDIR) BNDSRVPGM(BLDLIB/SRVPGM1 BLDLIB/SRVPGM2)
***Note: If the system
finds that one of the modules for the program wants to call procedure “proc1”,
it will search for that procedure in the modules or service programs listed in
the MODULE, BNDSRVPGM or BNDDIR parameters of the command.
Create Program (CRTPGM)
Type choices, press Enter.
Program . . . . . . . . . . . . > CALLSRVPGM Name
Library . . . . . . . . . . . *CURLIB Name, *CURLIB
Module . . . . . . . . . . . . . *PGM Name, generic*, *PGM, *ALL
Library . . . . . . . . . . . Name, *LIBL, *CURLIB...
+ for more values
Text 'description' . . . . . . . *ENTMODTXT
Additional Parameters
Program entry procedure module *FIRST Name, *FIRST, *ONLY, *PGM
Library . . . . . . . . . . . Name, *LIBL, *CURLIB...
Bind service program . . . . . . *NONE Name, generic*, *NONE, *ALL
Library . . . . . . . . . . . Name, *LIBL
+ for more values
Binding directory . . . . . . . *NONE Name, *NONE
Library . . . . . . . . . . . Name, *LIBL, *CURLIB...
+ for more values
Activation group . . . . . . . . *CALLER Name, *ENTMOD, *NEW, *CALLER