Customer action required - time should be manually updated through the CLI
Sun StorageTek 6130, 6140, 6540
Sun StorageTek FLX380, FLX280, FLX240, FLX210
Sun StorageTek D280, D240, B280, D178
Controller Firmware
The DST change will have no impact on the controller firmware or operation of the hardware. All time values that are stored by the controller or conveyed via the SYMbol interface are expressed in absolute GMT (Greenwich Mean Time). The time is obtained from the controller's real-time clock and provided in GMT format back to the management interface.
There is no notion of time zone in time stamps or preserved time values in the controller firmware. The management software is expected to translate between such values and the local time zone equivalents.
Management Software
Customers will be using either CAM or SANtricity as the Management Software for these arrays.
See the Storage Software section for information on CAM and SANtricity.
Sun StorageTek 6320
A patch is in development, but will not be available before March 11th 2007
The customer can manually change the time if needed
Impact of not upgrading - The associated event logs (generated on the Sun StorageTek 6320) will be off by one hour for the three week period from March 11 to April 1. Assuming that the servers attached to the Sun StorageTek 6320 have been properly updated, the user should see no visible problems because all end-user time-stamping (such as file date/time stamps) are generated by the host and are stored on the Sun StorageTek6320as simple data like everything else. On Sunday, April 1, the Sun StorageTek 6320 will self-correct, enabling DST.
Sun StorEdge 6910, 3910, 6960, 3960
No customer actions required
The StorEdge 6910, 3910, 6960, and 3960 all use GMT to record log events
The time on the service processor can be set manually if required
There is no impact if the time is not set
Sun StorageTek 6920
Customer actions are required - this issue will be addressed in the future release of Firmware version 3.0.1.26
Firmware version 3.0.1.26 (URB 26) is now available. This upgrade MUST be performed by Sun engineers. Please contact your local support center for further information.
Impact of not upgrading - The associated event logs (generated on the Sun StorageTek 6920) will be off by one hour for the three week period from March 11 to April 1. Assuming that the servers attached to the Sun StorageTek 6920 have been properly updated, the user should see no visible problems because all end-user time-stamping (such as file date/time stamps) are generated by the host and are stored on the Sun StorageTek 6920 as simple data like everything else. On Sunday, April 1, the Sun StorageTek 6920 will self-correct, enabling DST.
Sun StorageTek 9xxx
The Sun StorageTek 9xxx systems include a Service Processor (SVP) that is used by the engineer during the installation, configuration and ongoing management of the system. The clock on the SVP is typically set by the engineer to Greenwich Mean Time (GMT) or to the customer's local time and must never be set to automatically adjust to DST or other similar changes. The change in start/end dates for DST will not affect the operation of these storage systems.
No customer actions required
Sun StorageTek 9900, 9985 NAS Blade
The NAS Blade for the 9990 and 9985 rely upon their NAS operating systems to calculate daylight saving time changes. The required changes are in the 03-07 NAS operating system version that is scheduled for release on February 19, 2007.
See InfoDoc 78884 for details on the Hitachi Software and Microcode order process.
Note that this upgrade must be performed by Sun trained personnel.
These products maintain an internal time of day clock completely independent of any Host based clock. The internal time of day clock of these products must be manually synchronized to local time. This is accomplished via the local or detached operator panel. Keeping the product's internal time of day clock synchronized to the actual local time is a convenience and does not positively or negatively affect the operation of the product.
No customer actions required unless the product is set to local time
Check with your OS vendor to determine if OS patches are required
Sun StorEdge T3, T3+
No customer actions required
The time can be changed manually if required
Impact of not changing the time is that the the time recorded in the logs will be 1 hour off for 3 weeks
Check with your OS vendor to determine if OS patches are required
Key Management Station
The clock can be reset manually. Customers will be contacted and assisted through the process.
Tape Drives (all models)
No customer actions required
Check with your OS vendor to determine if OS patches are required
StorageTek L1400, L700, L180, L80, L40, L20
These products maintain an internal time of day clock independent of any Host based clock. The internal time of day clock of these products must be manually synchronized to local time. Keeping the product's internal time of day clock synchronized to the actual local time is a convenience and does not affect the operation of the product.
No customer actions required unless the product is set to local time
Check with your OS vendor to determine if OS patches are required
StorageTek 9310, 97xx
These products maintain an internal time of day clock independent of any Host based clock. The internal time of day clock of these products must be manually synchronized to local time. Keeping the product's internal time of day clock synchronized to the actual local time is a convenience and does not affect the operation of the product.
No customer actions required unless the product is set to local time
Check with your OS vendor to determine if OS patches are required
StorageTek C2, C4
Customer must reset the time via the operator control panel. See User Manual for instructions
An incorrect time can affect the timing of data backups
Also check with your OS vendor to determine if OS patches are required
Sun StorEdge 6130 Array Host Installation Software for Solaris V1.2 (Original 6130 release)
Runs on Solaris/SPARC Version 8, 9, 10
Uses J2SDK 1.4.2_08 (Java SDK)
Sun StorageTek 6140 Array Management Software 2.1 (Original 6140 release)
Runs on Solaris/SPARC Versions 8, 9, 10
Uses J2SDK 1.4.2_08
Sun StorageTek Common Array Manager (CAM) 5.0, 5.0.1, 5.0.2 (Original 6540 release)
Runs on Solaris/SPARC Versions 8, 9, 10, Solaris/X86 Version 10, Windows
Uses J2SDK 1.4.2_08
CAM 5.1 will ship in February 2007 with the latest Java SDK which fixes this issue.
Customer impacts if changes not applied:
If the customer does not apply the Java fixes to CAM 5.0, 5.0.1 or 5.0.2 or upgrade to CAM 5.1, the time reported by CAM will not change for DST at the right time. This could cause time stamps on logs and/or alarm entries to be off by an hour.
CBEM
Require an update to Java 1.4.2_13
Refer to Java DST Information to update from the Java 1.4.2 image that this product is using.
Data Replication Manager 1.0
Requires an update to Java 1.4.2_13. It is not compatible with Java 5.0. During installation, Java 1.4.2_08 may have been installed depending on the Customer actions during installation.
Refer to Java DST Information to update from the Java 1.4.2 image that this product is using.
Check with your OS vendor to determine if OS patches are required
Removable Media, Library Software/Client System Component (RMLS/CSC)
Gets time from the OS
Check with your OS vendor to determine if OS patches are required
SANtricity
The SANtricity management software relies on the Java Runtime Engine (JRE) to translate GMT into the appropriate time. This calculation involves both the time zone and daylight saving translations. So in order to fix this in SANtricity a new build of host software with the appropriate JRE included must be distributed. This issue is addressed in 1.4 JRE version 1.4.2.11 as well as the 1.5 JRE.
Customer actions required:
Upgrade to SANtricty the latest build of 9.12 or SANtricity 9.19.
The required JRE update has been incorporated into the latest 9.12 and all 9.19 SANtricity builds. If a customer is running either of these builds they will not see any impact of the DST change for any firmware levels they are managing.
Customer impacts if changes not applied:
If the customer is not running one of these builds there should be no material impact. The impact is cosemtic in that email alerts and Major Event Log entries will be off by 1 hour for 3 weeks in the spring and 1 week in the fall. This is due to the fact that the time will be translated improperly by the Java Runtime Engine that is currently in use.
This should not be a material impact; as noted above, all times within the controller firmware are stored in an absolute form. Such values will be incorrect for the three-week period when viewed from SANtricity or other Java-based management software. Additional incorrect timestamps may be seen in diagnostics reports, various component display dialog boxes, and performance monitor.
SDP Appliance
JRE and RedHat Linux upgrade patches to SDP site units are required
Updates will be implemented by SDP engineering over the remote connection
SDS/SVM/SLVM
Gets time from the OS
Check with your OS vendor to determine if OS patches are required
Check with your OS vendor to determine if OS patches are required
Virtualization
StorageTek VTL
StorageTek MirrorStore
FalconStor IPStor
The VTL, Mirrorstore, and IPStor management software relies on the Java Runtime Engine (JRE). The RedHat v7.3 patch and the SUSE v9.3 patch are updates to the JRE. Running the patches will ensure that local time is correctly calculated.
Customer impacts if changes not applied:
If the customer does not install these updates, FalconStor IPStor, Mirrorstor and VirtualTape Library systems will not accurately reflect the correct local time for replication schedules, TimeMark snapshots, log files, reports, and client/server synchronizations. The impact dates will be from March 11th to April 1st and again from October 28th to November 4th. Using Network Time Protocol (NTP) will not resolve these issues. Without the patches, local time values will be incorrect for a three-week period. The values will be corrected once the original DST date of April 1st passes.
Print-friendly Version
