HIGH-VALUES and LOW-VALUES in COBOL

[adwarak]

Just wanted why we need to use HIGH-VALUES and LOW-VALUES in cobol programs.
All I know about these literals is NOTHING is greater than HIGH-VALUES and NOTHING is lesser than LOW-VALUES.

 

[CliveC]

In a sense your question contains the answer. If you were sorting a table in core and wanted it to be in ascending order you could first initialize it to high values. If you did not fill the table, the remaining entries would sort to the bottom, whatever the key. Similarly if you were sorting in descending order you could initialize to low values.

If a field containing high or low values is inadvertantly packed it will not cause a problem.

Of course you can use any hex values with the notation x"nn" it is just that they do not all have special names.

Maybe others can think of some other uses.

Clive

http://tubularity.com

 

[webrabbit]

Early versions of COBOL did not have hex literals, so Low-Value and High-Value were required.

As a side note, early versions of Microfocus COBOL used X'7F' for High-Value. It didn't work very well on 8-bid machines.

 

[3gm]

I've used LOW-VALUES when working with null-terminated strings such as those required by C (LOW-VALUES = NULL in all the COBOLs I've ever seen).

A NULL value returned from a database read (i.e. no data in the field) is also LOW-VALUES in many systems.

I often set key fields to HIGH-VALUES when I reach EOF on an input file. It simplifies the logic in dealing with EOF with match/merge algorithms. (LOW-VALUES could be used as well if the files were sorted in descending order.)

I think there are probably lots of other uses beyond those outlined so far in these responses.

Regards.

Glenn

 

[slade]

Hi Ad,

Just another point that may be worth considering. When I want to "flag" a field or a record for future testing (i.e. IF HIGH-VALUES...) and special processing. I use a string of high vals on the premise that they occur rarely in nature and would only be in that field/record because I put it there. But check that premise in EVERY situation.

Another good/bad thing about h/l vals is that they "print" as spaces.

Regards, Jack.

 

[webrabbit]

Some caveats in using Low-Values in files other than data files: Some printers do not "print" Low-Values (nulls) as spaces, but ignore them altogether, so that X'300031' (ascii) or X'F000F1' (ebcdic) would print as "01" not "0 1". Also, some text editors cannot process nulls. One in particular, Brief, converts them to spaces.

 

[MIKELEIBO]

I use high-values in match programs which will work with "n" input selects. I move high-values to the match-keys. You need only test the equal leg for high-values to determine when all the files are at EOF.

I likewise use low-values to force initial low conditions.

Other than that, they are dangerous to use as their display on reports and other output media varies depending on the display software. I've seen null values been ignored which will cause data to shift without clear explanation.

Null(low) values can also be used if you need to play ganes with binary counters setting enmass to zero.

 

[on5ex]

You could set a file key to LOW-VALUES to keep some parameter(s) in one particular record.

 

[CobolKid]

Anyone remember the days?

LOW-VALUE filler for internally processed 8.3 filenames


How about "null character insertion"