During a full backup of a Microsoft Exchange DAG cluster, the backup operation fails when executed from one specific node. The error reported is:
ANS1243E (RC119) The file name is too long and cannot be processed by IBM Storage Protect.
ACN5060E A IBM Storage Protect API error has occurred. Examine the Windows Event Logs and DSMERROR.LOG for additional details.
The same Exchange database can be backed up successfully from other nodes in the DAG cluster.
- The backup fails with return code 119 (ANS1243E) and API error ACN5060E.
- The issue is specific to one node in the DAG cluster.
- The problem occurs only during full Exchange DB backups.
- Trace output reveals
Win32 RC = 234 is returned by the API public function GetVolumePathNamesForVolumeName().
The failure is caused by an error returned by the internal API function getVolumeNameForMountPoint(), which invokes the Windows function GetVolumePathNamesForVolumeName().
This Windows API function retrieves all the mount paths (e.g., drive letters like D:\ or mount folders) associated with a given volume. If the buffer provided by the Operating System (here: Windows) is too small, it returns Win32 RC = 234 (ERROR_MORE_DATA).
In this case, the function fails to retrieve the full list of mount paths due to an insufficient buffer size, which is translated internally to IBM Storage Protect API RC = 119. This prevents the Data Protection for Exchange backup from completing successfully.
All IBM Storage Protect for Mail - Data Protection for MS Exchange
1. Enable tracing on both the Data Mover and Data Protection for Exchange components using traceflag ALL in dsm.opt used by Data Protection
2. Look for the following entries in the API trace (here a generic example):
getVolumeNameForMountPoint(): mountPath='d:_ex_db\dag01_db001'
GetVolumePathNamesForVolumeName() returned Win32 RC = 234
Translated Win32 RC 234 (0x000000ea) from getVolumeNameForMountPoint(): GetVolumePathNamesForVolumeName to TSM RC 119
3. Review the Data Protection trace which will show the backup request failing with RC 119 for the affected database instance.
To verify the issue and check whether the mount path has an underlying problem:
1. Manually navigate to the indicated mount path (for example from previous trace abstract: d:_ex_db\dag01_db001) in File Explorer and check for access errors.
2. Run the following PowerShell commands (adjusting for the correct drive letter or mount point):
Get-Volume -DriveLetter D | Select-Object DriveLetter, Path
Get-Partition -DriveLetter D | Get-PartitionAccessPath
mountvol
If these commands return errors (especially Win32 RC = 234 or access issues), the problem likely lies in the system configuration of that node (e.g., missing or inconsistent mount points, insufficient permissions, corrupted volume info).
3. As this is an Operating System level issue, you should engage Microsoft Support for further investigation and potential resolution regarding the mount point behavior on the affected DAG node.
[{"Type":"MASTER","Line of Business":{"code":"LOB69","label":"Storage TPS"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSGHT2","label":"IBM Storage Protect for Mail"},"ARM Category":[{"code":"a8m3p000000hAZtAAM","label":"API"}],"ARM Case Number":"TS016594677","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.1.19;8.1.20;8.1.21;8.1.22"}]