Highlighted
Absent Member.
Absent Member.
1142 views

use of m$ function with linkage item to implement dynamic arrays

[Migrated content. Thread originally posted on 31 August 2011]

Hi, i developed a library to handle dynamic arrays. Functions written are new, free, append, insert, set, get, sort, search and binary search.

I choose the "get" function to examplify the question; this function use a linkage as follows:


linkage section
01 array
   05 array-ptr   usage pointer           | pointer to the head
   05 array-el-sz pic 9(09) usage comp-4  | size of each element
   05 array-len   pic 9(09) usage comp-4  | current number of elements
   05 array-cap   pic 9(09) usage comp-4  | current maximum capacity of the array

77 array-val pic x(16384) | variable to return the "array-idx" element of the array

77 array-idx pic 9(09) | index to get

procedure division.
...
...
...

entry "array:get" using array, array-val, array-idx | in C it is equal to do array-val = array[array-idx]
   ... here i use m$get and put value in array-val to return the value to the caller ...


As you can see to return a value contained into an array i have to pass a very big linkage item (16384 bytes) in order to have a buffer that can cope with my future needs.

This approach has two big disadvantages:
- the size of each array element is limited (in this case to 16384)
- using a big size such 16384 slow down sort and search operations even if my array contains only e.g. pic 9(09)
because in order to compare values from the array i have to put them in the buffer

To work around this problems i thought that instead of pass the buffer in the linkage i could pass the pointer of the buffer:



linkage section
01 array
   05 array-ptr   usage pointer           | pointer to the head
   05 array-el-sz pic 9(09) usage comp-4  | size of each element
   05 array-len   pic 9(09) usage comp-4  | number of elements
   05 array-cap   pic 9(09) usage comp-4  | current maximum capacity of the array

77 array-val-ptr usage pointer | pointer to the variable to return the "array-idx" element of the array

77 array-idx pic 9(09) | index to get

procedure division.
...
...
...

entry "array:get" using array, array-val-ptr, array-idx
   ... here i use m$copy and put value in array-val-ptr to return the value to the caller ...


This way i am not limited by the size of the linkage item but i have another problem that is, the library is already in use in my office and there is no retrocompability with previuos version that uses the buffer. Also, as it is not possible to do


call "array:get" using array, ADDRESS OF array-val, 0


the caller always have to write additional code and to declare an additional variable (the pointer):


set array-val-ptr to address of array-val
call "array:get" using array, array-val-ptr, 0



Finally i got to a third solution that is the one i prefer but i don't know if is a right way to do, that is what i want to know from you:


linkage section
01 array
   05 array-ptr   usage pointer           | pointer to the head
   05 array-el-sz pic 9(09) usage comp-4  | size of each element
   05 array-len   pic 9(09) usage comp-4  | number of elements
   05 array-cap   pic 9(09) usage comp-4  | current maximum capacity of the array

77 array-val pic x(01) | !!! IMPORTANT !!! I PASS A LINKAGE ITEM OF 1 BYTE

77 array-idx pic 9(09) | index to get

procedure division.
...
...
...

entry "array:get" using array, array-val, array-idx

   SET array-val-ptr TO address of array-val

   ... here i use m$copy and put value in array-val-ptr to return the value to the caller ...


Surprisingly i found that this approach works, the m$copy correctly copies any length of bytes in array-val if the caller pass a variable large enough, even if the linkage item is declared as pic x(01).

My question is, is this the behaviour expected from the m$copy (to ignore the declared size in linkage section on behalf of the actual size of linkage item)? Is it safe for me to use this approach and i can rely on the fact that c$copy will always behave this way in future runtime version?

(A little hint, the library always know how many bytes to copy with m$copy as it is indicated by the variable array-el-sz)

Thank you in advance,
Luca
0 Likes
5 Replies
Highlighted
Absent Member.
Absent Member.

RE: use of m$ function with linkage item to implement dynamic arrays

Does any one can answer this question? Maybe should i better explain the problem?
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: use of m$ function with linkage item to implement dynamic arrays

I need an answer to this question. Is there anyone that i can contact (for instance the supportline) that can answer?
0 Likes
Highlighted
New Member.

RE: use of m$ function with linkage item to implement dynamic arrays

Seems like a question that Gisle would have answered before, but I haven't noticed any posts from him on these new forums. Perhaps you could call your account rep, and ask them to put some pressure on the support staff to get this answered? It could prove to be a useful answer to someone else down the road as well.

-Chris
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: use of m$ function with linkage item to implement dynamic arrays

The ACUCOBOL-GT M$COPY routine does not keep track of the size of the parameter passed to copy into. So this is a perfectly acceptable solution.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: use of m$ function with linkage item to implement dynamic arrays

Ok, very good news, thank you for reply.

Luca
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.