When best to use: Copybooks, Modules, Service Programs

[Ju5]

When is it best to compile a program as a module and when is it best to compile as Service program?

I know that copybooks, modules and service programs encourage reuseability of code and that copybooks are members that can contain reuseable D-specs and that you don't compile copybooks.

Can you also put procedures and subroutines in copybooks? If you can then what is difference between copybooks and the other two?

When compiling modules I also use CRTPGM because it was instructed on the source code but I never understood why.

 

[tcsbiz]

A module can not be executed directly. A module is bound with other modules to create a program that can be executed directly.

CRTMOD creates modules.
CRTPGM creates an executable program by binding modules together.

If all you have is a stand alone program and take option 14 to compile it, that creates a module and binds it to a program in one step for you. Otherwise it would be a two-step process to compile a stand alone program.

Subroutines can be copy books.

 

[Ju5]

so a module cannot be run using the CALL command from the command prompt? Like a program that needs data created in another program passed to it to run?

How do copybooks work? I know that you need to put /IFDEFINE in the copy book and /DEFINE in the calling program but how does it work?

 

[mikrom]

so a module cannot be run using the CALL command from the command prompt?

No a module cannot be run. If you create in first step a module for example with CRTRPGMOD and if you want to run it, then you need additionaly second step to create a bound program with CRTPGM command. But you can create bound RPG program in one step too: with CRTBNDRPG command.

When is it best to compile a program as a module and when is it best to compile as Service program?

It's so: you need first to create modules with CRTRPGMOD, CRTCBLMOD,... and then you can create a servise program which contains the modules (with CRTSRVPGM command). You can then bind the modules and/or service program into an executable program - look at this thread for more details:

http://www.tek-tips.com/viewthread.cfm?qid=1566433&page=2

Note, that modules and service programs are the features of ILE (Integrated Language Environment) -see ILE Concepts

How do copybooks work?

With copybooks you can include in your source code a piece of another source code at the compile time. For example, you can write a data or procedure definition which you want often to use in your programs once (in a source member) and then include this source member in several other programs as copybook. For more details see this:

http://tutorialindia.com/articles/as400/ile_rpg_iv_copybook_definition.php

 

[PeteJohnston]

Service programs are best used when you have something that needs to be repeated in a lot of different places. For example, your company has a way of calculating product prices with lots of business logic to take account of. Prices that change depending on the order date, quantity order, discount, customer location, tax breaks..... This price calculation will be required in many places. On screen inquiry, order confirmation, invoice print and many more. Instead of coding it again and again, in every program that needs it, you code it Once and call the procedure every time. If the business logic changes you change it in one place and there is no problem forgetting to change a program and getting the wrong numbers in part of your system. It makes life soooo much easier.

Copybooks are the best way to store the prototypes that you have created in your modules. You don't have to re-type the same description (with the chance of getting it wrong) time after time. Just put in the /COPY line and you're good to go.

PeteJ
(Contract Code-monkey)

It's amazing how many ways there are to skin a cat
(apologies to the veggies)

 

[mikrom]

Service programs are best used when you have something that needs to be repeated in a lot of different places...

For that purpose you don't need service program, you can implement the computation in a subprogram and call that subprogramm from all other programs. When the computation logic changed, then you only have to do 1 step: recompile the subprogram with CTRBNDRPG command and that's all. In difference: When you have the computation as a procedure which is part of a service program, then you need 2 steps: recompile the module CRTRPGMOD and update the service program UPDSRVPGM.
I'm using service programs only in that case, when I have to create external SQL UDF (User Defined Function) - it's UDF written in HLL like C, COBOL or RPG and according to IBM convention this must be implemented as a procedure in service program.

 

[Mercury2]

mikrom I don't agree and share Pete's howto.

Philippe

 

[PeteJohnston]

Mikrom, if I understand you correctly you are suggesting stepping back a decade and calling a separate program each time, with all of the associated overhead of opening and closing files, to implement the use of a common function?

Using that technique also loses out on all of the ability to return values, pass parameters by value and many other bits and pieces that is just more difficult when calling a program.

Also, when a module in a service program is changed then the service program must be recreated using CRTSRVPGM. Programs that use procedures in this service program do not need to be recompiled unless the parameter list of any of the procedures has changed. If not it would cause a signature violation error, the *SRVPGM equivalent of a file level check.

You don't need to use a *SRVPGM, you could always go back to using a quill pen


PeteJ
(Contract Code-monkey)

It's amazing how many ways there are to skin a cat
(apologies to the veggies)

 

[mikrom]

PeteJohnston and Mercury2,
I didn't suggest, that service programs are evil and should't be used... They have surely big advantages opposite to subprograms - and as I mentioned I use them self too.

But IMHO for simple case of calling a procedure in different places you can use bound subprogam as well.

And as I wrote, my experience shows me too the disadvatage of using service programs - and that's IMO the increased maintenance effort opposite to simple bound subprograms.

 

[PeteJohnston]

What reads easier to you?

C               Eval    Field1 = 'A'
C               Eval    Field2 = '123'
C               Eval    Field3 = 20
C               Call    'LITTLEPGM'
C               Parm              Field1
C               Parm              Field2
C               Parm              Field3
C               Parm    *Blank    Field4
C               Eval    ResultField = Field4

or

    ResultField = LittleProc( 'A' : '123' : 20 );

As it says on the tin There are many ways to skin a cat and I know that program calls work. I started using that technique in 1988 to encapsulate common functions but things move on. New facilities are made available. RPG has developed so much since then and I can't see the point in not making use of things as they come along.

I used to have two utility CL programs which accepted 6 or 7 parameters, one that handled sending messages to a message subfile and the other that did date validation and reformatting. The date handling is now done with simple RPG %bifs and the other has been replaced with a procedure with the same 6 parameters. The difference is that 5 of the 6 are optional with default values and most of the time all I need is SendMsg( 'ABC1055' ).

We need to move with the times.

PeteJ
(Contract Code-monkey)

It's amazing how many ways there are to skin a cat
(apologies to the veggies)

 

[tcsbiz]

I can go either way on the topic of subprocedures versus subprograms. However, I do very little new development in RPG and do a ton of maintenance programming. I was in program last week that was originaly written in RPGII for a S/34 (ah, the bad old days). I had to deal with 86 indicators for a relatively simple screen program.

I would NEVER return to THAT style of programming. At some point, one does have to move on with technology and use the new capabilities. However, I would never tell someone to never code an old-school program call. They still have their place; 86 indicators do not.

 

[jmanj]

The bad old days??? Today's RPG goes to it's roots in the bad old days.... I have taught RPG (in IBM) since the beginning of S/3 to S/34, S/36 & AS400 but never been the bad old days. Language evolved even with the primitive man and they behold how they went forward. When you write single step programs you can talk about using sub-procedures, when it involve different levels of procedure that is totally different from the original then you can talk about service programs and modules, now when you are developing a whole applications like HR, AR, Inventory, Order entries, now you are talking about copybooks, service program and sub-programs combine.

Nowadays we talk about APIs using java and javascript that is used by either Cobol or RPG, we can now use socket programming to do away with a lot of sub-program and service programs. The $SFGR screen generator that is still being used (from S3 to AS400) becoms forms processing that can be portable to clients. And mind telling you, there is still those bad old days...