Midware
Ltd.
|
|
|
|
Prior to RPG IV, Input Specifications (I-specs) were used to define data elements (data structures, named constants, etc) within a program. Over the years I-specs were distanced from their original intent of defining program-described input files. As of RPG IV I-specs were returned to their original intent - to define program-described input files. All other types of data elements may be defined using the new D-specs. In addition to having a much more streamlined and intuitive layout that I-specs, D-specs also offer much more functionality. The D-spec layout is as follows: *.. 1 ...+... 2 ...+... 3 ...+... 4 ...+...
5 ...+... 6 ...+... 7 ...+... 8 ...+... 9 ...+... 10 I won't attempt to thoroughly cover the syntax of a D-spec here. I've found that the best way to learn D-specs syntax is to code the I-spec the way you want in RPG III and then run the conversion process. Instead, In addition to allowing you to define data structures, D-specs also allow you to define named constants and stand-alone fields. Positions 24-25 are used to identify the type of data element that is defined:
One of the opportunities that D-specs provide is the ability to define and initialize all program-described fields (stand alone fields as well as named constants) in D-specs rather than throughout the program. This practice can greatly improve program readability. Field names within a D-spec may be indented for readability and to imply a hierarchy for data structure subfields. Indenting is for readability however and has no affect on the data. Note also, that like H-spec and F-specs, D-specs also have free format keywords available. In addition to INZ (for stand alone fields) and CONST (for named constants), some of the available keywords include: DIM(numeric_constant): This keyword replaces the old E-specs by defining the field as a table or array. The CTDATA, FROMFILE, and TOFILE keywords may also be used in conjunction with the DIM keyword. CTDATA defines the array as being loaded with compile time data (described at the end of the source member). The FROMFILE and TOFILE keywords may be used to automatically load the array from a file at pre-runtime or update a file from the array at post-runtime. DTAARA{(data_area_name)}: This keyword associate a data element with an external data area. It is equivalent to using the *DTAARA DEFINE opcode. If the data element is defined as a data structure ("DS" in positions 24-25) and a "U" is coded in position 23, the data area will automatically be retrieved when the program is initialized, and updated when the program ends. EXPORT{(external_name)}, IMPORT{(external_name)}: The export and import keywords allow you to implicitly share data across modules in a program. This is a useful concept when creating ILE applications and will be covered in later sections. LIKE(RPG_name): The LIKE keyword allows you define a data element so that it has the same data type and length as another field. This keyword may be used in place of the *LIKE DEFINE opcode. OCCURS(numeric_constant): OCCURS, when used on a data structure, defines it as a multiple occurrence data structure. OVERLAY(name{:pos | *NEXT}): The OVERLAY keyword allows a field name to be created as an overlay of a data structure or a data structure subfield. The keyword is only valid on data structure subfields. For example: DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords++++++++++++++++++++++++++++ D DataStructure DS D Field10 10 D Field1to5 5 overlay(Field10) D Field6to10 5 overlay(Field10:*next) In the above example, FIELD10 is defined a 10 byte alpha subfield of data structure DATASTRUCTURE. FIELD1TO5 will be overlayed with the first 5 positions of FIELD10 and FIELD6TO10 will be overlayed with the last 5 positions. Keep in mind that all 4 data names refer to areas of the same 10 bytes of memory.
For a complete list of D-spec keywords (as of V4R5) see IBM's online documentation. Additional data typesIn addition to the syntax changes of D-specs, RPG IV also allow you to define a number of new data types. Some of the more interesting types include: Date (D), Time (T), and Timestamp (Z): One of the most long-awaited enhancements to RPG IV is the inclusion of date and time support. Timestamp fields combine both date and time (including micro-seconds) into one field. Prior to this, normally a six-digit number was used to represent date and time fields. Date, time, and timestamp fields are internally stored as a number of days (for date fields), seconds (for time fields), or micro-seconds (for timestamp fields) from a given base date or time. The INZ(*SYS) keyword may be used when defined date, time, or timestamp fields to initialize the value to current system date as in: DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords++++++++++++++++++++++++++++ D @CurrDate S D inz(*sys) D @CurrTime S T inz(*sys) D @CurrTimestmp S Z inz(*sys) For more information on date and time data types, see the Date and Time section. Floating Point (F): Floating point fields are often useful for storing calculated values where you don't know beforehand the number of decimal places or significant digits you'll need. Floating point fields may either be defined as standard 4-byte, or double precision 8-byte lengths.
Single precision floating point fields allow for a numeric range from 1.1754944-38 through 3.4028235+38. Double precision allows for a range of 2.225073858507201-308 through 1.797693134862315+308. Indicator fields (N): By defining fields of type N, you can create your own boolean variables for true/false evaluations. Pointers (*): Yes, RPG IV even supports pointers! Pointer variables, when used with the BASED keyword and ALLOC and DEALLOC opcodes provide some very sophisticated functionality. For more information as well as some examples, see the Pointers page.
|
   
Send mail to midware@midwareservices.com
with questions or comments about this web site. Last Modified: August 23, 2000 |
