Patching Instructions

Package File (9.4)
Package Elements
Build File -- defines which things are to be transported, but doesn't contain actual data
Install file -- tracks which patches have been installed.
Transport global -- temporary storage place to see how it will affect system before actually applying changes. So, when you "load" a patch, it has not been applied yet. You can change your mind before commiting to use of it.
Distribution file or message -- mail message is the primary format (esp in the VA). But there are some things it does not handle. Outside the VA firewall, they use a file format.
Patches -- Patches contain a distribution of a build. User uses patches.

Lifecycle

Productions Sites

- problems or opportunities arise

Support Hub (Forum and OpenForum)

- national Online Information Sharing (NOIS)
- can see if someone else has faced problem

Development Sites

- Kernel Installations & Distribution Systems (KIDS)

Forum and OpenForum

 - If a fix is found, Patch Module is released
    - it has a subscription list of people that want the patch.
 - Test and Verification Sites
 - VistA online (FTP site) & Vista documentation Library

Production Sites (Test & Live Environments)

 - first apply them to the test environment, then apply to Live

Software Stream

Occasional Package Releases (i.e. 4/yr)
Frequent Patches (about 10/wk)
Most patches only depend on other patches from within their own package
Some depend on those from other packages
A few are compound patches, combining patches from differenct packages

- these are not sent as emails (can only be as files so far)

This is a partially ordered set, and must be installed as such

Most of the time, it does not matter which order. But sometimes it does matter. The documentation will show this.

How to Patch in Order

Each patch lists its dependencies, and includes a sequence number (by package)

- Put them in in **sequence number**, not by the number found in the name. - the number in the name is the order in which patches were *started*, but still, apply them in the sequence number (the order that they were released in)

Keeping up is the easies approach--just install whatever is new each week.

- it gets harder when you get further behind

Running reports on the install file can tell you what you are missing
You should create and maintain one or more spreadsheets to track your patching.

- "The spreadsheat is your friend", so one can see where one is in the patching process.

Checking Routine Patch Lists

- occasionally (rarely) the patching process gets messed up by the user, and you might get a half patch. You can look at the second line on a routine and see the patch history.

A Sample Patch

Identification

-Name
-Sequence Number

Description

-Dependency
-Explanations
-Checksums
  Important.  Apply to the routines only.  Helps to ensure file not corrupted.  You can compare the "pre" number from the patch to YOUR "pre" number.  That will help you tell if you have modified the file on your system, or if yours is the same as the KIDS creater had.

KIDS Distribution

- a bunch of nodes and values that contain the changes to the system.

Reports for the Install File

Sorting by Package
Sorting by Install completion date
Sorting by Sequence Number
demo

Spreadsheet Issues

List out the patches applied Good to Record which batch a patch was applied. If you mess up on one patch, the others that you did at the same time (the patch) might also be messed up. Use the spreadsheet for planning which patches to apply, in which order.

Pearl: Turn on logging (to disk) in Putty so you can see what you did. Or on linux, use a utility called "script"

Patch Batch Checklist

Record you current patching status
Acquire All Missing Patches

- add the distribution files to your directoreis - add the patches to the spreadhseet ... this will check the checksums do CHECK^XTSUMBLD <-- there is an option for this one do CHECK1^XTSUMBLD

Individual Patch Checklist

Acuqire patch and all distribution files
Install predecessor (usualy) & dependants
check for non-forward-compality conflicts
study patch (features & package elements)
Load, check, print, compare, backup

- manually backu non-routine elements if conlict

Install, including any manual post-install
Manually resolve conflicts, if any.

Conflict Resolution

conflict resolution is programming
It involves four copies of a routine:
- class III before (which you wrote)
- Class I Before (which you overwrote)
- Class I After (introducted by the patch)
- Class III After (which you must now write -- including your modifications)
Comment extensively

- who, when, why, before, after, change history
- put this on the patch list on the second line

Kevin Toppenberg's extra notes:

Missing Patches

The source of patches is on the ftp server: ftp.va.gov However, there seem to be patches missing for various reasons. I am going to document these here.

KIDS file for LEX*2.0*29
CTD_MS_1_0.KID
NDF4P98.KID needed for patch PSN*4*98 SEQ #93 (seems to be copyrighted patient handout information)

Patching Instructions

Contents