Highlighted
Super Contributor.
Super Contributor.
128 views

Negative numbers in line sequential files - are they encoded?

Jump to solution

I noticed that negative numbers seem to be sort of encoded by Visual COBOL when written to line sequential files. PIC S99 VALUE -2, for instance, is stored in a line sequential file as "0r":

Micro Focus COBOL - Negative numbers in line sequential file.png

 

Is this by intention? I couldn't find any documentation describing how negative numbers are stored in line sequential files. Until now, I would have believed they were stored like any other literal value (e.g. as "-02").

Just in case, please find a sample project attached, depicting the issue.

Your help is appreciated.

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: Negative numbers in line sequential files - are they encoded?

Jump to solution

Nothing is specifically encoded in a line sequential file (except that with certain environmental settings non-printable characters may be preceded by an x"00" character).  Otherwise the entire record is written as is, and followed by either x"0d0a" or x"0a" (for Windows/Unix respectively, but this may also be affected by environmental settings).

There is no analysis of the structure of the record, and no knowledge that a particular area of the record corresponds to a numeric field, so no transformation.  In fact that area may anyway be subject to redefinition as  PIC X(n) or whatever.  The COBOL numeric field in your example can however be defined as:

01 myNumber PIC S99 SIGN IS LEADING SEPARATE.

...which will cause the sign to be stored as a separate byte (and therefore to get written out to the line sequential file as a separate character).  LEADING may be replaced by TRAILING for a trailing sign. 

View solution in original post

3 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: Negative numbers in line sequential files - are they encoded?

Jump to solution

Nothing is specifically encoded in a line sequential file (except that with certain environmental settings non-printable characters may be preceded by an x"00" character).  Otherwise the entire record is written as is, and followed by either x"0d0a" or x"0a" (for Windows/Unix respectively, but this may also be affected by environmental settings).

There is no analysis of the structure of the record, and no knowledge that a particular area of the record corresponds to a numeric field, so no transformation.  In fact that area may anyway be subject to redefinition as  PIC X(n) or whatever.  The COBOL numeric field in your example can however be defined as:

01 myNumber PIC S99 SIGN IS LEADING SEPARATE.

...which will cause the sign to be stored as a separate byte (and therefore to get written out to the line sequential file as a separate character).  LEADING may be replaced by TRAILING for a trailing sign. 

View solution in original post

Highlighted
Super Contributor.
Super Contributor.

Re: Negative numbers in line sequential files - are they encoded?

Jump to solution

Thanks a lot, Robert! 👍

Your answer was very informative and enlightening to me.

With the aid of your answer I was able to find the corresponding help topics in the documentation, providing even more in-depth information about how negative values are stored in sequential files. For anyone stumbling over this question at a later time, I'd like to list them here for quick reference:

Highlighted
Outstanding Contributor.
Outstanding Contributor.

Betreff: Negative numbers in line sequential files - are they encoded?

Jump to solution

this is ok so in mf-files. by negativ values the last sign is a character, for 02- 0r, etc....

You can work correctly with this automatically coding!

you can store sign trealing or leading, when you define this.

rm directive store the sign leading, when i remember me correctly.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.