Topic
  • 4 replies
  • Latest Post - ‏2014-06-02T07:28:30Z by 107D_Dieter_Schröder
107D_Dieter_Schröder
5 Posts

Pinned topic compile strategy

‏2014-05-30T11:52:28Z |

Hello,

my name ist Dieter and i come from Germany. Please excuse my poor English. I am developing in RPG for more than 20 years. I have spoken with many programmers and consultants about compiling RPG programs. Till this day i did not find a good solution for the following:

RPG service programs need to be compiled in an other way than "normal" RPG programs. In PDM you would take "14" to compile a normal program and you would use "15" to create a module of a service program. After creating the module you have to create the service program from the module. And you have to specify a lot of compile and binding options.

I think most programmers don't want to do these steps manually with PDM. I think most programmers have scripts for compiling. But the compile script has to know whether a source is a normal program or whether it is a service program. But there is no attribute for this. The source has an attribute "RPGLE" or "SQLRPGLE" but no attribute "SRVPGM". We solved this problem by beginning the source member text with "srv:" But this is only a poor vehicle. What is the suggestion from IBM? What does IBM think the programmers should do to compile programs by scripts? I have seen solutions where precompiler commands were placed in the comment area of a program header. Then a self written precompiler interprets this codes and generates a compile script. Other programmers use 3 party products (change management systems). I am wondering why IBM does not provide a good solution for those who don't want to rely on a 3 party change management system. And it is not efficient if every programmer writes his own precompiler for compiling and binding.

Maybe i have overlooked a solution?

Dieter

  • tuohyp
    tuohyp
    4 Posts

    Re: compile strategy

    ‏2014-05-30T13:00:28Z  

    Hi Dieter,

    You might find some food for thought in this article I wrote on Development Environments - http://www.itjungle.com/fhg/fhg051210-printer01.html

    HTH

    Paul

  • 107D_Dieter_Schröder
    5 Posts

    Re: compile strategy

    ‏2014-05-30T14:10:39Z  

    Hi Paul,

    thank you for your answer. Your link seems to be very helpful. I will discuss your article with my colleagues next monday. 

    Dieter

  • B.Hauser
    B.Hauser
    71 Posts

    Re: compile strategy

    ‏2014-06-01T17:00:51Z  

    Hi Paul,

    thank you for your answer. Your link seems to be very helpful. I will discuss your article with my colleagues next monday. 

    Dieter

    Dieter,

    you may contact me directly, because it is easier to explain it in German.

    We have the following strategie:

    1 Member = 1 Program or 1 Service Program

    The members for the service programs can consist of multiple (exported) procedures.

    The procedures are grouped depending on their functionality, for examples all date/time functions, all string furnctions, all check functions for the custormer no, all chain/read functions for a specific table etc.

    Almost all procedures are exported, internal procedures are the exception (for example for initializing global variables).

    All members that have to be compiled/bound to service programs are saved within the source file QSRVPGMSRC. All members that are compiled into programs are saved in the source file QPGMLESRC.

    All service programs  are registered within a single binder directory.

    We have a tool, i.e. a single CL command that allows to compile any of these sources to either a program or service program. It automatically creates the modules, binds the modules to either a program or service program, registers the service program in the binder directory, generates the binder language.

    The only requirement for this tool is, new procedures have to be added at the end of the source member. And one member = one program or one service program.

    Birgitta

  • 107D_Dieter_Schröder
    5 Posts

    Re: compile strategy

    ‏2014-06-02T07:28:30Z  
    • B.Hauser
    • ‏2014-06-01T17:00:51Z

    Dieter,

    you may contact me directly, because it is easier to explain it in German.

    We have the following strategie:

    1 Member = 1 Program or 1 Service Program

    The members for the service programs can consist of multiple (exported) procedures.

    The procedures are grouped depending on their functionality, for examples all date/time functions, all string furnctions, all check functions for the custormer no, all chain/read functions for a specific table etc.

    Almost all procedures are exported, internal procedures are the exception (for example for initializing global variables).

    All members that have to be compiled/bound to service programs are saved within the source file QSRVPGMSRC. All members that are compiled into programs are saved in the source file QPGMLESRC.

    All service programs  are registered within a single binder directory.

    We have a tool, i.e. a single CL command that allows to compile any of these sources to either a program or service program. It automatically creates the modules, binds the modules to either a program or service program, registers the service program in the binder directory, generates the binder language.

    The only requirement for this tool is, new procedures have to be added at the end of the source member. And one member = one program or one service program.

    Birgitta

    Hi Birgitta,

    thank you for your answer. Your idea to store program sources and serviceprogram sources in different sourcefiles is an interesting solution. It seems to be that every programmer has his own strategy for managing and compiling sources. There is no solution which is recommended by IBM.

    I think we will meet in German forums.

    Thank you,

    Dieter

     

     

    Updated on 2014-06-02T07:28:56Z at 2014-06-02T07:28:56Z by 107D_Dieter_Schröder