At 07:14 PM 08-08-17, Brian Donaldson wrote:

>Brian retorts:
>1) Unfortunately, the flimit parm on the FOPEN uses a PIC S9(09) comp field
>and that is what is dropping off the 2. Any suggestions on how to get around
>this little snafu?


One of the problems with COBOL is how it handles binary data.

For example, an item defined as PIC S9(04) COMP occupies 2 bytes of
real-estate and can have a maximum value of 9999 - even though the 16
bits represented by the 2-byte field can actually contain a value as
high as 2 to the power of 16, less 1, which equals 65,535.

So, if you really want to account for this fact, you need to move the
field non-numerically to a larger COBOL field, examine its true
contents (allowing its true maximum value to be revealed), perform
some operation on it (if necessary) then move it back (again
non-numerically) back to its originally-sized field if required to be
again utilized in its smaller form.

To illustrate:


01 full-size-number1.
05 filler PIC X(02).
05 number1 PIC S9(04) COMP.
01 full-size-number2.
05 number2 PIC S9(05) COMP.
*please note that full-size-number2 is 4-bytes in length.
01 display-number PIC ZZ,ZZ9.


MOVE full-size-number1 TO full-size-number2.
MOVE number2 TO display-number.
DISPLAY "The actual value contained in number1 is actually:", display-number.

It's left an exercise to the reader to extrapolate this technique to
larger size COMP fields, such as PIC S9(09).

Gilles Schipper
GSA Inc.
HP System Administration Specialists
300 John Street, Box 87651 Thornhill, ON Canada L3T 7R4
Voice: 905.889.3000 Fax: 905.889.3001
email: web:

* To join/leave the list, search archives, change list settings, *
* etc., please visit *