Which Control options/H-specs do you use?

In my many years of experience working for various companies I have found that just a few programmers define Control specifications in their RPG programs. The Control specification is commonly known as the Header specification, or H-spec, as in fixed format RPG the specification character, in the sixth position of the line, is 'H'. In all free RPG the Control specification was replaced by the Control options, 'CTL-OPT'.

In my opinion this was the most cryptic of the specifications in RPG III as you had to know what each column stood for, as it would only reveal its meaning when F4 was pressed to prompt the line.

H........1..CDYI....S..............1.F...............................Pgm-id H 1 Y- ERPA01 Prompt type . . . H Sequence number . . . 0000.01 Date Date Invert Alternate Debug Currency Format Edit Print Sequence 1 _ Y - _ _ 1P Forms File Program Position Translation Name _ _ ERPA01

It became easier when RPGLE was introduced as the Control specifications became free format. The equivalent of the above example would be:

HKeywords++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ H DEBUG DFTNAME(ERPA01) DATEDIT(*YMD-)

I do use Control specifications in all my RPG programs. So which ones do I use?

I put the following into all of my programs:

H OPTION(*NODEBUGIO:*SRCSTMT:*NOUNREF) ctl-opt option(*nodebugio:*srcstmt:*nounref) ;

*NODEBUGIO: If this is not given when I start debug (STRDBG) break points are generated for each field in the file. This means if I am stepping through the program I have to press F10 for each field in the file before I proceed to the next statement. By using *NODEBUGIO no break points are generated for the fields, so with one press of the F10 key I advance to the next statement.

*SRCSTMT: The source statement line numbers are used for the line numbers in the generated program or module. Therefore, when I receive an error message about line 223.00 I can go straight to that line number in the source. Without using this option the line numbers are determined sequentially and will not match the source line numbers.

*NOUNREF: The unreferenced fields and variables are not generated, unless they are used by some other module. On the plus side: this makes your program smaller. On the minus side: the unreferenced fields cannot be used in debug.

These are others I do use on a regular basis, just when circumstances need them:

H DFTACTGRP(*NO) ACTGRP(*NEW) BNDDIR('*LIBL/BNDDIRNAME') ctl-opt dftactgrp(*no) actgrp(*new) bnddir('*LIBL/BNDDIRNAME') ;

DFTACTGRP(*NO): The program will be associated with the activation group given in the ACTGRP.

ACTGRP(*NEW): This is only valid when the program is created using the CRTBNDRPG command. I just use *NEW as I am yet to encounter a reason why I need to name the activation group the program will be running in.

BNDDIR('*LIBL/BNDDIRNAME'): If you are binding modules and service programs to other programs then, in my opinion, you should be using a binding directory. I always name mine the same name of the program that will use it.

H NOMAIN ctl-opt nomain ;

NOMAIN: I use this in all of the source code of my modules. It denotes that the code does not have main procedure, and does not use the RPG cycle.

H MAIN(MainPrcedure) ctl-opt main(MainProcedure) ;

MAIN(MainProcedure): In a "linear" program that does not use the RPG cycle this gives the name of the main line procedure. This is something I will discuss in a future post.

H ALWNULL(*INPUTONLY) ctl-opt alwnull(*inputonly) ;

ALWNULL(*USRCTL): At times I do have to work with a file that comes from a different server or database. These tables/files do contain columns/fields that contain nulls. By specifying ALWNULL(*USRCTL) I can read these files without the program erroring as a field contains null, and handle the nulls using the null indicator.

If I use ALWNULL(*INPUTONLY) if a field containing null is encountered in the input operation, READ, CHAIN, etc., it is transformed into the field's default, blank, zero, etc.

 

I would like to hear from you what Control specifications/options you use? And why? Let me know by either posting a comment, below, or use the Contact form on the right and I will include your feedback in this post.

 

You can learn more about the Control specification on the IBM website here.

 

This article was written for IBM i 7.2, and it should work with other releases too.