Files > PATCH MONITOR

name
PATCH MONITOR
number
9.9
location
^XPD(9.9,
description
This file contains VistA patch information which is stored by a server option when a patch arrives to G.PATCHES at a site. The server extracts certain information and stores it here. A night-time program will then check the file, match it against the install file. If the current date is past the compliance date for patch installation (typically 30 days for regular patches, three days for emergency patches) it will do one of two things: 1. If the patch has been installed since last run and the parameter file is set in field 3 to delete installed patches, it will delete the entry from this file, regardless of the number of days in field 2. If the parameter file is set to leave patches, it is not deleted. 2. If the patch has NOT been installed, its information will be saved and reported via a mail message to a group. The person(s) who are in charge of monitoring patches at the site or perhaps for the VISN will be responsible for following up on delinquent patches.
Fields
#NameLocationTypeDetailsIndexDescription
.01patch name(+)0;1FREE TEXTBThis is the name of the patch as it comes in the mail message. Examples: RMIM*1*1 DG*5.3*211
1date of receipt0;2DATE-TIMECThis is the date the patch was received in-house.
2priority0;3SET OF CODESm:MANDATORY
e:EMERGENCY
The priority assigned to this patch. Typical is "mandatory".
3parent package0;4FREE TEXTThis is the package for which the patch was issued. This field must be free text because of the possibility of having a patch issued for a new package without the package having been installed yet.
4sequence number0;5NUMERICThis is the sequence number assigned to the patch by the National Patch Module.
5package version0;6FREE TEXTThis is the version of the parent package for which a patch is sent. It is determined from the patch information in the message.
6patch subject0;7FREE TEXTThis is the subject of the patch.
7install name0;8FREE TEXTThe installation information may or may not be in the INSTALL file for a patch. This may be because of: a. The package is new and may not yet be loaded but already has patches issued. b. The patch is a non-kids patch for executables, etc.
8compliance date0;9DATE-TIMEDThis is the date by which the patch must be installed.
9date installedCOMPUTEDThis is a computed field, driven by a mumps routine XTPMKPCF. This is a special routine to calculate the date installed from the INSTALL file. It reads the index backwards to find the last installed version by taking the $O(^XPD(9.7,"B",[INSTALL NAME],9999999999),-1). This is done because there may be several test versions on file in INSTALL file which may affect the true installation date determination.
10installed byCOMPUTEDThis is a computed field driven also by the routine AWBCKPCF at entry point WHO. It tells who installed the patch.
11non-kids patch?0;10BOOLEAN1:YES
This field determines what happens in various areas of the package. A patch can be KIDs or non-KIDs. The data on a patch record can be either NULL (KIDs patch) or 1 (Non-KIDs patch). The field can actually be only set to a 1 or the information deleted (NULL).
12non-kids install date0;11DATE-TIMEENon-KIDs patches are those which do not have an accompanying KIDs install in the Packman message because: o It may have an accompanying host file (too large for a mail message) or o It may be a patch message referring to a .zip, .exe or other file which will not put an entry into the INSTALL file. Because of this, there is no install record to extract the install date and it must be entered (i.e., completed) by filling in this field.
13non-kids patch completed by0;12POINTER200This is a pointer to file 200 to record who completed the non-KIDs patch.

Not Referenced