13
Fri, Dec
4 New Articles

An Introduction to ILE RPG: Part 1

RPG
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Brief: Early last year, IBM officially announced the Integrated Language Environment (ILE) and plans for a new generation of AS/400 languages. Even before the ILE announcement, the RPG programming community was aware of major changes being considered by IBM's language developers. Now, a new RPG language is close to completion in IBM's Toronto laboratory with a projected delivery date during the third quarter of 1994. Starting with this article, Midrange Computing will present a comprehensive tutorial on the new features and functions that define ILE RPG. This month's article provides an overview of the changes that pervade the new language and an in-depth look at changes to Control and File description specifications.

Since the announcement of the AS/400, we have seen many significant enhancements made to RPG/400, including the addition of string-handling capabilities, a number of new structured operation codes, named and hexadecimal constants, read with no update, and more.

Despite these enhancements, RPG/400 still has its critics. Six-character field names can result in cryptic, difficult-to-understand abbreviations. Complex formulas are difficult at best to code with a single operation per Calculation specification. Other criticisms abound.

We are about to see enhancements which will make RPG/400 seem as archaic and difficult to use as RPG II may now seem to experienced RPG/400 programmers. The programming language that will deliver these enhancements is Integrated Language Environment RPG (ILE RPG). ILE RPG should be announced as part of V3R1M0 of OS/400. You may also hear ILE RPG referred to as RPG IV or NPM (New Program Model) RPG.

An important benefit of the new ILE program model is the ability to bind programs. Binding programs means compiling programs separately as nonexecutable modules which can be combined (bound together) to form a single, executable program object. This facilitates modularity and makes it possible to create reusable components without the performance penalty of external program calls.

Calls to a program which is bound to the calling program can execute with the speed of a subroutine. You no longer have to code the same subroutine in multiple programs because you are afraid of the performance hit associated with calling an external program. Programs written in one language can call programs written in a different language with consistent operation and error handling. A common source-level debugger will service all ILE languages. Resources can be better controlled by partitioning a job into activation groups and controlling file opens, file sharing and program loads within an activation group.

All of these benefits are part of the underlying ILE enhancements included in V2R3M0. They will be available for each new ILE language as it is released. ILE C/400 is the first ILE language and was introduced in V2R3M0.

In addition to all of the ILE benefits, the RPG language itself has been substantially enhanced. It will take some time and perhaps some education to become as comfortable with the new ILE RPG as you now are with RPG II, RPG III or RPG/400. "Why?" you ask.

Do you use arrays? Guess what? Arrays and tables still exist, but there are no Extension specifications (E-specs) in ILE RPG! For that matter, there are no longer any Line Counter specifications (L-specs) either. Do you think you know the external file input/output operation codes? The DELET, UPDAT, UNLCK and REDPE operation codes no longer work. They've been changed to DELETE, UPDATE, UNLOCK and READPE. And if you're a real long-time expert, remember the D specification from System/3 RPG? Well, as we'll see, it doesn't mean dump in ILE RPG!

Even with these changes, there's no need to worry. An RPG/400-to-ILE RPG source conversion utility will be provided. This utility should completely automate conversion unless you use /COPY in RPG/400 or Auto Report. (More about this in a later article.)

All you really need is a little education. This series of articles provides some concentrated education about ILE RPG to make you comfortable with the new language. While the ILE RPG language definition is still subject to change, any changes made subsequent to the writing of this article will probably be minor.

At first glance, ILE RPG might seem very different from the current version of RPG/400. However, very shortly you'll understand why the changes were made and learn how the new ILE RPG will make programming easier and more efficient.

General Changes

o One of the most frequent complaints about RPG is its six-character limit for field names. ILE RPG now supports 10-character file, format, field, constant, data structure, key list, subroutine, label and other symbolic names. ILE RPG has generated some criticism because it only supports 10-character field names, while OS/400 supports longer field names. In fact, DDS directly supports only 10-character field names. Longer field names are supported only through the ALIAS keyword. For example, when defining DDS for a file, the field name

