ADSM-L

Re: ANE4014E unknown system error

2003-05-28 07:27:38
Subject: Re: ANE4014E unknown system error
From: Maria Ilieva <m.ilieva AT MOBILTEL DOT BG>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 28 May 2003 14:23:49 +0300
You're right.
The client compression is turned on. But here is my include/exclude list for
the problem node:

exclude.compression /.../*.gz
exclude.compression /.../*.Z

include.archive /usr/sap/tsm/data/.../*         SAP-DBF
include.archive /usr/sap/tsm/arch/.../*         SAP-ARCH

So the compression for files with extensions Z and gz is turned off.

In dsmerror.log there are only three entries for the time of archive:

05/28/03   02:24:39 ANS1228E Sending of object
'/usr/sap/tsm/data/bdksqhih/poold.data1.Z' failed
05/28/03   02:24:39 ANS4014E Error processing
'/usr/sap/tsm/data/bdksqhih/poold.data1.Z': unknown system error (157)
encountered.  Program ending.
05/28/03   02:47:19 ANS1803E Archive processing of '/usr/sap/tsm/data/*'
finished with failures.

Nothing different from the archive log :(

Maria Ilieva

----- Original Message -----
From: "Richard Sims" <rbs AT BU DOT EDU>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Wednesday, May 28, 2003 2:09 PM
Subject: Re: ANE4014E unknown system error


> >I receive the following error occasionally, while performing an archive:
> >
> >ANS1228E Sending of object '/usr/sap/tsm/data/bdksqhih/poold.data1.Z'
failed
> >ANS4014E Error processing '/usr/sap/tsm/data/bdksqhih/poold.data1.Z':
unknown
> >system error (157) encountered.  Program ending.
> >
> >It fails at different files for the same node. Client upgrade to the
latest
> >level do not help.
> >Does anybody know what is the reason to receive that error?
> >
> >TSM server 5.1.6.5 on AIX 4.3
> >TSM client 5.1.6 on AIX 4.3
>
> Maria - I would first check your client dsmerror.log for supplementary
info
>         which may help explain the situation.  The high error number is
bogus
> and should not be reported by the client (defect).
>
> Beyond that: I notice that the quoted file has a .Z suffix, meaning (or
should
> mean) that it was the subject of a 'compress' command.  If all the
failures
> are on compressed files, I wonder if client compression is turned on, and
> some issues in buffer handling are occurring as the file actually expands
> during the secondary compression.
>
>    Richard Sims, BU
>

<Prev in Thread] Current Thread [Next in Thread>