Level 66 and managed code

We're converting some REALLY old mainframe code to VC 2.3 for VS 2013 and we are getting a COBCH1710 when a Level 66 data item is referenced in the Procedure Division, specifically as an operand in an IF statement. I've dug around in the product documentation and can't find anything that says Level 66 shouldn't be used in managed code, but I've missed stuff in the past. Does anyone know of a restriction of Level 66 data items in managed code?
  • Can you provide me with an example? I tested with the following simple program and it works fine in managed code:

    working-storage section.
           01 my-field   pic x(10) value spaces.
           66 new-field renames my-field.
           procedure division.
           
               move "test" to my-field
               if new-field = "test"
                  display "ok"
               else
                  display "no"
               end-if
    
               goback.
    
  • Our Working Storage is slightly different.  Try modifying it to something like this:

          01  PREV-BC-CTL.

              10  P-BRCLGROUP             PIC 9          VALUE ZERO.

              10  P-ENPG                  PIC 9          VALUE ZERO.

              10  P-ERATE                 PIC X(5)       VALUE SPACES.

              10  P-FORM                  PIC X          VALUE SPACE.

          66  P-BC-NPG-RATE  RENAMES P-BRCLGROUP THRU P-ERATE.

    Then in the Procedure Division have:

              MOVE SPACES TO P-BC-NPG-RATE.

    The TO operand is red-underlined in the editor and the COBH1710 error is in the Error List window with text: 'type COBOLPrograms.WYE31P' has no member with name 'P-BC-NPG-RATE'

    We realize that this is easy enough to go around by eliminating the 66 Level item and using a group item of the same name within the 01 Level encompassing the same elementary items as specified in the 66 Level's Renames clause.  And that is what we are going to do.

    We just thought this was odd and that you might want to know about it.

  • I just tested this with both 2.3 and 2.3 update 1 and I cannot reproduce the problem you are seeing.

    Perhaps this is related to a directive that you are using that I am not.

    Could you try creating a new managed code console project and replacing the contents of Program1.cbl with the following to see if you still get the error?

          program-id. Program1 as "testman66.Program1".
          data division.
          working-storage section.
          01  PREV-BC-CTL.
             10  P-BRCLGROUP             PIC 9          VALUE ZERO.
             10  P-ENPG                  PIC 9          VALUE ZERO.
             10  P-ERATE                 PIC X(5)       VALUE SPACES.
             10  P-FORM                  PIC X          VALUE SPACE.
          66  P-BC-NPG-RATE  RENAMES P-BRCLGROUP THRU P-ERATE.
          procedure division.

              MOVE SPACES TO P-BC-NPG-RATE
              if P-BC-NPG-RATE = spaces
                 display "ok"
              else
                 display "no"
              end-if

              goback.

          end program Program1.

  • First, we're running 2.3 Update 1 also. Second, we are doing class libraries instead of console apps. And third, we found how to get rid of the error. But being a career mainframe procedural programmer, the only idea I have as to why this works would mean multiple instances sharing memory.

    This is what doesn't work:

          class-id Level66dll.Class1.

          working-storage section.

          01  PREV-BC-CTL.

            10  P-BRCLGROUP             PIC 9          VALUE ZERO.

            10  P-ENPG                  PIC 9          VALUE ZERO.

            10  P-ERATE                 PIC X(5)       VALUE SPACES.

            10  P-FORM                  PIC X          VALUE SPACE.

          66  P-BC-NPG-RATE  RENAMES P-BRCLGROUP THRU P-ERATE.

          method-id InstanceMethod.

          local-storage section.

          procedure division.

             MOVE SPACES TO P-BC-NPG-RATE

             if P-BC-NPG-RATE = spaces

                display "ok"

             else

                display "no"

             end-if

              goback.

          end method.

          end class.

    And this does:

          class-id Level66dll.Class1.

          working-storage section.

          01  PREV-BC-CTL.

            10  P-BRCLGROUP             PIC 9          VALUE ZERO.

            10  P-ENPG                  PIC 9          VALUE ZERO.

            10  P-ERATE                 PIC X(5)       VALUE SPACES.

            10  P-FORM                  PIC X          VALUE SPACE.

          method-id InstanceMethod.

          local-storage section.

          66  P-BC-NPG-RATE  RENAMES P-BRCLGROUP THRU P-ERATE.

          procedure division.

             MOVE SPACES TO P-BC-NPG-RATE

             if P-BC-NPG-RATE = spaces

                display "ok"

             else

                display "no"

             end-if

              goback.

          end method.

          end class.

    In a nutshell, can someone explain to this dinosaur what is going on in memory?

  • Verified Answer

    This appears to be a bug when trying to use renames in working-storage within a class definition. Although your example with moving just the 66 level item to local-storage gets rid of the compiler error the code generated is not correct. If you try to invoke InstanceMethod with this construct it will fail. If you move the entire data item being renamed to local-storage then it will work correctly.

    I will create a new support incident for you, Don and attach the RPI to it.

    Thanks.