Highlighted
Super Contributor.
Super Contributor.
2626 views

Working storage variables persisting after class finalized in native code

Jump to solution

A class had a method that used WORKING-STORAGE instead of LOCAL-STORAGE.  I created in instance of the class and set a variable in WORKING-STORAGE to a value, then finalized the instance.  I then created a new instance of the class and called the method.  The value from the last instance carried over into the new instance.  Is this expected behavior ?  It behaves the same way in Visual COBOL and Net Express 5.1.

I fixed this by using LOCAL-STORAGE instead of WORKING-STORAGE.

Phil Levin

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Working storage variables persisting after class finalized in native code

Jump to solution

Morning,

The working-storage section is static and shared between all instances, so if you want the field to part of the object-storage and exist in each instance move the field into the "object-storage section".  For example:...

 $SET MFOO LINKCOUNT"1024" ooctrl"+p-f"

       CLASS-ID. Class1
                 INHERITS FROM AGROBASE
                 WITH DATA.

       OBJECT SECTION.
       CLASS-CONTROL.

           Class1      IS CLASS "Class1"
           AGROBASE    IS CLASS "AGROBASE"
           .

       WORKING-STORAGE SECTION.

       CLASS-OBJECT.                           *> Definition of the Class data and method
       OBJECT-STORAGE SECTION.
       END CLASS-OBJECT.

      ********************************************************************
       OBJECT.    *> Definition of instance data and methods
      ********************************************************************

       OBJECT-STORAGE SECTION.
       01  WS-NEXT-CRIT-CODE         PIC 99999 VALUE ZERO.


      ********************************************************
       METHOD-ID. "GetNextCritCode".
      ********************************************************

       PROCEDURE DIVISION.

       010-MAIN.

           ADD 1 TO WS-NEXT-CRIT-CODE.

           exhibit named WS-NEXT-CRIT-CODE.
           EXIT METHOD.

       END METHOD "GetNextCritCode".


       END OBJECT.

       END CLASS Class1.

View solution in original post

Tags (1)
0 Likes
6 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Working storage variables persisting after class finalized in native code

Jump to solution

It depends where the variable is defined.  If it's defined in the STATIC area of the class (or the definition includes the STATIC keyword), then it would be expected to be the same for all instances of the class.  If on the other hand it's defined in the OBJECT area, then it should be distinct for each instance.

0 Likes
Highlighted
Super Contributor.
Super Contributor.

RE: Working storage variables persisting after class finalized in native code

Jump to solution

It was defined in WORKING-STORAGE of a method that was not static.  I normally use LOCAL-STORAGE instead of WORKING-STORAGE for my methods.  My actual fix was to define the variable in OBJECT-STORAGE because it was a counter I incremented each time I called the method.

Phil Levin

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Working storage variables persisting after class finalized in native code

Jump to solution

It's strange because WORKING-STORAGE and LOCAL-STORAGE sections are supposed to be equivalent within methods.  For instance the following program:

      class-id a.

      method-id main static.

      01 obj type a.

          set obj to new a

          perform 5 times

              invoke obj::m

          end-perform

      end method.

      method-id m.

      working-storage section.

      01 i1 binary-long.

          add 1 to i1

          display i1

      end method.

      end class.

...shows the value '1' 5 times, since i1 is reinitialized on each entry to the method.

I should say that the above is based on compiling the code to .NET or JVM.

0 Likes
Highlighted
Super Contributor.
Super Contributor.

RE: Working storage variables persisting after class finalized in native code

Jump to solution

I created a demo and opened incident 2780525.

Phil Levin

0 Likes
Highlighted
Super Contributor.
Super Contributor.

RE: Working storage variables persisting after class finalized in native code

Jump to solution

I'll also upload the demo.

Phil Levin

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Working storage variables persisting after class finalized in native code

Jump to solution

Morning,

The working-storage section is static and shared between all instances, so if you want the field to part of the object-storage and exist in each instance move the field into the "object-storage section".  For example:...

 $SET MFOO LINKCOUNT"1024" ooctrl"+p-f"

       CLASS-ID. Class1
                 INHERITS FROM AGROBASE
                 WITH DATA.

       OBJECT SECTION.
       CLASS-CONTROL.

           Class1      IS CLASS "Class1"
           AGROBASE    IS CLASS "AGROBASE"
           .

       WORKING-STORAGE SECTION.

       CLASS-OBJECT.                           *> Definition of the Class data and method
       OBJECT-STORAGE SECTION.
       END CLASS-OBJECT.

      ********************************************************************
       OBJECT.    *> Definition of instance data and methods
      ********************************************************************

       OBJECT-STORAGE SECTION.
       01  WS-NEXT-CRIT-CODE         PIC 99999 VALUE ZERO.


      ********************************************************
       METHOD-ID. "GetNextCritCode".
      ********************************************************

       PROCEDURE DIVISION.

       010-MAIN.

           ADD 1 TO WS-NEXT-CRIT-CODE.

           exhibit named WS-NEXT-CRIT-CODE.
           EXIT METHOD.

       END METHOD "GetNextCritCode".


       END OBJECT.

       END CLASS Class1.

View solution in original post

Tags (1)
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.