2
 01  g1.
     05  h1           PIC X   VALUE 'N'.
         88 s1                     VALUE 'Y'.
         88 s2                     VALUE 'N'.

In the above code what will be the value of s1 and s2? whether it holds the value given in the group variable(05) or it will have their own values?

Abacus
  • 2,041
  • 1
  • 18
  • 23
Dobby
  • 215
  • 8
  • 15

2 Answers2

6

S1 and S1 are named conditions. They will be true or not true depending upon the value of H1 (or G1 in this case).

The code:

Set S1 to true

will cause the value of H1 (and G1 in the case of your specific group) to be 'Y'. If you execute:

Set S2 to true

the value of H1 (and G1 again) will be a character 'N'.

These can be tested using standard relational conditions. For example:

Evaluate true
  when S1
    Display "S1 is true"
  when S2
    Display "S2 is true"
End-Evaluate

If S1
  Display "S1 is true"
Else
  Display "S1 is false"
End-If

Bruno covered most of the important features of 88-levels, or named conditions, but I feel it is important to mention the way they are badly abused by Cobol programs that just can't give up their 1974 skills.

You will often see people doing things like:

Move 'Y' to H1

This is a really bad idea for several reasons: - someday, somebody is going to "move 'x' to H1" and really mess up your day - somebody is going to write code like "if H1 = 'Y'" and make it impossible to scan for uses of your named condition

There is a way to avoid this, use an unnamed byte with your named conditions. If your data item looks like this:

01 G1
  02 ...
  02 Filler Pic X value 'N'.
    03 S1         value 'Y'.
    03 S2         value 'N'.

By skipping the name on H1, you FORCE other programmers working with your data layout to use your named conditions S1 and S2. This has many benefits, chief among them is that you can always scan your source repository for the named conditions and you can identify all changes easily.

Joe Zitzelberger
  • 4,238
  • 2
  • 28
  • 42
  • Neat idea, using un-named data items to force programmers to use only named conditions. Unfortunately the guys in my shop are "smarter" than that... They would resort to using reference modification to get at that un-named byte as in: `MOVE 'X' TO G1(2:1)` or whatever offset was needed. – NealB Aug 04 '11 at 18:28
  • Yes, they can. You can shoot yourself in any language, but this way pushes the responsible programmers to use the value-type safe versions. Over time, it can make a difference. – Joe Zitzelberger Aug 04 '11 at 22:33
  • @Joe: If you do this, I would also leave out 'filler'. It's not required anymore. – Kwebble Aug 25 '11 at 20:18
  • 1
    Make G1 a FILLER as well. Then no reference-modification possible :-) I prefer using FILLER rather than leaving it blank (an "implicit" FILLER). One thing you loose out with the FILLER definition is in the generated code you see reference to FILLER rather than a dataname when the 88 is referenced, but I think that that is a small price for knowing all the references. – Bill Woodger Jan 28 '13 at 13:44
4

s1 and s2 don't hold a value. They are "named conditions" ( so-called 88-levels ) and are associated with another item ( the conditional variable ). The 88 level does not define a field, and does not take space in the record; it is merely a value definition.

The named condition can be used in an IF statement, and tests whether the conditional variable is equal to any of the values given in the named condition's VALUE clause.

The SET statement can be used to make a named condition TRUE (by assigning the first of its values to the conditional variable).

Usage:

SET s1 TO TRUE

h1 will hold the value 'Y'

You could test it's value with

IF h1 = 'Y' or simply IF s1

EDIT: As Joe Zitzelberger mentioned in his answer, the correct way to test the conditional variable is to use the named conditions.

IF s1 THEN

   //do something
ELSE 

   //do somethingElse
END-IF
bruno
  • 2,802
  • 1
  • 23
  • 23
  • 1
    What is the point of giving a named condition if you are going to test it with literals? Totally defeats the purpose. – Joe Zitzelberger Aug 04 '11 at 16:46
  • You're right! Unfortunately it's pretty common to see code like this and I was only trying to show that they and "are the same". I'll update the answer. – bruno Aug 04 '11 at 20:33
  • I agree it is common to see it the way you had it. I just felt it important to point out that it's not necessary these days. – Joe Zitzelberger Aug 04 '11 at 22:34