In Cobol, to test "null or empty" we use "NOT = SPACE [ AND/OR ] LOW-VALUE" ? Which is it?_问答_开发者

I am now working in mainframe, in some modules, to开发者_如何学Go test

Not null or Empty

we see : NOT = SPACE OR LOW-VALUE The chief says that we should do : NOT = SPACE AND LOW-VALUE

Which one is it ?

Thanks!

Chief is correct.

COBOL is supposed to read something like natural language (this turns out to be just another bad joke).

Lets play with the following variables and values:

 A = 1
 B = 2
 C = 3

An expression such as:

IF A NOT EQUAL B THEN...

Is fairly straight forward to understand. One is not equal to two so we will do whatever follows the THEN. However,

IF A NOT EQUAL B AND A NOT EQUAL C THEN...

Is a whole lot harder to follow. Again one is not equal to two AND one is not equal to three so we will do whatever follows the 'THEN'.

COBOL has a short hand construct that IMHO should never be used. It confuses just about everyone (including me from time to time). Short hand expressions let you reduce the above to:

IF A NOT EQUAL B AND C THEN...

or if you would like to apply De Morgans rule:

IF NOT (A EQUAL B OR C) THEN...

My advice to you is avoid NOT in exprssions and NEVER use COBOL short hand expressions.

What you really want is:

 IF X = SPACE OR X = LOW-VALUE THEN...
    CONTINUE
 ELSE
    do whatever...
 END-IF

The above does nothing when the 'X' contains either spaces or low-values (nulls). It is exactly the same as:

 IF NOT (X = SPACE OR X = LOW-VALUE) THEN
    do whatever...
 END-IF

Which can be transformed into:

 IF X NOT = SPACE AND X NOT = LOW-VALUE THEN...

And finally...

 IF X NOT = SPACE AND LOW-VALUE THEN...

My advice is to stick to simple to understand longer and straight forward expressions in COBOL, forget the short hand crap.

In COBOL, there is no such thing as a Java null AND it is never "empty".

For example, take a field

 05  FIELD-1  PIC X(5).

The field will always contain something.

MOVE LOW-VALUES TO FIELD-1.

now it contains hexadimal zeros. x'0000000000'

MOVE HIGH-VALUES TO FIELD-1.

Now it contains all binary ones: x'FFFFFFFFFF'

MOVE SPACES TO FIELD-1.

Now each byte is a space. x'4040404040'

Once you declare a field, it points to a certain area in memory. That memory area must be set to something, even if you never modify it, it still will have what ever garbage it had before the program was loaded. Unless you initialize it.

05  FIELD-1 PIC X(6) VALUE 'BARUCH'.

It is worth noting that the value null is not always the same as low-value and this depends on the device architecture and its character set in use as determined by the manufacturer. Mainframes can have an entirely different collating sequence (low to high character code and symbol order) and symbol set compared to a device using linux or windows as you have no doubt seen by now. The shorthand used in Cobol for comparisons is sometimes used for boolean operations, like IF A GOTO PAR-5 and IF A OR C THEN .... and can be combined with comparisons of two variables or a variable and a literal value. The parser and compiler on different devices should deal with these situations in a standard (ANSI) method but this is not always the situation.

I agree with NealB. Keep it simple, avoid "short cuts", make it easy to understand without having to refer to the manual to check things out.

IF ( X EQUAL TO SPACE ) 
OR ( X EQUAL TO LOW-VALUES )
   CONTINUE
ELSE
   do whatever...
END-IF

However, why not put an 88 on X, and keep it really simple?:

88  X-HAS-A-VALUE-INDICATING-NULL-OR-EMPTY VALUE SPACE, LOW-VALUES.

IF X-HAS-A-VALUE-INDICATING-NULL-OR-EMPTY
    CONTINUE
ELSE
   do whatever...
END-IF

Note, in Mainframe Cobol, NULL is very restricted in meaning, and is not the meaning that you are attributing to it, Tom. "Empty" only means something in a particular coder-generated context (it means nothing to Cobol as far as a field is concerned).

We don't have "strings". Therefore, we don't have "null strings" (a string of length one including string-terminator). We don't have strings, so a field always has a value, so it can never be "empty" other than as termed by the programmer.

Oguz, I think your post illustrates how complex something that is really simple can be made, and how that can lead to errors. Can you test your conditions, please?