Herfried,
yes, he did. Maybe you missed it because this was explained in other
thread ("Client shceduler").
If the date is not accepted the server will run as the date/time is not
changed at all and there would be no problem.
Zlatko Krastev
IT Consultant
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: Hi, help me!!
hi,
just a hint : did you issue a "acc date" on the TSM Server ?
-herf
Zlatko Krastev <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 16.05.2002 11:14:21
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: Hi, help me!!
Hi,
was the answer of Tim Rushforth of no help?
Usually pending is for polling mode and means it is time for the schedule
to start but schedule is not yet started due to randomization (according
to server clock). According to node clock schedule is at later time if it
did not contacted server since. Wait for schedprompt interval.
what is the schedmode for the clients? They may need to contact server
once to get new time of the schedule. This new time from node's point of
view is similar to re-schedule. On second attempt they should be fine.
I hope this helps a bit.
Zlatko Krastev
IT Consultant
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Hi, help me!!
Hi, Krastev,
I'm sorry that I'm sending this urgent mail. I don't have nobody to
ask. I have TSM server on AIX. I had to reboot TSM and AIX due to time
zone change. Then I noticed all the client schedules missed. I tested
restarting baclient on one of client node and its event worked, but not
others. When it reaches the scheduled time, it gives status msg
'pending'. Do all baclients need to be restarted to pick up the new time
and start their regular schedules? Thanks for help.
Jin Bae Chi (Gus)
Data Center
614-287-2496
614-287-5488 Fax
e-mail: [EMAIL PROTECTED]
>>> [EMAIL PROTECTED] 05/15/02 05:14PM >>>
Are you able using "dd if=/dev/zero" to create file of this size. If
you
can problem is in TSM. But until then you cannot be sure there is
something in HP-UX settings.
Zlatko Krastev
IT Consultant
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: HP-UX restore problem
We recently ran into an odd problem restoring files to an HP-UX 11.0
system with 4.1.2.0 client software. The TSM server is at 4.2.1.9 and
runs under OS/390. We received the following error messages:
05/05/02 11:57:26 ANS4025E Error processing '/db/tjfrev6/MUMPS.EXT':
file exceeds user or system file limit
05/05/02 11:57:26 ANS4025E Error processing '/db/tjfrev6/MUMPS.EXT':
file exceeds user or system file limit
05/05/02 12:56:15 ANS4025E Error processing
'/db/tjfserv6/MUMPS.EXT':
file exceeds user or system file limit
05/05/02 12:56:15 ANS4025E Error processing
'/db/tjfserv6/MUMPS.EXT':
file exceeds user or system file limit
We discovered that each of the restored files was 2,147,483,136 bytes
long. The dsmsched.log entries for the backups of the files were still
around, and showed a length of 2,147,483,647 bytes for each of the
files,
which is 511 bytes more than the length of each of the restored files.
The
original length turns out to be 2**31-1. The HP-UX administrator
contacted
HP, who had him check a variety of system settings. After reviewing
the
settings HP was adamant that there was nothing in the system
configuration
to prevent TSM from writing files of the original length.
The restore process had one unusual feature. When the files were backed
up
/db/tjfrev6 and /db/tjfserv6 were file systems. When the files were
restored
/db/tjfrev6 and /db/tjfserv6 were ordinary directories within the /db
file
system.
The loss of 511 bytes had no visible effect on the application that
used
the
files. This is not quite as surprising as it sounds. The application
treats
each of its database files as a collection of 2048 byte blocks. The
original
length would have included 2047 bytes that did not fit into a block.
Even
though we dodged the bullet in this case, we are worried about running
into
this problem in the future. Is this a known problem?
