 |
|
TAMS Year 2000 info for SRM/UX & BASIC
Year 2000 NotesSRM/UX - For systems running SRM/UX two elements need to be examined for Y2K problems. 1. HP-UX Operating System Series 700/800: HP-UX releases beyond version 10.20 are Y2K safe. Series 300: The Series 300 does not support HP-UX 10.X so to be Y2K safe, a patched HP-UX 9.10 is required. This is available from TAMS. 2. SRM/UX SRM/UX versions F, G, H & J are Y2K safe. This product works on Series 300 HP-UX 9.10, Series 700 HP-UX 10.20 & 11.x, and Red Hat Linux 6.x, 7.1, & 7.2. CLIENTS 1. BASIC/WS: The Y2K compliant version of HP BASIC/WS is 6.4. This update may be purchased from TAMS as an upgrade from any previous version of HP BASIC/WS. 2. BASIC/UX 700 Version 8.02 is Y2K safe. 3. BASIC/UX 300 The current version of Basic/UX 300 is 6.5 and is Y2K safe. This is available from TAMS. 4. Network Clock Synchronizer E2085-18010 This BASIC Workstation to SRM/UX network clock synchronizing software which was distributed in January ‘94 to all SRM/UX customers with HP materials support contracts has been analyzed and tested, and found to be Y2K safe. Year 2000 Product Table
Last modified: October 18, 2005 (Reprint from Hewlett-Packard Test System News, Issue No. 6 - September 1997) Are Your HP BASIC Applications Year 2000 Safe?As the year 2000 approaches, people who work with computers in any capacity are increasingly asking the question - are my applications Year 2000 safe? Like most important questions the answer is more complex than a simple yes or no - it depends on several factors. First, any time two digits rather than four are used to represent a year there is a risk. Most people will explain the Year 2000 problem as a throwback to the days when computers had very limited memory, and therefore two digits were used rather than four. However, we usually write the date as 6/6/97 even on paper, so it's a human problem, not a computer problem. In looking forward to the Year 2000, you should consider two major factors: system (i.e., computer clock, operating system, utilities and language) and application software. System: Whether an operating system will experience problems depends a lot on how the computer's clock stores the date. In this regard, some early computers may be at risk. When HP released HP BASIC 6.3, one of the improvements it instituted was to allow dates beyond February 29, 2000 to be set in the computer's battery backed clock. The fix extended the date range to December 31, 2069 (don't let it creep up on you!). If you have an version earlier than 6.3, rebooting after Feb. 29th will show the system date as 1900. You will have to have your program or operator change the date each time you reboot. When you attempt to set the date to March 1, 2000, the system will give a warning that the battery backed clock was not set. Despite the warning, the system clock will run correctly until you turn the system off. HTBasic for Windows is year 2000 compliant, so no changes are required. HP BASIC/Workstation (6.3 and earlier) has an anomaly in the CAT string which causes the year 2000 to show as *0, 2001 as *1, etc, rather than 00 or 01 on HFS or SRM listings. The anomaly does not exist for LIF discs. This anomaly can cause errors in programs that read the catalog on a drive. Version 6.4, available from TAMS, fixes this problem. See the "Applications" section below for issues related to porting to this release. TAMS completed a review of SRM/UX and the newest release, which is now shipping (E2085G) is Year 2000 safe. In addition, the SRM/UX client extensions for BASIC/UX 7.0 and 8.0 contain the necessary changes to make those versions of BASIC/UX Year 2000 safe. While system issues are usually considered to be the manufacturer’s problem, responsibility for applications lies with the developer. Most test & measurement applications were written by users, so the software is obviously as diverse as its creators and their individual problems. The main concern will be whether math on dates will perform as expected, both in the Year 2000 and beyond. A simple example might be storing results if they are more recent than the ones already stored. For example, it is easy to do a simple comparison between 96 and 97 and know that 97 is greater. But when comparing 99 to 00, 99 looks bigger. How individual software was written will determine what needs to be corrected, but wherever time or date computations are done, there could be a problem, so software needs to be checked. When moving an application from a BASIC/WS version earlier than 6.x, several compatibility issues will arise. In particular, CSUBS will need to be rebuilt and upgrades may need to be purchased for sophisticated tools like compilers. We know there are some tools that were available for earlier versions that are not available in a 6.x version. We recommend you attempt to upgrade as soon as possible so that you will have time to explore your options. CSUBS for RMB/UX While CSUBS built for BASIC Workstation 6.2 and 6.3 will run with BASIC/WS 6.4, CSUBS built for RMB/UX much match versions exactly. In other words, if you are moving from RMB/UX 6.4 to RMB/UX 6.5, the CSUBS will not match and new versions will have to be obtained. In the next few years, it would be wise to have a support or update contract, because many revisions are likely to solve Year 2000 problems. The good news is that there is still time to make the changes necessary to cross into the next millennium. Tools to help with Year 2000:Enhanced Lister & XREF - These programs are designed to help programmers document and debug BASIC programs. To learn more about these programs please see the datasheet. TAMS Year 2000 Warranty StatementsHP-BASIC/WS Warranty Statement |
 All referenced prices are United States Dollars. Copyright © 1997-2003 Test & Measurement Systems Inc. Other products and companies referred to herein are trademarks or registered trademarks of their respective companies or mark holders. Specifications are subject to change without notice. Test & Measurement Systems Inc. Tel: + 970-669-6553 |
| Last Updated: 18 October, 2005 |
