Bruce,
One of our W2K / NT / NetWare gurus researched this very problem at our
site. For completeness, I have included his entire report to our group on
the problem. The bottom line is that it is a Novell issue. Hope the attached
helps.
Regards,
Jack Coyle
Rex Healthcare
(919) 784-3792
jack.coyle AT rexhealth DOT com
-------------------- Our Resource's Findings
--------------------------------------------------
> After futile attempts to exclude the Scross object in the dsm.opt file on
> RexNDS, I found out the following:
>
> The error showing up in the dsmerror.log (shown below) is blamed (by
> Tivoli) on a bad Novell API that allows an invalid object to be created on
> TSM.
>
> ANS1228E Sending of object '.[Root].O=REX.OU=Remote.OU=Scross'
> failed
> ANS1304W Active object not found
>
> The object is interpreted as a file when it is an object or some variation
> thereof, further explained in the TSM document included below. Once the
> problem occurs, the object is not recognized correctly so it will never
> match up. They list a work around to get rid of the object causing the
> error, but say this could occur in the future without the API fix. They
> post an incident number (2642846) to reference when calling Novell for the
> API fix.
>
> The steps are listed in red how to manually remove the object from the TSM
> filespace. It appears the error arrived about the time the TSM
> maintenance and upgrade from 5.1.7 to 5.1.8 occurred. For that reason, it
> may be best to remove the offending item at this time. Novell does not
> list anything currently regarding this issue but I reported to Novell
> support our request for an API fix. If you would prefer, I could open an
> incident to chase down an API fix immediately.
>
> To remove these objects from ITSM Server storage that will not be
> inactivated/deleted during incremental backups, either of the following
> can be done.
>
> 1. Rename the filespace on the ITSM server, and run a full backup from
> ITSM client to create a new filespace. Once a new clean filespace is
> created, customers can delete the old filespace.
>
> 2. Individual objects can be deleted with undocumented delete command
> specifying the specific High Level and Low Level identifiers for the
> object as it is stored in ITSM Server storage. Users would need to contact
> Support in determining the specific HL and LL qualifiers for these
> objects, as well as getting command syntax for delete command.
>
> I included the entire Tivoli document below. I am awaiting a response
> from Novell, but wanted to provide this information in case you wanted to
> rectify the daily error populating the logs at present. Given the pros
> and cons of renaming the filespace just to remove this error, let me know
> what you prefer.
>
>
> DCF Document ID: 1111468 - IBM Tivoli Storage Manager: ANS1228E ANS1304W
> "Active object not found" During Incremental Backup of NDS
> Problem Desc: "ANS1228E ANS1304W "Active Object Not Found"" error
> occurs. IBM Tivoli Storage Manager (ITSM) client fails NDS backup on
> Novell with this error message. Complete messaging is as follows: From
> dsmerror.log: ANS1228E Sending of object '.[Root].O=xxxx.OU=xxxx.CN=xxxx'
> failed ANS1304W Active object not found
>
> Solution: ITSM displays these errors when it attempts to inactivate an
> object stored on the ITSM Server and is unable to. ITSM determines that an
> object has been deleted from the client NDS tree after building the
> directory tree as shown in the trace snippet below. (traceflags service)
>
> Built the following directory tree...
> dirtree.cpp (2254):
> dirtree.cpp (2254): .O=AMGruppe
> incrdrv.cpp (2730): Time to get query information: 0.060000 sec.
> session.cpp (2777): Sess (xxx) FREELOCK lock action by thread (xxx):
> incrdrv.cpp (5864): PrivIncrFileSpace: Traversing: .[Root]
> .O=AMGruppe.OU=03.OU=K.OU=AO
> pstsa.cpp (1934): comparing target service AMGRUPPE to target
> service 'AMGRUPPE'.
> ntwfilio.cpp (3232): ntwSMSScan: resource
> (.OU=AO.OU=K.OU=03.O=AMGruppe.[Root])
> path(.OU=AO.OU=K.OU=03.O=AMGruppe.[Root]) connection 5 nameSpace 8
> ntwfilio.cpp (3308): NWSMTSGetNameSpaceTypeInfo (OPEN) : sms_rc = 0
> ntwfilio.cpp (3308): on connection 5 and sequence (OPEN) 0, (ATTRIB) 0
> ntwfilio.cpp (3338): NWSMPutOneName (OPEN) : sms_rc = 0
> ntwfilio.cpp (3338): on connection 5 and sequence (OPEN) 0, (ATTRIB) 0
> ntwfilio.cpp (3126): PRE-NWSMTSScanDataSetBegin (OPEN) : sms_rc = 0
> ntwfilio.cpp (3126): on connection 5 and sequence (OPEN) 0, (ATTRIB) 0
> ntwfilio.cpp (3138): NWSMTSScanDataSetBegin (OPEN) : sms_rc = 0
> ntwfilio.cpp (3138): on connection 5 and sequence (OPEN) 57DC2AF0,
> (ATTRIB) 0
> ntwfilio.cpp (3465): NWSMGetDataSetName: sms_rc = FFFBFFFC
> on connection 5 and sequence (OPEN) 57DC2AF0, (ATTRIB) 0
> ntwfilio.cpp (3465): (SMDR-1.0-24) An internal error has occurred.
> Either the list has no more entries or the specified name space type does
> not exist.
>
> ITSM compares what is stored on the ITSM Server for the NDS objects with
> what ITSM Client receives from Novell API calls, and will send
> "cuBackDel"verbs to the ITSM server to inactivate any object that has been
> deleted from the client NDS tree.
>
> The ANS1228E/ANS1304W message is displayed when ITSM server is unable to
> find the object that the client is sending the delete request for, and
> responds to the cuBackDel verb with an Abort Reason Code of 4.
>
> The cause of this failure to find an object to inactivate on the ITSM
> Server is the result of a defect in Novell's API. Novell incident 2642846
> documents this defect. The issue involves the NetWare API,
> NWSMTSScanDataSetBegin, which incorrectly reports the 'parentFlag'
> attribute for some NDS objects. NWSMTSScanDataSetBegin returns the
> parentFlag as a part of the object attributes in the
> NWSM_SCAN_INFORMATION structure. An object is defined as a FILE when the
> parentFlag is set to 0, and as a DIRECTORY with the parentFlag is set to
> 1.
>
> When an NDS object is backed up by ITSM, its attributes and its type (FILE
> or DIRECTORY) is passed from the NetWare API NWSMTSScanDataSetBegin.
> Originally, when the NDS object attributes
> are scanned the object is reported as a FILE by Novell API, but on
> subsequent scannings, the Novell API returns the object type as a
> DIRECTORY object.
>
> The reason that ITSM can not later inactivate/delete an object and reports
> the ANS1228E/ANS1304W message is that it has stored some NDS objects as
> FILE objects on the ITSM server. On the subsequent backups when the
> objects are to be expired/inactivated, the ITSM client
> sends the 'cuBackDel' verb to the ITSM server, and is trying to delete a
> DIRECTORY object because the Novell API is now reporting the object as a
> DIRECTORY type from the object attributes. ITSM Server can not process the
> backup delete request as FILE and DIRECTORY objects are
> stored and processed differently within ITSM Server, and the ITSM server
> is looking for a specific named object that is stored as a DIRECTORY.
> Since the object was backed up as a FILE object, ITSM server can not find
> a DIRECTORY object of the specified name, and returns the Abort Reason
> Code of 4, which triggers the ITSM client to fail
> sending the deletion request (ANS1228E), and the cause of the failure in
> sending the deletion request is that the object could not be found on the
> ITSM server (ANS1304W).
>
> The objects stored on ITSM server incorrectly as a FILE object can be
> removed manually, but this will not prevent the issue from happening again
> in the future.
>
> To remove these objects from ITSM Server storage that will not be
> inactivated/deleted during incremental backups, either of the following
> can be done.
>
> 1. Rename the filespace on the ITSM server, and run a full backup from
> ITSM client to create a new filespace. Once a new clean filespace is
> created, customers can delete the old filespace.
>
> 2. Individual objects can be deleted with undocumented delete command
> specifying the specific High Level and Low Level identifiers for the
> object as it is stored in ITSM Server storage. Users would need to contact
> Support in determining the specific HL and LL qualifiers for these
> objects, as well as getting command syntax for delete command.
>
> ITSM cleanup should be done after the customer has acquired a fix from
> Novell to prevent this issue again in the future, so repeated cleanups are
> not necessary. User's reporting this problem should be directed to Novell
> in regards to incident 2642846.
>
>
> ----------
> From: Kamp, Bruce[SMTP:bkamp AT MHS DOT NET]
> Reply To: ADSM: Dist Stor Manager
> Sent: Wednesday, December 10, 2003 2:21 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: NDS Backup error
>
> I am backing up my NDS tree on one server but I keep getting the following
> errors:
>
> 12/09/2003 20:14:52 ANS1228E Sending of object '.[Root].O=SBHD.OU=ICU3'
> failed
> 12/09/2003 20:14:52 ANS1304W Active object not found
>
> 12/09/2003 20:14:52 ANS1228E Sending of object
> '.[Root].O=SBHD.OU=MEMORIAL_CLUBHOUSE' failed
> 12/09/2003 20:14:52 ANS1304W Active object not found
>
> These OU's no longer exist in our NDS tree. Is this a TSM problem or NDS?
>
> The TSM client is 5.1.5.6 on Netware 6 SP2.
>
> Thanks,
> -----------------------------------------------------
> Bruce Kamp
> Midrange Systems Analyst II
> Memorial Healthcare System
> E-mail: bkamp AT mhs DOT net <mailto:bkamp AT mhs DOT net>
> Phone: (954) 987-2020 x4597
> Pager: (954) 286-9441
> Alphapage: 9542869441 AT archwireless DOT net
> Fax: (954) 985-1404
> -----------------------------------------------------
>
>
|
