$TXT Created by FORT,WALLY at NXT.KERNEL.FO-OAKLAND.MED.VA.GOV (KIDS) on Thursday, 03/22/07 at 13:33 ============================================================================= Run Date: DEC 12, 2007 Designation: XU*8*434 Package : XU - KERNEL Priority: Mandatory Version : 8 SEQ #384 Status: Released Compliance Date: JAN 12, 2008 ============================================================================= Associated patches: (v)XU*8*353 <<= must be installed BEFORE `XU*8*434' (v)XU*8*419 <<= must be installed BEFORE `XU*8*434' Subject: Set DILOCKTM in Kernel. Category: - Routine Description: ============ Patch Tracking #: 44415898 Test Sites: Bay Pines VAHCS, Little Rock VAMC, Long Beach VAMC, Salisbury VAMC Blood Bank Clearance: 4/17/2007 Remedy Tickets: None After installing this patch, the site configured variable DILOCKTM will exist (similar to the DTIME value) in the user's MUMPS partition after any login through XUS or BROKER. TASKMAN was updated by the release of patch XU*8*455 and XUP was updated by the release of patch XU*8*432. After these three patches are installed at a site, it will allow a site lock setting to exist during calls made by application code using the suggested remediation lock statement. Recoding Example: Current statement: L +^PS(IEN,0):1 Suggested remediation: L +^PS(IEN,0):DILOCKTM Because the routines to process the date saved in ^%ZRTL(3) have been deleted, Calls to T0 and T1 of %ZOSV have been removed from XUS. Background: With the deployment of Cache version 5 and ECP there were changes to lock timeout adherence. That is to say ECP is the first M-to-M communications protocol that strictly adheres to M code LOCK values. While it was once assumed that a one second lock meant a one second wait, that assumption was false. In prior Cache versions the requested lock timeout value was padded with a network acknowledgement which resulted in an extension of the requested lock timeout. In Cache v5 and ECP the network acknowledgement padding does not exist and thus lock timeouts are based solely on system clock time. VISN-20 experienced random lock failures after deployment of Cache 5. While lock failure issues were discussed on HSTS team calls we believe the implementation of the Cache data/app model was theorized as the cause. Once the HSTS team started to upgrade multiple sites to Cache 5 with ECP then they discovered that short lock timeout values could generate lock failure events as seen in VISN-20 in standalone single site traditional Cache Cluster environments. At that point in time the issue was elevated to HSD&D. The majority of lock problems were subsequently resolved with a FileManager patch (DI*22*147 released 5/15/06). This patch instituted a new default lock timeout of three seconds based on a global node setting of ^DD("DILOCKTM")=3. In an extended regional datacenter model, with inherent network latency, system management can now increase the value of this global node to help resolve future lock failure issues, but only in MUMPS code that calls FileMan utilities (example UPDATE^DIE). VISN-20 currently has ^DD("DILOCKTM") set to 5 seconds. While the FileMan patch addressed many locking issues, locks in a regionally extended RDP environment can still be problematic. VISN-20, during extended network latency testing, received CPRS user feedback about locked patient records. An examination of selected Class I code uncovered the existence of lock timeouts hard coded to one second. In the extended regional RDP environment the user was not able to have the lock granted in one second (clock time) and the code returned a statement that another user was accessing the record. With the imminent deployment of regional data centers, the inability to control the inherent network latency induced by distances and service providers, it is highly suggested if not mandatory that legacy VistA code be reviewed, and modified if appropriate, replacing hard coded lock values in favor of a standard variable value. ========================================================================= Installation: >>>Do not allow users to log in to the system during installation. >>>Users may remain on the system. >>>Allow KIDS to inhibit new sign-ons. >>>TaskMan does *NOT* need to be put stopped. 1. Use the 'INSTALL/CHECK MESSAGE' option on the PackMan menu. This option will load the KIDS package onto your system. 2. The patch has now been loaded into a Transport global on your system. You now need to use KIDS to install the Transport global. On the KIDS menu, under the 'Installation' menu, use the following options: Verify Checksums in Transport Global Print Transport Global Compare Transport Global to Current System Backup a Transport Global 3. Users can remain on the system. This patch can be loaded any non-peak time. TaskMan can remain running. 4. Installation will take less than 2 minutes. Install Package(s) 'XU*8.0*434' ========== Want KIDS to INHIBIT LOGONs during the install? YES// YES Want to DISABLE Scheduled Options, Menu Options, and Protocols? YES// NO ========================================================================= Routine Information: ==================== The checksums below are new checksums, and can be checked with CHECK1^XTSUMBLD. Routine Name: XUS Before: B30134409 After: B30954416 **16,26,49,59,149,180,265,337, 419,434** Routine Name: XUSCLEAN Before: B12811237 After: B13027306 **13,59,165,353,434** Routine list of preceding patches: 353, 419 ============================================================================= User Information: Entered By : FORT,WALLY Date Entered : SEP 27, 2006 Completed By: SINGH,GURBIR Date Completed: DEC 03, 2007 Released By : TILLIS,LEWIS Date Released : DEC 12, 2007 ============================================================================= Packman Mail Message: ===================== $END TXT