JUMP/3000 is a new commercial product that allows HP3000 systems
to continue running for a full 10 years past their current hard-coded
end-of-life on 2027/12/31.
JUMP/3000 can be used by HP3000s running on HP hardware, as well
as on Stromasys Charon virtual HP3000s.
The HP3000 operating system has a hard-coded limit beyond which
the system date cannot be set: 2027/12/31. User programs typically make use of
date-related intrinsic calls with the same limitation.
The limit affects systems running on HP hardware, as well as
Stromasys Charon emulators. It’s primarily due to the
widespread use of the ‘Calendar’ intrinsic, which stores dates using a 16-bit
format with inherent limits.
Currently the only way to continue using HP3000s after 2027 will
be to set the system date to a prior value. This ‘solution’ is highly
problematic, not only because of the complete disruption of all date-related
processing, but also because it greatly complicates the near-universal practice
of backing up systems using a combination of full and periodic incremental
backups.
The JUMP/3000 product provides a full 10-year extension to the
HP3000’s lifespan. It allows the system date to seamlessly wrap from
2027/12/31 to 2028/01/01, and to continue running through 2037/12/31.
JUMP/3000 offers a totally transparent solution: MPE command
interpreter (CI) commands and intrinsics are modified to work with the extended
system date. Application programs and third-party utilities that rely on system
intrinsics and language run-time support libraries will also keep working after
the end of 2027.
Your HP3000 can be started up into any date through 2037/12/31;
the system date can also be changed at any time using the
:SETCLOCK command. File system timestamps correctly reflect post-2027
system dates.
JUMP/3000 provides the most complete solution for extending the
life of your HP3000. It includes support for all date-related Intrinsics, CI
commands and variables, and for the :STORE command’s
selection of files by access or modify date.
JUMP/3000 is also the only post-2027 solution that is available
for installation on your own HP3000 hardware, including Stromasys Charon HP3000
emulators[1].
It can be licensed annually, or through the end of any year between 2028 and
2037. It also doesn’t force you to accept bundled hosting or support services.
Internally the HP3000 uses two primary mechanisms to keep track of
dates:
1)
Signed 64-bit timestamps that track
microseconds-since-1970.
This timestamp format is able to represent dates through the end of 2037
without change.
2)
16-bit 'Calendar' format timestamps,
containing two sub-fields:
YEAR (years-since-1900) : 7 bits long, covering the range 0..127
DAY (day-of-year) : 9 bits long, covering the range 0..511
The YEAR
field is able to represent years up to 27 relative
to 1900, covering the range 1900 to 2027.
Changing
the definition of this field allows it to represent years in the range 1910 to
2037:
Values in the range 10..127 continue to be
interpreted as 'years since 1900'.
Values in the range 0..9 are now interpreted as 'years since 2028'.
Existing Calendar and 64-bit system
timestamps (e.g. file creation and access timestamps) remain valid with this
change.
JUMP/3000 implements the modified
Calendar format using several different techniques to allow it to intercept and
modify all date references made by the MPE/iX operating system, and by all
programs running on a system.
Several low-level date system routines in the system library
(NL.PUB.SYS) are patched to support the modified Calendar format, and to allow
the system date to be set post-2027.
The patch is created using the same process used by HP when
developing operating system patches.
Installing the static patches uses the standard method of creating
a modified system load tape (SLT), and then updating the system from this tape[2].
JUMP/3000 static patches can also be also installed using Stage/iX.
Dynamic patching uses a low-level run-time interception method supported on the HP3000. It uses an HP-supplied mechanism called Procedure Exits (also known as AIF:PE), and allows interception of date-related calls made by user code, without the risk and extensive work involved in patching the system library.
JUMP/3000 Dynamic patches are implemented without making any changes
to library or program code. They are
activated by running a supplied program once during system startup. Once
activated they remain in effect until the system is next rebooted.
The HP3000 supports two code environments. Native Mode (NM) code uses the native 32-bit system libraries, while Compatibility Mode (CM) supports the legacy 16-bit environment provided by the original 'Classic' HP3000 architecture. The static and dynamic patch components allow JUMP/3000 to intercept date references made from NM and CM code.
The combination of interception
methods provides the simplest, lowest overhead, most reliable, and most
comprehensive solution. JUMP/3000 Static patch replacement routines are highly
efficient, and execute at the same speed (or faster) than the original date
routines they replace.
JUMP/3000 Dynamic patches have a marginally higher run-time
overhead, but are not used to intercept internal date calls made by the operating
system. Their overhead is acceptable in view of their much lower typical usage.
JUMP/3000 is designed so that it has no visible effects on a
system, other than enabling dates after 2027 to be used. It can be installed on
systems prior to 2028 with no problem.
JUMP/3000 allows post-2027 dates to be specified during system
startup:
|
Scanning PCI Bus
E0 ................................ |
The year can also be specified using 4 digits.
JUMP/3000 has a built-in demonstration mode that exercises many
date-related MPE commands, programs, and intrinsics. This can be used to
quickly verify all functionality.
Demo mode output is shown below – it shows annotated examples of
MPE commands and error messages that have been modified to function post-2027.
HP3000 command interpreter (CI) commands used are highlighted. It also includes
examples of making CM and NM intrinsic calls, and running CM and NM programs.
Demo mode output shows the real, unmodified output of these
commands and calls; it is not a simulation.
|
:jump demo |
The :JDATE command
is supplied to facilitate moving the system date when testing.
JDATE allows the year, month, and/or date to be changed without
also having to specify the full date and time every time. Year, month, and date
can be specified in absolute or relative terms.
|
:jdate ? |
JDATE with no parameters returns to the initial date.
JDATE is implemented as a wrapper for the
:SETCLOCK command. It specifies ;NOW when calling :SETCLOCK,
and preserves the current system time, rounded to the nearest
second.
|
:showtime |
You can also use JDATE to change the month and/or date. If you
attempt to change the date to an illegal value the command will fail with :SETCLOCK’s generic error message.
|
:jdate , +2, 15 |
It has been mentioned that JUMP allows the system clock to
smoothly roll over from 2027/12/31 to 2028/01/01. This display shows the output
of a :WHILE loop that calls
:SHOWCLOCK, followed by a 10 second pause. It shows just how uneventful
this transition will be with JUMP/3000.
|
SYSTEM TIME:
FRI, DEC 31, 2027, 11:59:11 PM |
Modifying the HP3000 operating system to handle post-2027 dates is
a significant part of keeping your system running, but it does not guarantee
that every user program and third-party product will be usable without
modification post-2027.
Programs can have hard-coded date limits; they may also directly
manipulate Calendar timestamps and their sub-fields. If they’re not aware of
the change to the Calendar format, they could interpret years in the range 2028..2037 as 1900..1909.
Unmodified software could interpret a Calendar field containing
Year=9 as 1909 or possibly 2009, instead of the correct 2037 value.
Programs that compare dates by treating the Calendar timestamp as
a 16-bit integer will give incorrect results when comparing years in the range 2028..2037 with dates prior to 2028.
Even though JUMP’s post-2027 patches are not a panacea, it does
provide a stable platform for an HP3000 to be used post-2027. Users will need
to carefully test their programs and third-party applications to verify their
correct functioning, and be prepared to make modifications if necessary.
It is entirely possible that testing may reveal some aspects of
the operating system where dates are incorrectly formatted post-2027. We are
not able to give a 100% guarantee that every possible command and programming
interface will work correctly post-2027.
We are aware of only one area where post-2027 dates are currently
not displayed correctly:
1)
Spooler :LISTSPF command
and output.
Not currently patched to display post-2027 dates correctly.
It is crucial that you have appropriate expectations before using
JUMP/3000.
You must be prepared to perform comprehensive testing of all
in-house and third-party software to verify correct functioning post-2027, and
to make changes if necessary.
It is possible you will encounter problems with some third-party
utilities; you may need to obtain updated versions of these utilities, or be
prepared to work-around problems using these utilities.
Testing JUMP/3000 requires temporarily setting the system date to
post-2027 values. This will obviously disrupt routine system operations.
Ideally you should have access to a test system to performing testing.
JUMP/3000 has been developed and tested under MPE/iX 7.5. It works
on HP3000s running on HP hardware, as well as on systems running Stromasys’
CHARON emulator.
Both static and dynamic JUMP/3000 patch components are designed to
be largely independent of the MPE/iX version. They should run on systems
running MPE/iX versions 6.5 through 7.5.
JUMP/3000 was created by an HP3000 developer of long-standing. He
has worked as a software developer for several of the most prominent HP3000
third-party vendors, including Bradmark, Vesoft, Quest Software, Orbit, and
Informatica.
He has extensive experience using dynamic patching techniques to
modify the HP3000 operating system behavior in significant ways. Software
developed by him was at one time installed on several tens of thousands of
HP3000 sites.
He created the TimeWarp virtual date testing product in 1999.
TimeWarp allowed users to test system and application behavior post-Y2K, back
when this was a significant issue. This product intercepted many of the same
operating system date routines that are used by JUMP/3000, and formed the basis
for initial work on this project.
He was the Stromasys HP3000 Business Manager during the
development of Charon-HPA/3000, and has extensive experience as a developer
using the Stromasys emulator.
He is still active as a developer, and intends to continue
developing and supporting JUMP/3000 in the future.
Resume is available at https://ptaffel.com/Detail
Paul Taffel
[2] Stromasys
Charon emulators support virtual tape drives; this is the preferred way to
update these systems.