TimeWarp is designed to do just one thing: to allow the testing of user programs and CI scripts within any desired Date and Time, without requiring you to change your system date globally. TimeWarp allows you to specify that a given Job or Session operate under a particular date and Time in one of three ways:
1) User specified.
TimeWarp and 'External' DateTime Calls
Whatever programming language your applications are written in, when they need to retrieve the current system date or time, they will ultimately call system routines located in one of three system libraries: SL.PUB.SYS, XL.PUB.SYS or NL.PUB.SYS. TimeWarp intercepts these calls, and can modify the Date and Time information returned to your applications so that they 'see' a different Date and Time to the 'real' current system Date and Time.
TimeWarp is able to display the names of all 'external' routines (located in any of the system libraries) called by your applications, to aid you in determining how your applications retrieve the system date and time. More importantly, TimeWarp can display the stack-trace leading up to every date and time-related external call; this stack trace identifies the names of (and offsets within) every procedure that your applications call in order to retrieve the system date and time. This can be of significant help in determining where applications reference dates, particularly when they make use of code located inside user libraries (SLs and XLs located in arbitrary MPE groups).
TimeWarp also intercepts attempts by CI jobs, command files and UDCs to retrieve the system date and time, and correctly modifies the values returned so that your command scripts can be tested at the same time as your application programs. TimeWarp also intercepts date and time references performed via the COMMAND and HPCICOMMAND intrinsics, as well as attempts to programmatically retrieve date and time information from system variables (HPYEAR, HPDATE, etc).
TimeWarp integrates smoothly with VESOFT's MPEX enhanced command interpreter, allowing date and time references within MPEX command files to be tested at the same time as your application programs.
Finally, TimeWarp also correctly intercepts attempts by Posix applications to reference date and time information from their Posix environment, and correctly simulates virtual date references from within the Posix Shell.
Taken together, TimeWarp's extremely thorough coverage of date and time related functionality means that you can rely on TimeWarp to run applications in virtual date and time environments that perfectly mimics the way they'll run when the system date is really set to these virtual dates and times.
Before installing TimeWarp, please note the following:
TimeWarp has been tested within MPE/iX 5.0, 5.5, and 6.0 environments.
You should not attempt to install or use the product under other MPE/iX releases without first checking with us.
Once TimeWarp has been installed, you will NOT have to reinstall after updating your MPE/iX version, or installing MPE patches.
If you require technical support during testing or use of this product, please contact the Technical Support Staff of our local distributor:
United States, Canada or Mexico:
OmniSolutions, Inc. (800) 935 0101 http://www.OmniSolutions.com
MiniSoft, Inc. (800) 682 0200 http://www.MiniSoft.com
Europe:
Gainsborough Software (UK) +44 0121 352 0707 http://www.Gainsborough.com
You may also contact SMGA directly:
SMGA (714) 271 1360 http://www.smga3000.com
Installing (or Updating) TimeWarp
1) Logon as MANAGER.SYS and restore the contents of the TimeWarp DAT:
Notes:
- All files are installed into the TimeWarp Account.
- The TimeWarp Account should be password-protected immediately after the SETUP job has completed. Subsequent re-installation of TimeWarp will not remove any password(s) that you've assigned to the Account.
- The SETUP job also installs the WARP UDC system-wide.
All aspects of TimeWarp configuration and management are performed using the WARP command, which is automatically installed as a System-level UDC. Typing :WARP with no parameters displays the following help screen, summarizing all available WARP keywords:
___________________________________________________________________________
| |
| WARP command syntax: |
| |
| :WARP STATUS | HELP | ENABLE | MANAGER | PRINTLOG |
| :WARP TURNON <LogTrace> <DateTime> |
| :WARP TURNOFF <LogTrace> |
| :WARP EXCLUDE | INCLUDE <Program> |
| :WARP DATA <File> |
| |
| Specify Absolute <DateTime> using any of these formats: |
| |
| YYYY/MM/DD HH:MM ... Absolute Date & Time |
| YYYY/MM/DD ... Absolute Date |
| YYYY/MM ... Absolute Year and Month |
| YYYY ... Absolute Year |
| |
| Specify Relative <DateTime> using this syntax: |
| |
| +/-<number> YEARS | MONTHS | WEEKS | DAYS | HOURS | MINUTES |
| |
| Available <LogTrace> keywords: |
| |
| TRACE ... Display DateTime calls to STDLIST |
| LOG ... Log DateTime calls to Logfile |
| STACK ... Include Stack leading to DateTime calls |
| SINGLE ... Only show first occurrence of each DateTime call |
| ALL ... Show all DateTime calls |
| |
|___________________________________________________________________________|
The primary WARP functions are summarized below. They are explained in more detail in the sections that follow.
Most WARP keywords may be combined with other keywords. For example:
After installation, before TimeWarp can be used to switch any Job or Session into a 'virtual' DateTime, you must 'enable' the use of TimeWarp by using the following command:
The WARP ENABLE must be performed after every system restart. You only need to perform WARP ENABLE once after each restart. If you attempt to enable TimeWarp when it's already enabled, you'll see the following:
Displaying TimeWarp Status (WARP STATUS)
To display current TimeWarp status, type the following:
The output format varies according to whether TimeWarp is enabled or not, andwhether a virtual TimeWarp DateTime is currently turned on or not.
Example 1: TimeWarp not currently Enabled:
Turning-On a Virtual DateTime Locally (WARP TURNON)
To switch the DateTime in the current Job or Session to any desired Date or Time, type the following:
When using Relative DateTime specifications, you may specify any number of units of the specified 'base', for example the number of MONTHS is not limited to 12.
Relative <DateTime> specifications are always applied to the current system date to determine the 'virtual' TimeWarp DateTime. If you're currently running in a TimeWarp-controlled virtual DateTime, and you issue WARP TURNON with a relative DateTime, the relative offset will be applied to the current real system date, not to your virtual TimeWarp DateTime. In other words, relative DateTimes are not cumulative.
The <DateTime> parameter, whether specified absolutely or relatively, must lie within the year range 1970 to 2027. Dates outside this range are not currently supported by MPE/iX.
Following use of WARP TURNON, all processes created within the local Job/Session will operate in the specified DateTime, and all Jobs streamed from within the local Job/Session will 'inherit' the same DateTime.
The <DateTime> specification may be omitted if WARP TURNON has previously been used in the current Job/Session. In this case, the previously specified DateTime will be reapplied.
The WARP TURNON command may be issued as many times as required, specifying different DateTimes, if desired.
No special MPE capabilities are required to issue WARP TURNON. It may be used when in BREAK, but may not be used directly from within user programs.
Turning-Off a Virtual DateTime Locally (WARP TURNOFF)
To turn-off TimeWarp within the current Job/Session, type the following:
Turning LogTrace Options On or OFF (WARP TURNON/TURNOFF)
TimeWarp, in addition to allowing you to simulate virtual DateTimes, also allows you to Trace (display on the STDLIST device) and/or Log (write to an MPE file) a record of all calls to DateTime related intrinsics. Tracing and Logging are turned on using WARP TURNON and WARP TURNOFF:
The TRACE and LOG options may be active at the same time, the ALL and SINGLE options are mutually exclusive.
More information about Log and Trace facilities is contained in the relevant section, below.
TimeWarp Manager (WARP MANAGER)
To access the TimeWarp Manager program:
The TimeWarp Manager program uses full-screen character mode. This means that although you are presented with full-screen displays, you still press <RETURN>, or <ENTER> on the main keyboard (rather than <ENTER> on the numeric keypad) to enter data. You will be prompted in 2 different ways. The first way is the Main Menu pop up window. This is very similar to a PC Windows-type drop down menu in that you use the up and down arrow keys to highlight an item and then press <RETURN>. In the second way you are presented with a screen that has various fields that require values. The cursor will highlight each field, and your options for entry will be displayed on the bottom of the screen. If function keys are displayed, whatever options you see are available to you.
Whenever an error message is displayed it will be centered and highlighted; you must press <RETURN> to clear it.
The initial WARP MANAGER Menu screen displays the following options:
This screen displays (by default) information on all users who are currently operating in TimeWarp controlled 'virtual' DateTime environments. The following information is shown for all displayed users:
- JSnum ... Job/Session Number of user
- Parent ... Job/Session from which DateTime was inherited
- Active DateTime ... Current 'virtual' DateTime
- LogTrace ... Current LogTrace options
The screen display is updated automatically every 5 seconds; the update interval may be changed via Function Key 4. Each active Job/Session's virtual DateTime field is updated whenever the screen is redrawn.
LogTrace options are abbreviated to single characters, interpreted as follows:
- F1: Toggles between three display modes:
- F4: Change update interval.
- F8: Return to Main Menu.
WARP Manager: View LogFiles Screen
This screen displays information on all existing LogFiles, located in the LOG.TIMEWARP group.
The following information is shown for all displayed files:
- LogFile ... Name of LogFile, identifying Job/Session number.
- Logon ID ... Name Job/Session logged on as.
- Created ... Real DateTime LogFile created.
- Modified ... Real DateTime LogFile last written to.
Within this screen, Function Keys perform the following functions:
- F1: Deletes all LogFiles.
- F4: View highlighted LogFile.
- F5: Delete highlighted LogFile.
- F8: Return to Main Menu.
WARP Manager: Configure Rules Screen
On entry, this screen displays all configured Logon Rules.
Logon rules allow you to setup any number of rules that are tested whenever any Job or Session logs on. If the Job or Session name matches a particular rule, the associated DateTime is automatically setup as soon as the Job or Session logs on. In addition, any specified LogTrace options are turned on.
A rule consists of both 'Type' and 'Logon ID' fields. If both fields match, then the Rule's DateTime Spec and LogTrace Options are automatically applied.
The following information is shown for each Rule:
- Type ... 'J', 'S' or '@'.
- F1: Add a new Rule.
- F4: Modify highlighted Rule.
- F5: Delete highlighted Rule.
- F8: Return to Main Menu.
A particular rule may be modified by selecting it, and following the dialogue that appears on the next screen. New Rules are defined using the same screen.
With the 'Modify Rule' screen, the following Function Keys are available:
- F1: Save changes.
- F2: Ignore changes.
- F8: Return to Main Menu.
WARP Manager: Configure Exclude Screen
On entry, this screen displays all configured globally Excluded Program files.
Excluding a Program using this screen ensures that it will not be affected by any TimeWarp virtual DateTime settings in any Job or Session on the system.
The only information that is stored is the fully-qualified name of each Program file to be excluded. You cannot use wildcards in this screen.
Within this screen, Function Keys perform the following functions:
- F1: Add a new Excluded Program.
- F4: Modify highlighted Program.
- F5: Delete highlighted Program.
- F8: Return to Main Menu.
A particular Program name may be modified by selecting it, and following the dialogue that appears on the next screen. New Excluded Program names are defined using the same screen.
With the 'Modify Program' screen, the following Function Keys are available:
- F1: Save changes.
- F2: Ignore changes.
- F8: Return to Main Menu.
Displaying Local LogFile contents (WARP PRINTLOG)
To display the contents of the local LogFile:
Tracing and Logging Facilities
TimeWarp can Trace (display on the STDLIST device) and/or Log (write to an MPE file) a record of all calls to Date or Time related intrinsics.
Tracing and Logging are turned on using WARP TURNON, described above.
Trace and Log output is only generated when a virtual TimeWarp DateTime is currently turned on.
1) Standard TRACE/LOG output.
By default, both Trace and Log output record every instance of a call to any Date or Time related intrinsic by generating a single line per call:
When the STACK option is set ON, the stack trace leading up to every call to any Date or Time related intrinsic is also Traced/Logged, for example:
---------------------------------------------------------------------------
CALENDAR (intrinsic)
export stub: 368.00006c00 SHOWCLKS.PUB.DEV/get_mpe_time+$14
SP=41836208 RP=368.00006c50 get_all_times+$20
SP=418361d0 RP=368.000074e8 PROGRAM+$428
---------------------------------------------------------------------------
CLOCK (intrinsic)
export stub: 368.00006c0c SHOWCLKS.PUB.DEV/get_mpe_time+$20
SP=41836208 RP=368.00006c50 get_all_times+$20
SP=418361d0 RP=368.000074e8 PROGRAM+$428
---------------------------------------------------------------------------
HPGMTSECS (intrinsic)
export stub: 149.00083c08 XL.PUB.SYS/time+$34
export stub: 368.00007a48 SHOWCLKS.PUB.DEV/showctime+$10
SP=418361c8 RP=368.00007940 PROGRAM+$880
---------------------------------------------------------------------------
ctime (C library)
export stub: 368.00007a54 SHOWCLKS.PUB.DEV/showctime+$1c
SP=418361c8 RP=368.00007940 PROGRAM+$880
---------------------------------------------------------------------------
When output is being sent to a log file (WARP TURNON LOG has been used), all output from all processes run within the monitored Job/Session is appended to
the same file. To allow output from individual processes to be distinguished from each other, each LogFile line is prefixed by the pin number of the process that generated it. For example:
:WARP TURNON 2002/01 LOG STACK
:RUN COBXX.PUB
:WARP PRINTLOG
Contents of TimeWarp LogFile S00053.LOG.TIMEWARP:
>>>>>> User #S53: MANAGER.DEV,PUB 1998/01/07 22:00:16
68 >>> Logging CI.PUB.SYS 2002/01/07 22:00:16
44 >>> Logging COBXX.PUB 2002/01/07 22:00:41
44 >>> Virtual DateTime: 2002/01/07 22:00:41
44 >>>
44 >>> ---------------------------- HPGMTSECS (intrinsic)
44 >>> export stub: 150.0037d6a0 XL.PUB.SYS/COB_TZ_DATE+$24
44 >>> export stub: 538.000052a0 COBOL.PUB.DEV/datez+$28
44 >>>
44 >>> ---------------------------- CALENDAR (intrinsic)
44 >>> export stub: 150.00378894 XL.PUB.SYS/cr_calendar+$10
44 >>> SP=41836288 RP=150.0037651c COB_DAY_DATE_TIME+$134
44 >>> SP=41836250 RP=150.00375cc0 COB_DISPLAY_SR+$14
44 >>> export stub: 538.000053d0 COBOL.PUB.DEV/datez+$158
44 >>>
44 >>> ---------------------------- CLOCK (intrinsic)
44 >>> export stub: 150.003788bc XL.PUB.SYS/cr_clock+$10
44 >>> SP=41836288 RP=150.0037640c COB_DAY_DATE_TIME+$24
44 >>> SP=41836250 RP=150.00375cc0 COB_DISPLAY_SR+$14
44 >>> export stub: 538.00005418 COBOL.PUB.DEV/datez+$1a0
44 >>>
68 >>>
68 >>> TURNOFF 2002/01/07 22:01:46
68 >>>
In this example, the CI has pin number 68, while the program COBXX.PUB ran with pin number 44.
The LogTrace settings are automatically inherited by jobs streamed from within the active Job/Session.
Disabling TimeWarp System-Wide
To disable TimeWarp, system-wide:
This disables TimeWarp's AIF:PE traps system-wide, immediately. However, it does not affect any other product's use of AIF:PE traps on your system.
You'll need to re-enable TimeWarp using the WARP ENABLE command before TimeWarp can be used again.
Note: Disabling TimeWarp should never normally be necessary: the traps have no effect for any Job/Session unless TimeWarp has been turned on via the WARP TURNON command, or the Job/Session matches one of the logon Rules defined via WARP MANAGER's Configure Rules screen.
Automatic DateTime Inheritance
When a Job or Session is operating in a TimeWarp 'virtual' DateTime, any jobs that are streamed from within the Job/Session will also automatically execute in the same virtual DateTime.
This feature greatly simplifies testing of complex environments, where online applications perform processing by streaming off background jobs.
Such 'nested' jobs are said to 'inherit' the DateTime of the Job/Session that streamed them. When they log on, an extra line appears in the Job's STDLIST indicating that the DateTime has been inherited:
___________________________________________________________________________
| |
| JOB SAMPLE,MANAGER.SYS,PUB. |
| Priority = DS; Inpri = 8; Time = UNLIMITED seconds. |
| Job number = #j55. |
| MON, NOV 17, 1997, 10:48 PM. |
| HP3000 release: C.55.00 User Version: C.55.00 |
| MPE/iX HP31900 C.05.08 Copyright Hewlett-Packard 1987. |
| All rights reserved. |
| STREAMED BY ONOFF,MANAGER.SYS (#J54) ON LDEV# 10 |
| STREAM DATE: MON, NOV 17, 1997, 10:48 PM |
>> | TIMEWARP DATE: SUN, NOV 22, 1987, 11:09 AM (inherited) |
|___________________________________________________________________________|
Similarly, any Jobs streamed from within this Job will Inherit the DateTime settings currently active within this Job. The WARP MANAGER command's 'Console' screen identifies all TimeWarp controlled Jobs, and displays the Job/Session from which they inherited their DateTime settings.
In addition to Jobs, any Sessions that are created by use of the :STARTSESS command from within a 'Warped' Job or Session will inherit the Warped Job or Session's virtual DateTime. An identification line is displayed when such Sessions are created that indicates that the DateTime has been inherited.
When Jobs log on that match logon Rules (setup using the WARP MANAGER command's 'Configure Rules' screen), an extra line appears in the Job's STDLIST indicating that the DateTime is Rule-based:
___________________________________________________________________________
| |
| JOB SAMPLE,MANAGER.SYS,PUB. |
| Priority = DS; Inpri = 8; Time = UNLIMITED seconds. |
| Job number = #j55. |
| MON, NOV 17, 1997, 10:48 PM. |
| HP3000 release: C.55.00 User Version: C.55.00 |
| MPE/iX HP31900 C.05.08 Copyright Hewlett-Packard 1987. |
| All rights reserved. |
| STREAMED BY ONOFF,MANAGER.SYS (#J54) ON LDEV# 10 |
| STREAM DATE: MON, NOV 17, 1997, 10:48 PM |
>> | TIMEWARP DATE: MON, JAN 19, 1998, 12:00 AM (from rule) |
|___________________________________________________________________________|
If a Job would be both a candidate for a Rule-based DateTime, as well as an Inherited DateTime, the Inherited DateTime takes precedence.
Excluding Individual Program Files from being affected by TimeWarp
In the event that you wish to prevent particular programs from being affected by TimeWarp, even when the job or Session in which they're being run is operating in a virtual DateTime, you can do so using either of two available exclusion mechanisms: Local or Global.
To exclude a particular program from being affected by any TimeWarp virtual DateTime within the current Job or Session, issue the following command:
Internally, the WARP EXCLUDE command converts <program> into a SETVAR command, mapping embedded '.' and '/' characters to '_' characters.
Programs excluded using this command are only excluded for the duration of the Job or Session in which the command was issued. The exclusion is not inherited by Jobs streamed from within the current Job or Session.
To reverse the effect of a WARP EXCLUDE command, use the following command:
To globally exclude a particular program from being affected by any TimeWarp virtual DateTime, in any Job or Session, use the :WARP MANAGER command, and select the Configure Exclude option on the Menu screen.
The Globally excluded program list is processed once, whenever a Job or Session logs on. Changes made do not take effect within currently running Jobs or Sessions.
Displaying all Excluded Programs
To display all currently excluded Program files (both Local and Global), issue the following command (without any parameters):
You can also use the :WARP MANAGER command's Configure Exclude option to display the Global exclusion list.
- There are three ways that a Job/Session can operate under TimeWarp's control:
Note that the Date and Time related env variables in the shell represent a snapshot of the Date and Time when the Shell was launched. They are not implemented (under MPE) as active functions.
- TimeWarp integrates seamlessly with VESOFT's MPEX, including the following:
- TimeWarp is not intended to allow the security systems of third-party products to be circumvented. We will work with third party vendors to ensure that TimeWarp is not used to bypass their internal security.
The TimeWarp account contains the following Groups:
So, you've converted all your programs to be Y2K compliant, and you've expanded date fields in all your database, MPE and KSAM files. The only problem is that you don't actually have very much, or any data in them with dates in the new century that you can test against. This is where DataWarp can help.
DataWarp is an add-on module to TimeWarp/3000 that allows you to age any date, in any file. We support dates stored in all types of 32 bit integer fields (I2, J2, K2), as well as in Z6, Z8, X6, or X8 field types. Dates are recognized when stored as named Image item fields, when embedded within Image items, or when located in MPE/KSAM files.
The following date formats are currently supported;
YYMMDD
CCYYMMDD
MMDDYY
DDMMYY
CALENDAR format
HPCALENDAR format
YYMMDD date where YY is an MM3000-style year (2000 represented as 'A0')
MMDDYY date where YY is an MM3000-style year (2000 represented as 'A0')
DDMMYY date where YY is an MM3000-style year (2000 represented as 'A0')
You specify the offset to be applied to dates using the same syntax as TimeWarp uses to specify system date offsets: absolute or relative offsets specified in YEARS, MONTHS, WEEKS and/or DAYS.
DataWarp can perform up to 99 date transformations in a single excution, with the option of only selecting records that match supplied search values.
The DataWarp subsystem operates in either of two modes:
Interactive Mode
In this mode, DataWarp is provided with the name of a previously-built DataWarp script file. It performs the transformation defined in the script file without prompting for any additional input. Script-Driven mode is accessed using the following command:
Within Interactive mode, type '??' at any time for context-sensitive help, describing the input currently being prompted for.
Pressing <Enter> or <Return> at any prompt backs up to the prior prompt level. Default or available values are displayed inside '[]'s, at the end of each prompt.
Entering '/' at any prompt immediately exits DataWarp, without performing any processing.
The Filename prompt will be displayed first:
If you enter a DataBase name, you will be prompted for the Database password, (default is ';' for creator access). You will then be prompted to enter the Image open mode to be used. Default is 1, but you may need to use 3 or 4, depending on your environment.
When a DataBase is being operated on, DataWarp next prompts for the Data Set to be transformed:
When a DataBase is being operated on, DataWarp next prompts for the Data Item to be transformed:
The Data Item prompt includes a loop counter. Up to 99 different Data Items may be transformed in a single WARP DATA run. The program loops back to the Data Item prompt after you have answered the following Date Storage, Format and Offset prompts (see below).
You will next see a menu selection of supported date storage types. Select the option describing the date field that you wish to modify:
Next you'll be prompted for the date offset to apply:
Typing '??' at the Date Offset prompt shows the date offset formats accepted by DataWarp:
DataWarp next prompts for a search value:
For example: 13:8 specifies a date field 8 bytes long, starting at position 13 within the record.
See the section on How Searching Works for a detailed description.
At this stage, DataWarp returns to the 'Data Item' prompt, allowing another Data Item transformation to be specified. Hit <enter> to signal that no further transformations are required.
Finally you will have the option to either Save, Save and Execute, Execute (no save), or Discard (no save, no execute) the script that you just created:
Script-Driven mode is accessed as follows:
There are a number of reasons why it may be valuable to save the DataWarp script. Firstly, it allows later (and repeated) execution. Saving the script also allows the transformation to be easily reversed. If you use a relative offset like +600 DAYS, then it is simple to go and edit the generated script file to -600 DAYS with all other criteria remaining the same, and thus reverse the date transformation.
The search capability within DataWarp allows control over the actual records within a DataSet or MPE file that are modified by DataWarp.
So if you had order records you wanted to test, you could take all records created on a particular date and push them forward into January 2000, and then select all records created on another date and push them forward to December 1999, and then test your application programs with a range that spanned those two months, thus crossing the century in your program logic.
Since many shops "overload" the image definitions of items, we also support the concept of "embedded" dates. This is where you have an image item named something like FILLER-100, and you have a date that you want to search on that starts at byte 31.
Let's assume that the date is stored as a standard ASCII string, then we could specify FILLER-100(31:6) as our search range, assuming a 6 character date.
Understanding how DataWarp Date Offsets Work
If you apply a transform with the intention of reversing the transformation at a later time and returning all date fields to their original values, you should specify the offset in terms of +/- DAYS or WEEKS only.
Any date transformations that are specified in terms of MONTHS or YEARS are subject to end-of-month rounding. While such transformations work, they generally can NOT be exactly reversed at a later time.
In other words, if you specify date offset of +6 MONTHS, don't expect that subsequently applying a transformation of -6 MONTHS will return all dates to their original values. A transformation of +183 DAYS, however, can be exactly reversed by applying a -183 DAYS transformation.
Why is this? Because of the uncertainty implied when taking a date like March 31 and transforming it by -1 MONTH. Do you wish to transform this date to February 28 (or 29), March 3 (or 2), or do you wish to generate an illegal date error?
Using absolute dates can also cause confusion because unless you used search criteria on the date field to restrict it to a particular value, all date fields will be set to the same value regardless of what their original values were, making later reversal impossible.
If an absolute date is used that does not specify the Month and/or Day, then DataWarp will default to the current Month and/or Day at run-time. This might be an issue if you create a DataWarp script and execute it at a later date.
Internally, the DataWarp module relies on features that were added to MPE/iX release 5.5 express 4. Some of these features were 'broken' by HP in express 5, but were fixed again in express 6. All features work in MPE/iX release 6.0.