EIP in CPFilter with BM39SP2 on NW65SP8

Question

I have finally taken the plunge and just upgraded some servers from BM3.8 to
3.9SP1 then applied SP2.
The servers have been running NW65SP8 for some time without any significant
issues.
Now on one server I am getting multiple abends as soon as I try to apply any
changes to the ACL via iManager (2.7.3) Workstation.
On another I find that although iManager reports a successful application of
the new rules, the server re-reads the rules but reports the old number of
rules, ie pre-change. Hitting the Apply Changes button a second or third
time brings the server into line.
I have seen a post from March that there is a new version of ACLCHECK
available, but I cannot find any trace of it in the downloads section of the
Novell site.
Can anyone please help?
Regards... Liam McDonnell

Answer 1

I have been supplied a new version of ACLCHECK which addressed the issues
with the "EIP in CPFilter" abends.
On the other hand, I was also caught out by the flawed install routine of
BM3.9 SP2 which stops if it fails to see a copy of iManager to back up, but
still updates PRODUCTS.DAT.
The clue is in the BM39SP2.LOG which should explicitly declare that the
various affected folders have had files copied.
"Craig Johnson" <[email protected]> wrote in message
news:[email protected]...
> In article <[email protected]>, Liam McDonnell
> wrote:
>> Now on one server I am getting multiple abends as soon as I try to apply
>> any
>> changes to the ACL via iManager (2.7.3) Workstation.
>>
> When I see this sort of behavior, it usually means a corrupted rule. The
> fix
> is generally to delete and reapply rules. Might help to backup the rules,
> wipe
> them out and just restore the backup. (At least it's easy to try).
>
>> On another I find that although iManager reports a successful application
>> of
>> the new rules, the server re-reads the rules but reports the old number
>> of
>> rules, ie pre-change. Hitting the Apply Changes button a second or third
>> time brings the server into line.
>
> My personal theory on this:
> -With 3.8 and earlier, using NWADMN32, Novell had architected the system
> to
> have a) nwadmin write a change to nds, and b) nwadmin notify the server
> nlms to
> refresh the appropriate config, and c) nwadmin tell the server what
> timestamp
> to look for. Therefore, the server would keep reading its config from NDS
> until it got a change with the designated timestamp.
>
> I think with 3.9 that Novell no longer signals BMgr what timestamp to look
> for,
> but simply tells it to reread the config. And so you end up having BMgr
> read
> NDS too soon for synch of changes made at other replicas, resulting in
> BMgr
> simply rereading the existing config. By the time you tell it to apply
> changes
> later on, changes submitted into one replica have synched over to the BMgr
> server and are then seen by BMgr.
>
>> I have seen a post from March that there is a new version of ACLCHECK
>> available, but I cannot find any trace of it in the downloads section of
>> the
>> Novell site.
>
> Nothing new released publicly yet, but I don't know that it would have any
> bearing on the issues here.
>
>
> Craig Johnson
> Novell Support Connection SysOp
> *** For a current patch list, tips, handy files and books on
> BorderManager, go to http://www.craigjconsulting.com ***
>