EMP_NUM might have an ALIAS of EMPLOYEE_NUMBER. While ILE RPG will not support alias field names, it will support native field names for any file on the AS/400.

o The underscore (_) is now valid in a symbolic name but cannot be the first character. EMP_NAME is a valid field name, but _NAME is not.

o Array subscripts are specified using parentheses instead of a comma. ARR,X in RPG/400 becomes ARR(X) in ILE RPG.

o Upper- and lowercase characters can be used anywhere in an ILE RPG program. The field names EmpName and location are now valid. The operation codes CHAIN, Chain, and chain all perform the same function. The use of lowercase is optional.

The compiler will translate all source-with a few exceptions-from lowercase characters ("a" to "z") to uppercase characters. Comments, literals (with the exception of hexadecimal literals) and compile-time array and table data will not be translated. Also not translated are: the currency symbol, date and time edit values on the Control specification (H-spec), date and time separator characters on Input specifications (I-specs) (we'll address separator characters in a later article), and comparison characters on Record Identification entries on I-specs.

Hexadecimal literals will be translated, so coding x'f0' is the same as coding X'F0'. Compile listings will show upper- and lowercase as entered by the user. The cross-reference listing will appear in uppercase only.

o The maximum length of named constants has increased from 256 to 1,024 characters. Numeric variables will now support up to 30 decimal positions, up from 9. The field length of character variables has also increased, in answer to criticism of RPG/400's 256-character limitation. Character variables and array elements can now be up to 32,767 characters in length.

o Other limits have also been in-creased. The maximum record length of a program-described file has been increased from 9,999 bytes to 99,999 bytes. Externally described files can have even larger record lengths. The number of elements in a table or array has been increased from 9,999 to 32,767. The maximum length of a single-occurrence data structure has changed from 9,999 to 9,999,999 while the maximum number of occurrences in a multiple-occurrence data structure has changed from 9,999 to 32,767. Finally, the length of compile-time table and array data has increased from 80 to 100 characters.

o Some limits have been virtually eliminated. In RPG/400, the number of files is limited to 50. The maximum number of arrays is 200. And, believe it or not, there is a maximum program size. In ILE RPG, there are no practical limits for these values.

1 summarizes changes to limits.

Figure 1 summarizes changes to limits.

o Source statements which are blankin positions 6 to 80 will be treated as comments. An asterisk (*) in position 7 will also force a statement to be a comment just as it does in RPG/400. In general, positions 81 to 100 are treated as comments in source statements except for compile-time table and array data defined as longer than 80 characters.

o The default source file name has changed from QRPGSRC to QRPGLESRC and the record length has expanded from 92 to 112 bytes. The existing six-character date and SEU sequence-number fields remain unchanged. The increase of the source statement length from 80 to 100 characters will accommodate the longer file and field names as well as the comments in positions 81 to 100.

Having reviewed general changes which affect all specifications in ILE RPG, we now can take a look at the details. In the balance of this article, we will address the H-specs and File description specifications (F-specs). The next article will address the new Data specification (D-spec) and built-in functions. Future articles will round up our review with Input, Calculation, and Output specifications (I-specs, C-specs and O-specs) together with expressions, new operation codes and date manipulation.

Control Specifications (H-specs)

A quick look at an H-spec (2) introduces ILE RPG keyword notation which you'll see repeatedly as we cover each specification type. The keyword notation used in ILE RPG is very similar to the keyword notation found in CL.

A quick look at an H-spec (Figure 2) introduces ILE RPG keyword notation which you'll see repeatedly as we cover each specification type. The keyword notation used in ILE RPG is very similar to the keyword notation found in CL.

For example, instead of specifying a D in position 15 of the H-spec, the keyword DEBUG is now used to enable DEBUG and DUMP operations. The use of DEBUG or DEBUG(*YES) enables DEBUG and DUMP operations. Not specifying the DEBUG keyword at all or specifying DEBUG(*NO) disables DEBUG and DUMP operations.

The currency symbol in position 18 is now specified using the CURSYM keyword with a single character enclosed in quotes. If CURSYM is not specified, the currency symbol defaults to '$'.

The date format and date edit in positions 19 and 20 are replaced with the DATEDIT keyword to specify the order of month, day and year of UDATE and *DATE as well as the separator character for the Y edit-code. *MDY, *DMY and *YMD formats can be specified.

An optional separator character may be specified for *DMY, *YMD and *MDY format dates. The separator character is added to the date format. For example, specifying DATEDIT(*MDY.) causes dates to appear as MM.DD.YY when the Y edit- code is used.

The DECEDIT keyword replaces the decimal notation in position 21.

Alternate collating sequence is now specified with the ALTSEQ keyword instead of an A in position 26.

The FORMSALIGN parameter replaces the 1 in position 41 to request first-page forms alignment. FORMSALIGN and FORMSALIGN(*YES) enable first-page forms alignment. Not specifying the FORMSALIGN keyword, or specifying FORMSALIGN(*NO), disables first-page forms alignment.

A file translation table is indicated using the FTRANS keyword instead of the 'F' in position 43.

The transparency (graphic) check in position 57 is no longer required.

The default program name is now specified using the DFTNAME keyword instead of using positions 75 to 80. If DFTNAME is not specified or if the specified name is invalid, RPGOBJ will be used as the default program name. At compile time, a program name is normally specified as the same name as the source member, so DFTNAME does not need to be specified in most cases.

The DATFMT keyword is used to indicate the format and separator for date literals which are required to support the new date and timestamp data types. (Date, time and timestamp data types and operations will be described in a later article.) *MDY, *DMY and *YMD support the traditional, eight-character MM/DD/YY, DD/MM/YY and YY/MM/DD date formats. A number of other formats are also supported.

The TIMFMT keyword is used to indicate the format and separator for time literals which are used to support the new time and timestamp data types. 3 summarizes the changes in the H-spec.

The TIMFMT keyword is used to indicate the format and separator for time literals which are used to support the new time and timestamp data types. Figure 3 summarizes the changes in the H-spec.

What's in the future for H-specs? It is easy to see that the new keyword notation has eliminated any format or length restrictions since multiple lines of specifications can be used.

What about compile options? Aren't they specified in keyword notation on the compile commands? Wouldn't it be nice to include compile options in the source and never again have to prompt and change parameters on a compile command? Perhaps we'll see this capability in a later release of ILE RPG.

File Description Specifications (F-specs)

A simple F-spec sample in 4 shows further use of keyword notation in ILE RPG. The file information data structure DSMBID is now defined as a parameter of the INFDS keyword: INFDS(DSMBID)

A simple F-spec sample in Figure 4 shows further use of keyword notation in ILE RPG. The file information data structure DSMBID is now defined as a parameter of the INFDS keyword: INFDS(DSMBID)

In a similar manner, the information subroutine SUBRER is now specified as a parameter on the INFSR keyword: INFSR(SUBRER)

The rename of a record format is a two-part parameter of the RENAME keyword: RENAME(COPMB1:COLMBID1)

The F-spec in ILE RPG has been modified to accommodate expanded lengths. For example, the eight-character file name in positions 7 to 14 has been expanded to 10 characters in positions 7 to 16. The four-character record length in positions 24 to 27 has been expanded to five characters in positions 23 to 27. And the two-character key length in positions 29 to 30 has been expanded to five characters in positions 29 to 33. There are many other changes of this type. 5 summarizes all the F-spec changes.

The F-spec in ILE RPG has been modified to accommodate expanded lengths. For example, the eight-character file name in positions 7 to 14 has been expanded to 10 characters in positions 7 to 16. The four-character record length in positions 24 to 27 has been expanded to five characters in positions 23 to 27. And the two-character key length in positions 29 to 30 has been expanded to five characters in positions 29 to 33. There are many other changes of this type. Figure 5 summarizes all the F-spec changes.

Date, time and timestamp keys are now supported by specifying a D, T or Z. These key formats are indicated using the DATFMT and TIMFMT keywords in F-specs with values similar to those that can be specified in the DATFMT and TIMFMT keywords in the H-specs.

The USROPN and EXTIND keywords shown in 6 are now used to condition the opening of files. The UC in positions 71 to 72 has been changed to the USROPN keyword for the file COLMBDS. The U8 external indicator for COLMBID has been changed to EXTIND(U8). You specify that a file allows additions with an A in position 20 rather than position 66. This will probably take a while to get used to!

The USROPN and EXTIND keywords shown in Figure 6 are now used to condition the opening of files. The UC in positions 71 to 72 has been changed to the USROPN keyword for the file COLMBDS. The U8 external indicator for COLMBID has been changed to EXTIND(U8). You specify that a file allows additions with an A in position 20 rather than position 66. This will probably take a while to get used to!

Prefix Keyword

One of the most significant F-spec enhancements involves the use of the same record format multiple times in a program. In ILE RPG, as in RPG/400, if you want to use a physical file and a logical file based on the physical file in the same program, you have to rename the record format of one of the files. However, in RPG/400, if you want to read a record from the physical file and then read a record from the logical file without altering the values of the fields from the physical file, you have to rename the fields in the I-specs. This is no longer true in ILE RPG.

In our sample in 7, we have renamed the record format COPMB1 to COLMBID1 for the file COLMBID in both RPG/400 and ILE RPG. But we only changed the fields MBDELT to M2DELT, MBID to M2ID, and MBNAME to M2NAME in the RPG/400 sample. Instead of having to individually list each field in the file, ILE RPG now supports the PREFIX keyword to perform a global field rename function. By specifying PREFIX(M2_), we have implicitly renamed MBDELT to M2_MBDELT, MBID to M2_MBID and MBNAME to M2_MBNAME.

In our sample in Figure 7, we have renamed the record format COPMB1 to COLMBID1 for the file COLMBID in both RPG/400 and ILE RPG. But we only changed the fields MBDELT to M2DELT, MBID to M2ID, and MBNAME to M2NAME in the RPG/400 sample. Instead of having to individually list each field in the file, ILE RPG now supports the PREFIX keyword to perform a global field rename function. By specifying PREFIX(M2_), we have implicitly renamed MBDELT to M2_MBDELT, MBID to M2_MBID and MBNAME to M2_MBNAME.

Fields that are explicitly re-named on I-specs are not affected by the PREFIX keyword. Also, if the addition of the prefix to the field name results in a field name which exceeds 10 characters, a compile error will occur.

Not only will the PREFIX global rename capability save a tremendous amount of coding time, it will also eliminate the need to check your programs when you add a field to a file. The added field will automatically be prefixed (e.g., M2_NEWFLD) when the program is recompiled. Nice job, IBM!

Selecting Record Formats

The IGNORE keyword can be used to ignore a record format from an externally defined file in both RPG/400 and ILE RPG. Each format to be ignored must be specified in RPG/400. Our sample in 8 shows formats FORMAT2, FORMAT3 and FORMAT4 being ignored. In addition to the IGNORE keyword in ILE RPG, an INCLUDE keyword is also provided. Any record format not specified using the INCLUDE keyword is ignored. If you do not specify INCLUDE or IGNORE, all records formats will be included. In our ILE RPG sample, we included FORMAT1 instead of explicitly ignoring FORMAT2, FORMAT3 and FORMAT4.

The IGNORE keyword can be used to ignore a record format from an externally defined file in both RPG/400 and ILE RPG. Each format to be ignored must be specified in RPG/400. Our sample in Figure 8 shows formats FORMAT2, FORMAT3 and FORMAT4 being ignored. In addition to the IGNORE keyword in ILE RPG, an INCLUDE keyword is also provided. Any record format not specified using the INCLUDE keyword is ignored. If you do not specify INCLUDE or IGNORE, all records formats will be included. In our ILE RPG sample, we included FORMAT1 instead of explicitly ignoring FORMAT2, FORMAT3 and FORMAT4.

Commitment Control

The COMIT keyword in RPG/400 has been changed to COMMIT in ILE RPG. Commitment- control processing has been substantially enhanced through the ability to specify a single-character field as a parameter on the COMMIT keyword to condition the use of commitment control. If the field contains a 1, the file will be opened with commitment control. Otherwise, the file will be opened without commitment control. The field value must be set prior to opening the file and can be passed as an *ENTRY parameter. If the file is shared and is already open, this keyword has no effect.

In the commitment-control sample in 9, the file COLMBID is always opened under commitment control in RPG/400. The field C_COLMBID is implicitly defined as a one-byte character field in the ILE RPG sample. If passed as an *ENTRY parameter with a value of '1', the file COLMBID is opened under commitment control. Otherwise, the file COLMBID will be opened but commitment control will not be used. For files opened under user control, the value of C_COLMBID could be set in the RPG program prior to opening the file.

In the commitment-control sample in Figure 9, the file COLMBID is always opened under commitment control in RPG/400. The field C_COLMBID is implicitly defined as a one-byte character field in the ILE RPG sample. If passed as an *ENTRY parameter with a value of '1', the file COLMBID is opened under commitment control. Otherwise, the file COLMBID will be opened but commitment control will not be used. For files opened under user control, the value of C_COLMBID could be set in the RPG program prior to opening the file.

ADDROUT Files

Since E-specs have been eliminated, coding ADDROUT files in ILE RPG has changed. The ADDROUT file record length which was coded in positions 24 to 27 is now coded in positions 23 to 27. The key length has been moved from positions 29 to 30 and expanded to five characters in positions 29 to 33. The T representing file organization in position 32 has been moved to position 35. The TOFILE keyword replaces the E-spec. In our sample in 10, TOFILE(OS6MASTR) relates the file ADDROUT to the file OS6MASTR.

Since E-specs have been eliminated, coding ADDROUT files in ILE RPG has changed. The ADDROUT file record length which was coded in positions 24 to 27 is now coded in positions 23 to 27. The key length has been moved from positions 29 to 30 and expanded to five characters in positions 29 to 33. The T representing file organization in position 32 has been moved to position 35. The TOFILE keyword replaces the E-spec. In our sample in Figure 10, TOFILE(OS6MASTR) relates the file ADDROUT to the file OS6MASTR.

Line Counter Functions

The L-spec has also been eliminated from ILE RPG and its function has been moved to F-specs using the FORMLEN and FORMOFL keywords. In the sample in 11, the overflow indicator is now coded using OFLIND(OF). The forms length of 51 lines and overflow line number of 44, both of which used to be coded in the L-spec, are coded in the F-spec using FORMLEN(51) and FORMOFL(44).

The L-spec has also been eliminated from ILE RPG and its function has been moved to F-specs using the FORMLEN and FORMOFL keywords. In the sample in Figure 11, the overflow indicator is now coded using OFLIND(OF). The forms length of 51 lines and overflow line number of 44, both of which used to be coded in the L-spec, are coded in the F-spec using FORMLEN(51) and FORMOFL(44).

The PRTCTL keyword is still used to define a data structure to access the current line value and dynamically control a program-described printer file, but it has been expanded to accommodate longer fields. Instead of coding skip and space before and after in Output specifications (O-specs), these values can be set in a PRTCTL data structure. Specifying PRTCTL(DSname:*COMPAT) will retain the RPG/400 definitions. Not specifying *COMPAT will change the format of PRTCTL as summarized in 12.

The PRTCTL keyword is still used to define a data structure to access the current line value and dynamically control a program-described printer file, but it has been expanded to accommodate longer fields. Instead of coding skip and space before and after in Output specifications (O-specs), these values can be set in a PRTCTL data structure. Specifying PRTCTL(DSname:*COMPAT) will retain the RPG/400 definitions. Not specifying *COMPAT will change the format of PRTCTL as summarized in Figure 12.

Other File Continuation Keywords

The PGMNAME keyword specifies the name of the program which gets control for a SPECIAL file. The PLIST keyword is still used to specify a parameter list for the program to handle a SPECIAL file.

Changes have also been made to other file continuation keywords. The ID keyword that defines a field to contain the name of the program device has been changed to DEVID. Saved indicators are now specified using the new SAVEIND keyword instead of the old IND keyword. The SAVDS (save data structure) keyword has been changed to SAVEDS.

The NUM parameter used to specify the maximum number of acquired devices for a WORKSTN file has been changed to MAXDEV and has been substantially enhanced. Instead of having to recompile the program to increase the maximum number of acquired devices, MAXDEV(*FILE) can be specified to cause this value to be taken from the display file at run time. In this case, SAVEDS and SAVEIND space allocation take place at run time. MAXDEV(*ONLY) is the default which indicates a single device file. The actual number of devices can no longer be specified- only *FILE and *ONLY are valid.

Some keywords remain the same. The PASS keyword used to control passing of indicators to data management, the RECNO keyword used to specify a relative record number for files processed by relative record number and the SLN keyword used to specify a starting line number for a WORKSTN file are all unchanged.

What's Next?

As you can see, numerous modifications were required just to handle the change from six-character to 10-character symbolic names. Introducing keyword notation has not only freed up space to accommodate longer fields in F-specs, it has also made the coding of H- and F-specs much easier for us and much easier for IBM to enhance in the future.

As you'll see in the remaining articles in this series, the changes to accommodate longer names are minor compared to other changes in ILE RPG. In our next article, we will tackle I-specs and the newly reincarnated D-specs.

Charlie Massoglia is president of Massoglia Technical Consulting, Inc. in Okemos, Michigan. Author of a number of midrange books, Charlie is a frequent speaker throughout the United States, Canada, Europe and Australia.


An Introduction to ILE RPG: Part 1

Figure 1 Changes to Limits

 
  Description of Changed Limit       RPG/400 Limit      ILE RPG Limit 
 
  Field name                               6                  10 
 
  Table and array name                     6                  10 
 
  File name                                8                  10 
 
  File record format name                  8                  10 
 
  Valid characters in          A-Z, 0-9, $, # and @  A-Z, 0-9, $, #, @ and _ 
  symbolic name 
  (First character may not be 0-9 or _) 
 
  Use of upper- and lowercase         Uppercase      Upper- and lowercase 
 
  Length of character field and array    256              32,767 
  element 
 
  Length of named constants              256               1,024 
 
  Number of decimal positions              9                  30 
 
  Number of files                         50           No practical limit 
 
  Number of arrays                       200           No practical limit 
 
  Program size                          Varies         No practical limit 
 
  Program-described file record        9,999              99,999 
  length 
 
  Number of elements in table or       9,999              32,767 
  array 
 
  Length of single-occurrence data     9,999           9,999,999 
  structure 
 
  Number of occurrences in a           9,999              32,767 
  multiple-occurrence data structure 
 
  Length of compile-time table and        80                 100 
  array data 

An Introduction to ILE RPG: Part 1

Figure 2 H-spec Sample Code

 
  RPG/400 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  H........1..CDYI....S..............1.F...............................Pgm-id 
  H        D  $M D    A              1 F 
 
 
  ILE RPG 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  HFunctions+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++Comm 
  ents++++++++++++ 
  H DEBUG(*YES)  CURSYM('$')  DATEDIT(*MDY)  DECEDIT('.') 
  H ALTSEQ(*SRC)  FORMSALIGN(*YES)  FTRANS(*SRC)  DFTNAME(name) 
  H                 DATFMT(*MDY/)  TIMFMT(*ISO) 

An Introduction to ILE RPG: Part 1

Figure 3 Changes to H-specs

 
 
  RPG/400       SEU Format                                         ILE RPG 
  Position      Abbreviation         Explanation                   Keyword 
 
  15               1                Debug and Dump                 DEBUG 
  18               C                Currency Symbol                CURSYM 
  19               D                Date Format                    DATEDIT 
  20               Y                UDATE Edit                     DATEDIT 
  21               I                Decimal Notation               DECEDIT 
  New                               Date Literals Format           DATFMT 
  New                               Time Literals Format           TIMFMT 
  26               S                Alternate Collating Sequence   ALTSEQ 
  41               1                First-page Forms Alignment     FORMSALIGN 
  43               F                File Translation               FTRANS 
  57                                Transparency Check             No longer 
                                                                   needed 
  75-80         Pgm-id              Default Program Name           DFTNAME 

An Introduction to ILE RPG: Part 1

Figure 4 INFDS, INFSR and RENAME

 
  RPG/400 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilenameIPEAF....RlenLK1AIOvKlocEDevice+......KExit++Entry+A....U1....... 
  FCOLMBID UF  E           K        DISK         KINFDS DSMBID 
  F............Ext-recfmt..................Recno+KOptionEntry+............... 
  F                                              KINFSR SUBRER 
  F            COPMB1                            KRENAMECOLMBID1 
 
  ILE RPG 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilename++IPEASFRlen+LKlen+AIDevice+.File 
  continuation++++++++++++++++++++Comments++++++++++++ 
  FCOLMBID   UF   E           K DISK    INFDS(DSMBID) INFSR(SUBRER) 
  F                                     RENAME(COPMB1:COLMBID1) 

An Introduction to ILE RPG: Part 1

Figure 5 Changes to F-specs

 
 
     RPG/400      ILE RPG      SEU Format                         New 
     Position     Position     Abbreviation      Explanation      Keyword 
 
        7-14      7-16         Filename          File name 
        15        17           I                 File type 
        16        18           P                 File designation 
        17        19           E                 End of file control 
        18        21           A                 Match field sequence 
        19        22           F                 File format 
        24-27     23-27        Rlen              Record length 
        28        28           L                 Limits processing 
        29-30     29-33        K1                Key field length 
        31        34           A                 Record address type 
        32        35           I                 File organization 
        33-34     Keyword      Ov                Overflow indicator      OFLIND 
        35-38     Keyword      Kloc              Key field               KEYLOC 
                                                 starting location 
        39        Keyword      E                 Extension code          TOFILE 
                                                                         FORMLEN 
                                                                         FORMOFL 
        40-46     36-42        Device            Device type 
        53-65     44-80        KExit++Entry+     File continuation keywords 
        66        20           A                 File addition 
        71-72     Keyword      U1                File condition          EXTIND 
                                                                         USROPN 
        75-80     81-100       Comments          Comments 

An Introduction to ILE RPG: Part 1

Figure 6 USROPN and EXTIND

 
  RPG/400 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilenameIPEAF....RlenLK1AIOvKlocEDevice+......KExit++Entry+A....U1....... 
  FCOLMBDS IF  E           K        DISK                           UC 
  FCOLMBID UF  E           K        DISK                      A    U8 
 
  ILE RPG 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilename++IPEASFRlen+LKlen+AIDevice+.File 
  continuation++++++++++++++++++++Comments++++++++++++ 
  FCOLMBDS   IF   E           K DISK    USROPN 
  FCOLMBID   UF A E           K DISK    EXTIND(U8) 

An Introduction to ILE RPG: Part 1

Figure 7 RENAME and PREFIX

 
  RPG/400 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilenameIPEAF....RlenLK1AIOvKlocEDevice+......KExit++Entry+A....U1....... 
  FCOPMB   UF  E           K        DISK 
  FCOLMBID IF  E           K        DISK 
  F............Ext-recfmt..................Recno+KOptionEntry+............... 
  F            COPMB1                            KRENAMECOLMBID1 
 
  IFilenameSqNORiPos1NCCPos2NCCPos3NCC....................................... 
  ICOLMBID 
  I..............Ext-field+......................Field+L1M1..PlMnZr.......... 
  I              MBDELT                          M2DELT 
  I              MBID                            M2ID 
  I              MBNAME                          M2NAME 
 
  ILE RPG 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilename++IPEASFRlen+LKlen+AIDevice+.File 
  continuation++++++++++++++++++++Comments++++++++++++ 
  FCOPMB     UF   E           K DISK 
  FCOLMBID   IF   E           K DISK    RENAME(COPMB1:COLMBID1) PREFIX(M2_) 

An Introduction to ILE RPG: Part 1

Figure 8 IGNORE and INCLUDE

 
  RPG/400 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilenameIPEAF....RlenLK1AIOvKlocEDevice+......KExit++Entry+A....U1....... 
  FALLMBID IF  E           K        DISK         KIGNOREFORMAT2 
  F                                              KIGNOREFORMAT3 
  F                                              KIGNOREFORMAT4 
 
  ILE RPG 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilename++IPEASFRlen+LKlen+AIDevice+.File 
  continuation++++++++++++++++++++Comments++++++++++++ 
  FALLMBID   IF   E           K DISK    INCLUDE(FORMAT1) 

An Introduction to ILE RPG: Part 1

Figure 9 COMMIT

 
  RPG/400 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilenameIPEAF....RlenLK1AIOvKlocEDevice+......KExit++Entry+A....U1....... 
  FCOLMBID UF  E           K        DISK         KCOMIT 
 
  ILE RPG 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilename++IPEASFRlen+LKlen+AIDevice+.File 
  continuation++++++++++++++++++++Comments++++++++++++ 
  FCOLMBID   UF A E           K DISK    COMMIT(C_COLMBID) 

An Introduction to ILE RPG: Part 1

Figure 10 TOFILE

 
  RPG/400 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilenameIPEAF....RlenLK1AIOvKlocEDevice+......KExit++Entry+A....U1.......FOS6M 
  ASTRIP  E                    DISK 
  FADDROUT IR  F       3  3 T      EDISK 
 
  E....FromfileTofile++ArrnamN/rN/rbLenPDSArrnamLenPDSComments............... 
  E    ADDROUT OS6MASTR 
 
  ILE RPG 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilename++IPEASFRlen+LKlen+AIDevice+.File 
  continuation++++++++++++++++++++Comments++++++++++++ 
  FOS6MASTR  IP   E             DISK 
  FADDROUT   IR   F    3     3 TDISK    TOFILE(OS6MASTR) 

An Introduction to ILE RPG: Part 1

Figure 11 OFLIND, FORMLEN and FORMOFL

 
  RPG/400 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilenameIPEAF....RlenLK1AIOvKlocEDevice+......KExit++Entry+A....U1....... 
  FINVOICESO   F     132     OF    LPRINTER 
 
  LFilenameFlnFlOlnOl........................................................ 
  LINVOICES 51FL 44OL 
 
  ILE RPG 
  *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 
  ...+... 9 ...+... 10 
  FFilename++IPEASFRlen+LKlen+AIDevice+.File 
  continuation++++++++++++++++++++Comments++++++++++++ 
  FINVOICES  O    F  132        PRINTER OFLIND(OF) FORMLEN(51) FORMOFL(44) 

An Introduction to ILE RPG: Part 1

Figure 12 Changes to the PRTCTL Data Structure

 
                                   RPG/400                     ILE RPG 
 
   Description             Positions      Length      Positions        Length 
  Space before               1-1            1           1-3               3 
 
  Space after                2-2            1           4-6               3 
 
  Skip to line number        3-4            2           7-9               3 
  before 
 
  Skip to line number        5-6            2          10-13              3 
  after 
 
  Current line count         7-9            3          13-15              3 
BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: