Highlighted
Super Contributor.
Super Contributor.
1550 views

Level 66 and managed code

Jump to solution
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?
0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Level 66 and managed code

Jump to solution

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.

View solution in original post

0 Likes
5 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Level 66 and managed code

Jump to solution

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.
0 Likes
Highlighted
Super Contributor.
Super Contributor.

RE: Level 66 and managed code

Jump to solution

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.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Level 66 and managed code

Jump to solution

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.

0 Likes
Highlighted
Super Contributor.
Super Contributor.

RE: Level 66 and managed code

Jump to solution

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?

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Level 66 and managed code

Jump to solution

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.

View solution in original post

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.