Patch Barn Specifications

Patch Barn

The Hardhats are going to have a good old-fashioned barn raising! We plan to develop a software application that can be given to the Department of Veterans Affairs to make it painless for them to post software patches in archives for folks both inside and outside the VA. A win-win for everyone.

Preparations:

Volunteers:
(contact Greg Kreis to volunteer.)

Required Skill Sets:

Generation of HTML pages from M code (or willing to give it a try)
Knowledge of KIDS builds and Packman formatting
Opening, writing and closing Host Files (using the Kernel's device manager)
Knowledge of VA programming standards (or an interest in learning them)
Building Kernel menus and options (or in interest in learning how)
Documentation writer
An experienced VISTA/DHCP developer willing to lead the virtual team
Designers to take the specifications and turn them into software plans
Creation of Mailman Servers

Design Notes:

The following collection of notes will guide the Patch Barn designers in their prepartions for the raising.

Background Information:

Patches are distributed as KIDS builds in Packman formatted Mailman messages.
Most messages have descriptive text and the actual KIDS build in the body of the message. In cases where the size it too large, the KIDS build may be offered in a Host sequential file.
Patches pass through several stages in the VA before they are finally released by customer service as mailman messages.
Patches are number and also have a sequence number to indicate the sequence in which they must be installed. Sequence is essential, since patches may overwrite routines and DD entries.

Use Cases:

Patches will be received as mailman messages by the Data Base Administrator.
The DBA periodically applies these patches to a FOIA Platinum account.
DBA wishes to automate the collection and posting of patches to a web pages that links to patches in host sequential files that are archived.

Software Design ideas:

Consider creation of a Mailman server that can receive all patches, saving them in various baskets to be processed periodically.
Patches should be converted from Mailman message format to HFS (host sequential files) format and placed in specified directories.
HTML pages should be automatically generated for posting to a web server with ftp download links connected to the stored patches. Consider putting descriptive text of each patch
Software should allow configuration options to define destination directories for patches and HTML pages.
The sequence numbers for patches must be preserved when archiving the patches and building the linking web pages.
Web pages need to provide at least two views. One by application, within by version and within by sequence number. The other view is a chronological listing of all patches, perhaps as a hierarchy of pages to avoid one giant page.
Web pages will be being updated as patches are processed. Consider using existing VA files and adding files to create a non-visual model of patch history. This model can then drive the creation and recreationg of web pages.

Here are some objectives for an automated patching system. For more information about the requirements, you may want to contact the VA's DBA (Cameron Schlehuber).

Specifications of the message formats:

According to Cameron Schlehuber, here's the patch and HFS structure in a nutshell:

patch message structure:

$TXT creation title etc. } These lines are optional but

... } if present must be bracketed

$END TXT } with $TXT $END TXT

$KID nmsp*vn*pn } E.g., PSJ*4.5*42

**INSTALL NAME** } Always the same

nmsp*vn*pn } E.g., PSJ*4.5*42

... } part of the load global root

... } and its data

$END KID nmsp*vn*pn

HFS file structure:

creation title etc. } free text

comment line } may be blank, but must exist

**KIDS**:nmsp*vn*pn^ } note colon and circumflex!

} blank line

**INSTALL NAME** } This is the

nmsp*vn*pn } same as

... } the text in

... } the patch.

**END** } Always the same

**END** } Always the same (yup, twice!)

} linefeed after 2nd **END**

The name of the HFS file should closely match the patch name structure, but needs to be compatible with NT and UNIX standards. I suggest nmsp-vn_dp-pn.kid ... where vn is the whole number part of the version number and dp is the decimal part, and instead of "*", "-" would be used.

To be convenient to use, one should be able to have an option to select one or more message numbers, as well as those in a range, and be able to enter the destination path. Note that sometimes patches have no code (i.e., $KID etc., doesn't exist). These should default to not creating any file entry and skip gracefully. Perhaps even more convenient would be to have a Server that could "receive" all such messages, with a parameter entry to define the default destination path, and automatically process all such received messages.