10-10-2019 08:28 AM
I cannot find the following corresponding status code in the latest NBU 8.1.2 status code reference guide!
1) So what mean about the status code 0/9/14/22/42 for robotd/vnet_connect_to_service?
17:26:07.684 [28059] <16> robotd_connect: vnet_connect_to_service(jchxbak, tldcd) failed: 14
17:26:07.684 [28059] <16> robotd_connect: unable to connect to tldcd: Error 0 (0)
17:26:07.685 [28059] <16> robotd_connect: cannot connect to tldcd on host jchxbak: cannot connect to robotic software daemon (42)
17:29:21.577 [28060] <16> robotd_connect: vnet_connect_to_service(jchxbak, tldcd) failed: 9
17:29:21.578 [28060] <16> robotd_connect: unable to connect to tldcd: Invalid argument (22)
17:29:21.578 [28060] <16> robotd_connect: cannot connect to tldcd on host jchxbak: cannot connect to robotic software daemon (42)
17:29:21.589 [28062] <16> robotd_connect: vnet_connect_to_service(jchxbak, tldcd) failed: 9
17:29:21.589 [28062] <16> robotd_connect: unable to connect to tldcd: Invalid argument (22)
17:29:21.589 [28062] <16> robotd_connect: cannot connect to tldcd on host jchxbak: cannot connect to robotic software daemon (42)
17:29:21.590 [28061] <16> robotd_connect: vnet_connect_to_service(jchxbak, tldcd) failed: 9
17:29:21.590 [28059] <16> robotd_connect: vnet_connect_to_service(jchxbak, tldcd) failed: 9
2) And also what mean about status code 328 with EMM_ERROR_SQLNoDataFound(2007031) ?
17:52:37.308 [8199] <6> WriteEntry: Updating drive HP.ULTRIUM5-SCSI.008 at path /dev/rtape/tape212_BESTnb on attach host
17:57:34.285 [8199] <16> emmlib_SetRobotStatus: (0) The parameter RobotPath is empty... assuming we are setting robot state
17:57:34.286 [8199] <16> emmlib_SetRobotStatus: (0) Host < sccmsrst >, RobNum < 3 >, RobotStatus < 1 >
17:57:34.286 [8199] <16> emmlib_SetRobotStatus: (0) NdmpHost < >
17:57:34.300 [8199] <16> emmlib_SetRobotStatus: (0) UpdateLibrary failed, emmError = 2007031, nbError = 0
17:57:34.319 [8199] <16> ROBOT_CONNECT: (-) Translating EMM_ERROR_SQLNoDataFound(2007031) to 328 in the device management context
17:57:34.319 [8199] <16> RobotConnect: emmlib_SetRobotStatus() failed for robot 3 with error 328
17:57:34.319 [8199] <16> RobotConnect: Updated robot
17:57:34.319 [8199] <2> RobotConnect: Received Type=2 message from TLD(3), RobotConnect continuing
17:57:34.319 [8199] <16> emmlib_SetRobotStatus: (0) The parameter RobotPath is empty... assuming we are setting robot state
17:57:34.319 [8199] <16> emmlib_SetRobotStatus: (0) Host < sccmsrst >, RobNum < 0 >, RobotStatus < 1 >
17:57:34.319 [8199] <16> emmlib_SetRobotStatus: (0) NdmpHost < >
17:57:34.333 [8199] <16> emmlib_SetRobotStatus: (0) UpdateLibrary failed, emmError = 2007031, nbError = 0
17:57:34.333 [8199] <16> ROBOT_CONNECT: (-) Translating EMM_ERROR_SQLNoDataFound(2007031) to 328 in the device management context
17:57:34.333 [8199] <16> RobotConnect: emmlib_SetRobotStatus() failed for robot 0 with error 328
17:57:34.333 [8199] <16> RobotConnect: Updated robot
17:57:34.333 [8199] <2> RobotConnect: Received Type=2 message from TLD(0), RobotConnect continuing
17:57:34.333 [8199] <4> LtidProcCmd: Informing RB to unload drives
17:57:34.341 [8199] <16> emmlib_SetRobotStatus: (0) The parameter RobotPath is empty... assuming we are setting robot state
17:57:34.341 [8199] <16> emmlib_SetRobotStatus: (0) Host < sccmsrst >, RobNum < 0 >, RobotStatus < 1 >
17:57:34.341 [8199] <16> emmlib_SetRobotStatus: (0) NdmpHost < >
17:57:34.354 [8199] <16> emmlib_SetRobotStatus: (0) UpdateLibrary failed, emmError = 2007031, nbError = 0
17:57:34.354 [8199] <16> emmlib_SetRobotStatus: (0) The parameter RobotPath is empty... assuming we are setting robot state
17:57:34.354 [8199] <16> emmlib_SetRobotStatus: (0) Host < sccmsrst >, RobNum < 3 >, RobotStatus < 1 >
10-10-2019 08:45 AM
I would think that not all are documented.
The problem with status codes is that sometimes they are from the operating system, sometimes they are from third party APIs (e.g. VMware), sometimes they are vendor specific (e.g. QLogic, LSI, Hitachi, NetApp, etc), sometimes they are published NetBackup core codes, sometimes they are undocumented NetBackup core codes, sometimes they are NetBackup CORBA codes, sometimes they are NetBackup Volume Manager codes. Yes, sometimes a NetBackup core code is not the same as a NetBackup Volume Manager code. Sometimes some longword (long-integer, 32-bit) codes are shown in decimal form, and you have to first convert back to Hex to be able to google for anything meaningful.
Sometimes it is obvious where a code comes from, e.g. a "Win32 <code>" is definitely Windows. Sometimes command "bperror -S <number>" might seem to reveal something relevant to NetBackup - but, at then end of the day, one can never be sure where the status code has come from if the associated text is ambiguous and not specific, and sometimes the error message text comes from third parties and so the ambiguity is not always Veritas fault.
FYI - some links:
https://docs.microsoft.com/en-gb/windows/win32/debug/system-error-codes--0-499-?redirectedfrom=MSDN
I'm sure you find a list of Linux and/or Unix satus codes somewhere.
10-10-2019 03:51 PM
The logs you have provided are indicating some problem with the configuration of you robot and tape drives.
Have a look at the following two articles to see if they assist in fixing the problems.
https://isearch.veritas.com/internal-search/en_US/article.100022496.html
https://isearch.veritas.com/internal-search/en_US/article.100026843.html
If these do not help, the next step may be to remove all references to existing robots and tape devices
(refer to nbemmcmd -deletealldevices command)
and then use the wizard in the GUI to reconfigure evrything again.
10-10-2019 07:16 PM
The above https links just come from the internal website of veritas, so I cannot open them!
Could you please copy and paste them in my this post ?
10-10-2019 09:06 PM
My apologies - I was looking internally and forgot to get the equivalent public links - try these
https://www.veritas.com/support/en_US/article.100022496
https://www.veritas.com/support/en_US/article.100026843
10-11-2019 12:26 AM
Thanks !
But it's so strange that the symptom disappeared after we restarted the netbackup services for some times without changing any configurations .