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?


Yes.

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:

WORKING-STORAGE SECTION.

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.

PROCEDURE DIVISION.

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: gilles@gsainc.com web: http://www.gsainc.com
-------------------------------------------------------------------------------------------------

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *