The Versatility of Variable-Length Fields

Versatility is an RPG programmer's friend. In this month's column, we're introducing one of the most versatile RPG field types: variable-length fields.

Variable-length fields can be defined either on the database or internally within your RPG programs. Definition within a program is a simple matter. You merely add the keyword "varying" to a regular fixed-length character field, as the following example illustrates:

D OutputString    S            200a   Varying

A varying-length field differs from a conventional character field in that the length you define (200 characters in the above example) is the field's maximum size. At any given time, the current length of the field varies from a minimum of zero to the maximum. How does the compiler know the field length? Well, a variable-length field consists of two parts; a 2-byte integer field that holds the current length, followed by the actual data itself. Because of this, a variable-length field always occupies two more bytes than its maximum length.

Defining variable-length fields in the database can be valuable for reducing storage requirements. Suppose we have a database in which we store narrative descriptions of our products. The maximum space allowed for a given description is 1,000 characters, but a typical description is less than 100 characters. That means that in a database of only 1,000 products, we've probably wasted about 900,000 bytes of storage (i.e., 1,000 records which typically waste 900 bytes each). In the physical file data description specification (DDS) below; you'll see that we used the keyword "VARLEN" when defining the ProdDescr field. The parameter value (100) informs the system that only 100 bytes of the description are to be kept with the record's main body. (Note: If VARLEN is specified without the optional numeric parameter you'll still have a varying length field, but won't save any disk space.)

           R PRODREC
              PRODCODE      5
              PRODDESCR   1000          VARLEN(100)
            K PRODCODE

If the description exceeds 100 bytes, the excess will be stored in a separate part of the database. This means that the descriptions for the majority of our records use only 102 bytes. Only those that exceed the 100-character limit use additional space. All of this is transparent to the programmer, because the database presents the description to the user program as a full 1,000 bytes, having blank padded any unused character positions.

When used in operations, variable-length fields are treated like fixed-length fields with lengths equal to the field's current length. This is illustrated by the following code snippet, which reads each of the records in the Product file described above.The ProdDescr field is moved to a conventional fixed-length field (Message), which has previously been filled with question marks.

 FProdData  IF   E           K Disk
 D Message         S             52
 C                   Read      ProdData
 C                   DoW       Not %Eof(ProdData)
 C                   Eval      Message = *All'?'
 C                   MoveL     ProdDescr Message
 C     Message       Dsply
 C                   Read      ProdData
 C                   EndDo

















Jon Paris is a technical editor with IBM Systems Magazine and co-owner of Partner400.

Susan Gantner is a technical editor with IBM Systems Magazine and co-owner of Partner400.

comments powered by Disqus



2017 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

New and Improved XML-INTO

Namespace support makes the opcode a viable option

Authenticating on the Web

The finer points of OpenRPGUI, Part 1

The Microphone is Open

Add your voice: Should IBM i include open-source RPG tools?

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters