Filter
Top Products
Changing a Module or Program
Note: In the remainder of this section the term 'object' will be used to refer to
either an ILE module or ILE program.
Using the UPDPGM Command
In general, you can update a program by replacing modules as needed. For
example, if you add a new procedure to a module, you recompile the module
object, and then update the program. You do not have to re-create the program.
This is helpful if you are supplying an application to other sites. You need only send
the revised modules, and the receiving site can update the application using the
UPDPGM or UPDSRVPGM command.
The UPDPGM command works with both program and module objects. The param-
eters on the command are very similar to those on the CRTPGM command. For
example, to replace a module in a program, you would enter the module name for
MODULE parameter and the library name. The UPDPGM command requires that
the modules to be replaced be in the same libraries as when the program was
created. You can specify that all modules are to be replaced, or some subset.
The UPDPGM command requires that the module object be present. Thus, it is
easier to use the command when you have created the program using separate
compile and bind steps. Since the module object already exists, you simply specify
its name and library when issuing the command.
To update a program created by CRTBNDRPG command, you must ensure that
the revised module is in the library QTEMP. This is because the temporary module
used when the CRTBNDRPG command was issued, was created in QTEMP. Once
the module is in QTEMP, you can issue the UPDPGM command to replace the
module.
For more information, see
ILE Concepts
and the
CL Reference (Abridged)
.
Changing the Optimization Level
Optimizing an object means looking at the compiled code, determining what can
be done to make the run-time performance as fast as possible, and making the
necessary changes. In general, the higher the optimizing request, the longer it
takes to create an object. At run time the highly optimized program or service
program should run faster than the corresponding nonoptimized program or service
program.
However, at higher levels of optimization, the values of fields may not be accurate
when displayed in a debug session, or after recovery from exception. In addition,
optimized code may have altered breakpoints and step locations used by the
source debugger, since the optimization changes may rearrange or eliminate some
statements.
To ensure that the contents of a field reflect their most current value, especially
after exception recovery, you can use the NOOPT keyword on the corresponding
Definition specification. For more information, see “Optimization Considerations” on
page 226.
To circumvent this problem while debugging, you can lower the optimization level of
a module to display fields accurately as you debug a program, and then raise the
Chapter 7. Creating a Program with the CRTRPGMOD and CRTPGM Commands 87