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
More 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.
TRY 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.
Forms 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.
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:
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.
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:
LATEST COMMENTS
MC Press Online