Jampack Software Changes

Jampack is now qualified for use on MCP 54.1 and later; this change prevents the display of MCP warning messages.

If consecutive JAMPACK initiated RESERVE commands were rejected by the MCP because of syntax, JAMPACK will now abort instead of trying to continue,and often issuing the same failed command continuously. The following message will be displayed:

  JAMPACK ABORT:CONSECUTIVE RESERVE JOBS HAVE FAILED SYNTAX

JamPack now gives a more informative message when a checkerboard is created. It will also handle larger numbers of rows in the range.

An optimization has reduced JamPack's elapsed time by about 4 seconds per RESERVE or report.

If a bad title is detected in a header, the CheckerBoard report will now indicate:

>> Bad Title <<

JamPack can now produce a readable CheckerBoard report similar to the one in *SYSTEM/FILEDATA. However, the report is produced typically in just 5% of the Elapsed time that FileData uses and only 2% of the CPU time. Also, unlike FileData it reports not only on Permanent file in the SYSTEMDIRECTORY, but on temporary files as well as many other types of disk usage.

The syntax is:

<Family> # <Inx> SEG <Address> FOR <length>

For example: DISK #2 SEG 1000000 FOR 10000

If # <inx> is omitted #1 is assumed.

The report is produced in a permanent disk file called CHKBD, which can be Label-Equated. Each row has a line in the file of the format:

<start> <hyphen> <end> <fixed> <flags> <row type>

where <start>. and <end> are the start and end addresses

      <hyphen> is a space for a single row, or a '-' if there are
      multiple contiguous rows of the same file.
      <fixed> is normally a space, but is 'F' if the row would block or
      otherwise give problems to a RESERVE.
      <flags> is normally space, but is 'T' if the file is temporary,
      and 'O' if the file is in use.
      <row type> is either a FILENAME or one of the following:
         >> Label << - The unit label area (at address 0 to 27)
         >> Olay Row << - An overlay row (only on DL OLAY family)
         >> MCP Info << - The Mem Dump workspace (only CM'ed Families)
         >> Unavailable << - Areas that are in use, but which are not
                             known to RESERVE.
         >> Job File << - A job in the live JOBDESC (on DL JOBS family)
         >> Obsolete Job << - Rows in an obsolete JOBDESC, which should
                              be removed.
      For example:

      0 27       F  >> Label <<
     28-4027      O *SYSTEMDIRECTORY/001
   4093 4597        (SHAFT)METALOGIC/MG

Jampack will now use a simpler interface to Magus.

The MCP interfaces have been simplified so Jampack no longer has any INCLUDEs.

These changes reduce the Jampack symbol by 200 cards and the images compiled by about 1000.

Jampack is now qualified for use on MCP 5.3

Use Include/Meta

Version 510.01 of Jampack is compatible with MCP 5.2 but gave incompatibility warnings. This change changes the maximum MCP check to use MCP 5.2.

Confirm compatibility with MCP 5.1

Previously, if a manual SQUASH or RES command was input for a disk family that was currently being processed by JAMPACK, JAMPACK could fault with a DIVIDE BY ZERO @ 34380000 or hang indefinitely waiting for a RESERVEDISK to complete that had already failed because of the above. In the latter cases, the JAMPACK RESERVEDISK would fail with SYNTAX and its EOJ not always being detected correctly.

Both these issues have been addressed. If a running JAMPACK detects that a manual RES or SQUASH is already active for same family the JAMPACK will gracefully terminate with:

RESERVE OR SQUASH IS ALREADY RUNNING ON <FAMILYNAME>

If JAMPACK detects a RESERVE that has failed with SYNTAX, the following message will be displayed:

RESERVEDISK JOB NNNNN HAS FAILED WITH SYNTAX

If possible, JAMPACK will attempt another RESERVEDISK but, in most cases, this message will be seen if another SQUASH or RESERVE is already active.

Dnote JAMPACK 500.01 Confirm compatibility with MCP 5.0

Confirm compatibility with MCP 5.0

JAMPACK has now been updated for MCP 49.1 to relax the warning messages seen on earlier MCP versions.

Previous versions of Jampack would give an error if a target area > 7 digits was requested. Metalogic still recommend that 7 digit targets should not be exceeded, but a warning is now given instead of an error. The new limit is now 549755813887, the maximum size of an integer allowed on MCP systems.

Previously, JAMPACK would reject requests for individual family indices greater than 99. This restriction has been removed and index values up to 255 (the MCP maximum) are permitted.

Although JAMPACK has been qualified for use on MCP 48.1 for some time now, any JAMPACK run on this level was giving misleading warnings about MCP qualification. This warning has now been removed.

Dnote 470.03 did not quite fix the described problem because the MCP version checking was not correctly including the patch level. This problem is now fixed

Patch 470.02 inadvertently caused JAMPACK to F-DS with integer overflow when checking MCP levels. This fault has now been fixed.

MCP 46.189.8633 introduced a bug which would stop Jampack from recognising that ReserveDisk was waiting. This change detours the problem.

This change supports Jampack on MCP 4.7

JAMPACK now supports the Unisys MORETASKS implementation allowing the provision of mixnumbers up to 65535. This is achieved by setting the system options MORETASKS (OP+MORETASKS), halt-loading and changing the MAX command.

In very rare circumstances if Jampack missed the waiting notice for RESERVEDISK, it would fail with an invalid index after DSing the waiting RESRVEDISK.

JAMPACK can now handle pack units with up to 2**32 segments, which is the SSR 45.1 MCP limit. The memory usage of JAMPACK will be somewhat larger due to this change, but the CPU consumption should normally be slightly less.

JAMPACK will now correctly report some errors when linking to MAGUS.
This JAMPACK must be used with MAGUS Version 460.02 or later.

JAMPACK is now compatible with MCP Field Test version 46.143.

Jampack will now notify the user with an error message if the family contains a pack with more than 2**24 segments.

This restriction will be lifted as soon as possible.