The following example shows how to create a service program CVTTOHEX which converts character strings to their hexadecimal equivalent. Two parameters are passed to the service program:
The field HexString is used to contain the result of the conversion and also to indicate the length of the string to be converted. For example, if a character string of 30 characters is passed, but you are only interested in converting the first ten, you would pass a second parameter of 20 bytes (2 times 10). Based on the length of the passed fields, the service program determines the length to handle.
This shows the source for the service program.This shows the /COPY member containing the prototype for CvtToHex.
The basic logic of the procedure contained within the service program is listed below:
The service program makes use of operational descriptors, which is an ILE construct used when the precise nature of a passed parameter is not known ahead of time, in this case the length. The operational descriptors are created on a call to a procedure when you specify the operation extender (D) on the CALLB operation, or when OPDESC is specified on the prototype.
To use the operational descriptors, the service program must call the ILE bindable API,CEEDOD (Retrieve Operational Descriptor). This API requires certain parameters which must be defined for the CALLB operation. However, it is the last parameter which provides the information needed, namely, the length. For more information on operational descriptors, see “Using Operational Descriptors”.
Source for Service Program CvtToHex
Source for /COPY Member with Prototype for CvtToHex
When designing this service program, it was decided to make use of binder language to determine the interface, so that the program could be more easily updated at a later date. This shows the binder language needed to define the exports of the service program CVTTOHEX. This source is used in the EXPORT, SRCFILE and SRCMBR parameters of the CRTSRVPGM command.
The parameter SIGNATURE on STRPGMEXP identifies the interface that the service program will provide. In this case, the export identified in the binder language is the interface. Any program bound to CVTTOHEX will make use of this signature.
The binder language EXPORT statements identify the exports of the service program. You need one for each procedure whose exports you want to make available to the caller. In this case, the service program contains one module which contains one procedure. Hence, only one EXPORT statement is required.
Creating the Service Program
To create the service program CVTTOHEX, follow these steps:
The last three parameters in the above command identify the exports which the service program will make available. In this case, it is based on the source found in the member CVTTOHEX in the file QSRVSRC in the library MYLIB.
Note that a binding directory is not required here because all modules needed to create the service program have been specified with the MODULE parameter.
The service program CVTTOHEX will be created in the library MYLIB. It can be debugged using a statement view; this is determined by the default DBGVIEW parameter on the CRTRPGMOD command. No binder listing is produced.
Binding to a Program
To complete the example, we will create an ’application’ consisting of a program CVTHEXPGM which is bound to the service program. It uses a seven-character string which it passes to CVTTOHEX twice, once where the value of the hex string is 10 (that is, convert 5 characters) and again where the value is 14, that is, the actual length.
Note that the program CVTHEXPGM serves to show the use of the service program CVTTOHEX. In a real application the caller of CVTTOHEX would have another primary purpose other than testing CVTTOHEX. Furthermore, a service program would normally be used by many other programs, or many times by a few programs; otherwise the overhead of initial call does not justify making it into a service program.
To create the application follow these steps:
CRTRPGMOD MODULE(MYLIB/CVTHEXPGM) SRCFILE(MYLIB/QRPGLESRC)
When CVTHEXPGM is created, it will include information regarding the interface it uses to interact with the service program. This is the same as reflected in the binder language for CVTTOHEX.
During the process of making CVTHEXPGM ready to run, the system verifies that:
If either of the above is not true, then an error message is issued.
The output of CVTHEXPGM is shown below. (The input string is ’ABC123*’.)
C1C2C3F1F2 10 character output
C1C2C3F1F2F35C 14 character output
Source for Test Program CVTHEXPGM
Updating the Service Program
Because of the binder language, the service program could be updated and the program CVTHEXPGM would not have to be re-compiled. For example, there are two ways to add a new procedure to CVTTOHEX, depending on whether the new procedure goes into the existing module or into a new one.
To add a new procedure to an existing module, you would:
To add a new procedure using a new module, you would:
With either method, new programs can access the new function. Since the old exports are in the same order they can still be used by the existing programs. Until it is necessary to also update the existing programs, they do not have to be re-compiled.
For more information on updating service programs, see ILE Concepts.
Sample Binder Listing
This shows a sample binder listing for the CVTHEXPGM. The listing is an example of a basic listing. For more information on binder listings, see “Using a Binder Listing”.
Basic Binder listing for CVTHEXPGM
IBM - RPG Related Interview Questions
|IBM-ILE Interview Questions||IBM Informix Interview Questions|
|IBM DB2 Interview Questions||SQL Database Interview Questions|
|IBM AIX Interview Questions||SQL Interview Questions|
|AS400 Interview Questions||DB2 SQL Programming Interview Questions|
|IBM Integration Bus Interview Questions||Synopsys Interview Questions|
|Rpgle Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.