It's all about the answers!

Ask a question

Best Practice building RPG service programs in RTC


Mihael Schmidt (5154) | asked Mar 03 '11, 2:58 a.m.
We are just trying to start with RTC and are wondering what the best practices for building service programs are.

The mail list tutorial declared an extra build program for each service program. This is not very feasible for us as we have many service programs and 99% have a fixed logic for building:

1 service program is built with 1 module with binder source where the binder source member has the same name as the service program. The service program has the same name as the module with as _SV suffix.

Module: ORDER
Binder Source: ORDER___SV
Service Program: ORDER___SV

Is there some way to make ONE general build program?

Or what is the best way to build service programs?

Thanx in advance

Mihael

2 answers



permanent link
Sean Babineau (38825) | answered Mar 08 '11, 10:25 a.m.
JAZZ DEVELOPER
We are just trying to start with RTC and are wondering what the best practices for building service programs are.

The mail list tutorial declared an extra build program for each service program. This is not very feasible for us as we have many service programs and 99% have a fixed logic for building:

1 service program is built with 1 module with binder source where the binder source member has the same name as the service program. The service program has the same name as the module with as _SV suffix.

Module: ORDER
Binder Source: ORDER___SV
Service Program: ORDER___SV

Is there some way to make ONE general build program?

Or what is the best way to build service programs?

Thanx in advance

Mihael



I think that usually, SRVPGMs are going to be multi-module and thus will require their own builders to specify their own modules.

The Builder can have multiple inputs (source members or objects), and one of these inputs can be iterative (type: to be processed one at a time). This means the associated command set will be called iteratively for each member/object found matching the iterative input's include-exclude filters, and for each of these calls, it will assign the values of &L, &N (and &F if this is a source member) which may be specified as substitute variables in the command set.

So, if you have a way to specify an iterative input to isolate the *MODULE objects for your SRVPGMs, you may be able to have a single builder with a command set something like "CRTSRVPGM SRVPGM(*CURLIB/&N__SV) MODULE(&N) SRCFILE(*LIBL/QSRVSRC) SRCMBR(&N__SV)"

If you want to iterate on the Binding source members, I think you might need to rename the binding source members to remove the __SV suffix, since there's no way in the Builder or Commandset to assign a substring of a variable.

Failing that, the command set can include any native commands (or calls to native programs), so you could create a little delegate CL program, e.g. CRTMYSPGM, which takes parameters for the (iterated) binding source name, computes the substring for the module name, and calls CRTSRVPGM with the derived parameter values). Then change the SRVPGM Command set to call your delegate program, and specify a single Builder to create all your single-module srvpgms through this Command set and delegate program.

-Sean-

permanent link
Mihael Schmidt (5154) | answered Mar 08 '11, 11:53 a.m.

I think that usually, SRVPGMs are going to be multi-module and thus will require their own builders to specify their own modules.


In our case 99% of the service programs are created from just one module. So a single specification for the building of service programs would really help.

Thanx for your response

Mihael

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.