The format section describes where the field that you want is located within the receiver variable.
An offset is shown in both decimal and hexadecimal. Depending on which language you use, either offset may be helpful. For CL and RPG, you would normally use the decimal offset. With any offset, it is important to remember whether your language works with an offset from a base of 0 or a base of 1. The format tables in the APIs are prepared for languages that work from a base of 0, but not all languages can use this base. CL and RPG, for example, work from a base of 1, so you need to add 1 to the decimal value of each offset. The hold on job queue field begins at decimal offset 76, for example. To access the information in CL or RPG, you need to address byte 77 within the receiver variable.
Using the format, you can tell that the field after the hold on job queue field, output queue name, begins in offset 86. This means that the hold on job queue information is in the following location from a CL or RPG perspective:
77 86
. .
. .
XXXXXXXXXX
The only possible values for the hold on job queue field are *YES and *NO. They are left-justified in the field and the remaining positions are blank.
Most of the formats provide additional bytes for each field to allow for expansion, such as a new value for the hold on job queue field that would be more than 4 bytes.
Many of the needed structures are provided by the system-include library, QSYSINC. However, any fields of a structure that are variable in length are not defined by QSYSINC. These variable-length fields must be defined by the user, as shown by (3) in Example in OPM RPG: Accessing a field value (initial library list).