You are currently on IBM Systems Media’s archival website. Click here to view our new website.


New D-Specs Break the Limit

RPG extends maximum size limits and adds new keywords

Anything Else?

The more astute among you may have noticed we still have a small problem in that D-specs only have enough columns to define a field length of 9,999,999 characters, a little below the new maximum. How then can we define those really big fields? By the simple use of the new keyword LEN, which can be used in place of a length definition. So to define a field of 16 million characters, we simply code LEN(16000000). You’re not limited to only using this notation for large fields. You can use it in place of the traditional-length definition any time you like. It’s interesting to note that this addition will simplify any future transition to a fully free-format D-spec.

Those of you familiar with the use of varying-length fields (that should be all of you—not that we're nagging) may be wondering if the maximum size for these has also been increased. The answer, as you might expect, is yes. The maximum size for a VARYING field has increased from 65,535 to 16,773,100 bytes. This leads to a small problem. Previously variable-length fields included a two-byte binary field, which is used to record the current length of the field. Trouble is, a two-byte field can only hold values up to 65,635 and that isn't large enough for the new limit. The simple answer was to increase the length of the count area to four bytes, but if that new length were applied to all variable-length fields, it would cause compatibility problems for programs that currently use varying-length fields. The compromise solution that the compiler writers adopted was to use either two or four bytes based on the length of the field itself. For lengths up to the old limit of 65,635, a two-byte length is used. Varying-length fields longer than this use a four-byte length area. Programmers who like consistency will also appreciate the fact that the VARYING keyword has now been extended to let programmers specify the size of the length area. So VARYING(4), for example, can be used to force a varying-length field of 2,000 characters to use a four-byte count even though only two are required.

Those of you who use varying-length fields to build strings for, say, XML documents may also find the new second parameter added to %ADDR useful. Since a varying-length field may now contain either two or four bytes preceding the data, then the old technique of using %ADDR(fieldname+2) for passing the address of the actual data portion is no longer safe. Thus the compiler writers have given us the additional keyword *DATA for %ADDR so now we can simply code %ADDR(fieldname : *Data) and be assured that we’ll always get the correct address.

All Grown Up!

While RPG IV's data-definition capabilities are by no means complete, we’ve come a long way, baby!

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.



2019 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