- Article Type: General
- Product: Aleph
- Product Version: 18.01
We recently added a new sublibrary and I have been going through all our profiles adding in the permission for the new sublibraries when a z67_func/z67_sub_func is restricted to a subset of all sublibraries. I was adding in a line to profile TMACPR03 and instead of adding the sublibrary, it deleted all sublibraries for the z67_func/z67_sub_func.
I checked to see if there was adequate space in z67, and there is. I checked to see if the problem occurred on other profiles, and I was able to successfully add in lines to a different profile.
When I selected all lines for z67_rec_key like 'TMACPRO3%' I found that the rec_key 'TMACPRO3 9999' has been used, which is probably why a new line can not be added. I'm not sure why the already assigned keys for the z67_func/z67_sub_func were also deleted.
Currently there are 2710 lines in the profile, although the high key of 9999 has already been reached.
I'm not sure how the system is trying to assign the key since there are some large gaps.
The fact that the Z67-SEQUENCE (bytes 11-14 of the Z67-REC-KEY) has reached 9999 is certainly the cause of this problem.
One solution would be to increase the length of the Z67-SEQUENCE to 5 bytes, but such a change could only be made in a higher version.
I see the large "holes" in the TMACPRO3 Z67-SEQUENCE's. I'm uncertain just what accounts for these. In assigning the next Z67-SEQUENCE value, the system looks for the current high value for this user, in a fashion very similar to the "select max" SQL shown below.
The purpose of the Z67-SEQUENCE is to make the z67_rec_key unique. It is not referenced anywhere else.
I suggest you use SQL to rearrange the existing TMACPRO3 Z67-SEQUENCE's so that the higher numbers fill in these lower holes, such as:
SQL> update z67 set z67_rec_key = 'TMACPRO3 ' || 'yy' || substr (z67_rec_key,13,2) where z67_rec_key like 'TMACPRO3 xx%';
(You should, of course, back up the z67 with p_file_03 before making any such update.)
If you do this, you should have a max (Z67-SEQUENCE) of around 4000 or 5000 - which should allow quite a bit of growth.
The following SQL can be used to see the highest case:
SQL> select z67_rec_key from z67 where substr (z67_rec_key,11,4) in (select max (substr (z67_rec_key,11,4)) from z67);
and this to monitor other cases over 9000:
SQL> select z67_rec_key from z67 where substr (z67_rec_key,11,4) > 9000;
- Article last edited: 10/8/2013