Patching Instructions

Patching Instructions
This will be filled in over time...

Example name: XWB-1p1_SEQ-10_PAT-11.kid

XWB is package name SEQ-10 means this is the 10th sequence number Patch-11 means this is patch number 11

Because multiple teams may be working on a project, occasionally patch 4 might come out before patch 3. Thus the sequence numbers were introduced, to ensure proper ordering.

To make a long story short, install the KID patches in numerical SEQUENCE NUMBER ordering.

The KIDS menu option is under EVE->Programming->KIDS

Patches have to be first loaded, then applied Always read the .TXT file that accompanies a patch (.kid). This will tell the special conditions that should be met before applying a patch.

Rick's Talk At WorldVistA 7/1/06
These are things that can be included in a KIDS package

Package elements: Primary
 * Package (?)
 * Build (file 9.6)
 * Data Dictionary (0)
 * Data (file 1)
 * Routine (*)
 * Routine (file 9.8) entries <--- possible conflicts with local stuff.
 * Option (file 19)
 * Protocol (file 101)
 * Remote Procedure (file 8994)

Package Elements: Secondary Below are not included in KIDS, but instructions might specify for user to edit them.
 * Function (.5) -- fileman functions
 * Dialog (.84) -- i.e. internationalization text
 * Parameter (8989.5) -- i.e. adjustable parameters for CPRS etc.
 * Parameter Definition (8989.51)
 * Device
 * Domain
 * bulletin
 * Mail Group
 * Help Frame
 * Security Key
 * New Person

Package Elements: Templates Print Template sort Template Input Template Form Block Foreign Format ...

Non-KIDS stuff -- not included in KIDS Manuals Script Configuration File Non-MUMPS programs

Instructions will tell you to go get separate programs.

Update Ingredients

 * 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
- problems or opportunities arise - national Online Information Sharing (NOIS) - can see if someone else has faced problem - Kernel Installations & Distribution Systems (KIDS) - 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 - first apply them to the test environment, then apply to Live
 * Productions Sites
 * Support Hub (Forum and OpenForum)
 * Development Sites
 * Forum and OpenForum
 * Production Sites (Test & Live Environments)

Software Stream
- these are not sent as emails (can only be as files so far)
 * 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
 * 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
- 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) - it gets harder when you get further behind - "The spreadsheat is your friend", so one can see where one is in the patching process. - 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.
 * Each patch lists its dependencies, and includes a sequence number (by package)
 * Keeping up is the easies approach--just install whatever is new each week.
 * 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.
 * Checking Routine Patch Lists

A Sample Patch
-Name -Sequence Number -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. - a bunch of nodes and values that contain the changes to the system.
 * Identification
 * Description
 * KIDS Distribution

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
- 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
 * Record you current patching status
 * Acquire All Missing Patches

Individual Patch Checklist
- manually backu non-routine elements if conlict
 * 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
 * Install, including any manual post-install
 * Manually resolve conflicts, if any.

Conflict Resolution
- who, when, why, before, after, change history - put this on the patch list on the second line
 * 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

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)