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 [EMAIL PROTECTED] -------------------- 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:[EMAIL PROTECTED] > Reply To: ADSM: Dist Stor Manager > Sent: Wednesday, December 10, 2003 2:21 PM > To: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > Phone: (954) 987-2020 x4597 > Pager: (954) 286-9441 > Alphapage: [EMAIL PROTECTED] > Fax: (954) 985-1404 > ----------------------------------------------------- > >
