View source for NVSTAR

<pre>
TEST ACCOUNT RESET UTILITIES, VERSION 6.0, September 1, 2002

NOTE:  This document describes the contents and use of a set of special utilities that will assist you in setting up a restored version of your production database for use as a test or mirrored account.  The ongoing development and refinement of these utilities is the result of some hard work by the Avanti and AXP Support Team members, the FileMan Team, various application developers, as well as by the sites who have tested this software.  To all those involved:  thanks for your help and patience.

All these utilities can be used on either an Avanti or AXP/DSM system.  It is assumed that you have already established your test/mirror system, and have completed a recent restore procedure as outlined in other platform-specific documentation.

NOTE:  If you have questions about these utilities, or if you need assistance in setting up a test/mirror system, please log a NOIS or call the National Help Desk to log a Remedy request with the appropriate support team.

- - - - - - - - - -

WHERE TO GET THESE UTILITIES

With this latest version, all the currently available utilities are distributed in a KIDs build.  You can retrieve the KIDs build file from the ftp server at Hines:  fo-hines.med.va.gov (10.3.29.201).  Log on as anonymous.  Change directories twice:  first to avanti, then to testsystem.  The files you want are:

	NVSTAR6.KID		 contains the KIDs build
	NVSTAR6_Install.txt	 contains an example KIDs installation

Install the KIDs build using the example in NVSTAR6_Install.txt file as a general guide.

NEVER UNLOAD THE NVSTAR ROUTINE SET INTO YOUR PRODUCTION ACCOUNT(S)!

- - - - - - - - - -

TEST ACCOUNT RESET UTILITY, version 6.0, September 1, 2002

IT IS RECOMMENDED THAT THIS UTILITY BE USED REGARDLESS OF WHETHER YOU INTEND TO USE ANY OF THE OTHERS.  IF YOU DO PLAN TO USE ANY OF THE OTHER
UTILITIES, YOU SHOULD BE SURE TO RUN THIS ONE FIRST.

This utility is used to reset various file parameters in order for you to use a restored production system as a "test" system.  Following are the actions that will be taken.  Note that this utility uses all currently published conventions for file settings, domain naming, and test/mirror system namespacing (or UCI).

The NVSTAR* routine set performs the following actions:

1.  Rename the domain so that it begins with "TEST" (for example:  DOMAIN.VA.GOV would be changed to TEST.DOMAIN.VA.GOV).  The introductory text is replaced with something that is meant to scream out to anyone logging onto the system that this is the TEST system.

2.  Close, remove any relay domains, and disable "turn" for ALL domains.  If you want to open mail communications from your Test system to your production domain, you will need to do that manually.  You should be very careful, however, to make sure that domains are left closed.

3.	Disable devices with a printer subtype, and all HL7-related links and devices.

•	Disable all devices that contain a printer subtype (for example, any device that has a subtype of P-anything will be disabled).  "Disabled" means that the $I values are set equal to the NULL device's $I (the NULL device's $I is retrieved from your Device file automatically).  Also, the OUT-OF-SERVICE DATE field is set to today's date.  Lastly, the QUEUEING field is set to NOT ALLOWED.  (Note that the BROWSER device and the HFS devices are screened out of this process and are NOT disabled.)
•	Edit HL LOWER LEVEL PROTOCOL file (#869.2) to remove TCP/IP addresses from field 400.01; check the device in field 200.01 (HLLP DEVICE) and disable the device in the Device file in the same way as described for other devices above.
•	Edit HL COMMUNICATION SERVER PARAMETERS file (#869.3) to set field .03 (PRODUCTION or TEST?) to “T” for Test.
•	Edit HL LOGICAL LINK file (#870) to disable AUTOSTART, and set SHUTDOWN LLP? field equal to YES.
•	Edit HL LOGICAL LINK file (#870) to set all TCP/IP addresses in the multiple field 400.01 to delete the TCP/IP address for each logical link.
•	Edit HL7 MESSAGE ADMINISTRATION file (#773) to set all messages to a status of “SUCCESSFULLY COMPLETED” and delete the message administration cross reference ^HLMA(“AC”).
•	Examine each record in the Patient file (#2) for any CIRN/MPI data and clean out any found (this was formally done in previous versions by the module DELMPI^NVSCIRN1.  The procedures is now a standard part of the basic Test Account Reset Utilities procedures.)
•	Set WARD LOCATION file (#42) field RAI/MDS WARD (#.035) to 0 (zero) to disable data transmission between VistA and COTS systems used for RAI/MDS databases.
•	In the Kernel System Parameters file (#8989.3), the field DNS IP (#51) is set to 0.0.0.0.

4.	Reset selected %Z globals.
•	Delete the schedule file (^%ZTSCH) and reset top level (^%ZTSCH=””).
•	Delete the task file (^%ZTSK) and reset top level (^%ZTSK(-1)=100).
•	Delete entries in the failed access attempts log (^%ZUA(3.05)) and reset top level.
•	Delete entries in the programmer mode log (^%ZUA(3.07)) and reset top level.
•	Search OPTION SCHEDULING file (#19.2) for any entries in the TASK ID field (#12).  This field contains a free-text pointer to a task in ^%ZTSK.  If an entry is found, it is deleted.

Note:  because all entries are cleared from the Schedule file (^%ZTSCH), if you wish any scheduled options (from the Option Scheduling file #19.2) to be rescheduled, you will need to do this manually using the Task Manager option.  NO tasks/options are automatically rescheduled to run.

5.  Clean out network mail.  This procedure processes all of Postmaster’s network mail baskets.  All messages found in those baskets are deleted (both from Postmaster’s basket and the Message file.)  This option also deletes the network mail global ^XMBX(3.9,”AI”).  Finally, it processes through the Mail Group file (#3.8) and removes any entries in the REMOTE MEMBERS field for all groups.

6.  Reset RPC Broker Parameters file.  If you are using this file to startup the Broker Listener, it will reset it so that the Listener will be able to start up correctly.  If you are not using it, you may see an "error" message that the file is missing.  Since this file is not necessarily the only means of starting a listener, you can simply ignore any messages.  If you have questions about this, please log a NOIS and we'll be glad to talk it over with you.

7.  Re-enable logons.  This is an optional step.  When the EMC Test Account Reset Utilities are first initialized, logins are automatically disabled.  Before the Reset Utilities procedures begin, you are asked whether you wish to re-enable logins when they are completed.  If you choose not to allow this to happen automatically, you will need to manually re-enable logons in the Volume Set file.

The sequence of execution of the procedures described above is controlled by the main routine (^NVSTAR).  The procedures use the ^XTMP(“NVSTAR”,…) global for scratch space during execution.  The ^XTMP(“NVSTAR”) global is deleted when the procedures are completed.

Following is a listing of the NVSTAR routine set:

^NVSTAR	Reset Procedure Master Routine
^NVSTAR0	Procedure Launcher (controls execution sequence)
^NVSTAR1	Reset Kernel Site Parameters file
^NVSTAR2	Reset Domain file entries
^NVSTAR3	Disable printers
^NVSTAR4	Disable HL7-related links and devices
^NVSTAR5	Task Manager and other %Z Globals Cleanup
^NVSTAR6	Reset RPC Broker Parameters File
^NVSTAR7	Clean Out Network Mail
^NVSTAR8	Enable Logons (if user enables this procedure)
^NVSTARM*	Procedure Monitor Main Routine and Utilities
^NVSTARU	Reset Procedure Functions and Utilities

How to Use:

Start the procedure by issuing the command DO ^NVSTAR in the TST namespace.  This routine (^NVSTAR) is the master routine for all the procedures.  It performs a couple of environment checks:

	-a check for the current namespace (Avanti site) or UCI (DSM site).  The reset procedures will *NOT* run in a "VAH" namespace on an Avanti system, or in a "ROU" UCI on a DSM system.
	-a check for the existence of a tracking global (as described above).  If a tracking global exists, you will be given options on how you want to proceed.
	-a prompt for the name of the NULL device.  This is needed in order to specify the exact NULL device whose $I value will be used as a replacement when the printers are disabled (see more information below.)
	-a prompt for whether you wish to re-enabled logins once the procedures are completed.

    Once the environment checks are complete, the procedure begin and you are shown each step and some explanation of each procedure is provided.

    NOTE:  if for any reason the Test System Reset Utility stops (due to an unforeseen system error, or as a result of human intervention), you should restart the process with step #1 above.  The entire set of procedures can be run multiple times without harm.

- - - - - - - - - -

PATIENT DATA SCRAMBLER UTILITY, version 6.0, September 1, 2002

The Patient Data Scrambler Utility edits various fields in the Patient file.  The intent is to sufficiently "scramble" the information contained in those fields to protect patients.  Although perhaps not completely foolproof, scrambling can be done as a means of protecting patient privacy.  The most important consideration, however, is to prevent confusion when a test system database is used for staff training.  A scrambled Patient file should help prevent action on clinical orders (filling prescriptions, ordering tests, scheduling appointments, etc.) for "test" patients.

A word about name and social security number scrambling:

•	A patient name is first passed through the standard format check function STDNAME^XLFNAME to ensure that the name is in the VistA-standard format.  It is then passed through the scrambling algorithm found in the function REVN^NVSPDSU.  The algorithm used is a simple $TRANSLATE – please see the above module for specific details of the letter-by-letter exchange.  It is important to note that the first letter of the patient’s last name is NOT changed.
•	Social Security Numbers are scrambled by using a new algorithm:

The procedure uses a base prefix of 101-01.  It loops through the existing last-4 SSN cross reference (^DPT("BS")) and simply increments the base prefix as required for the number of records with the same last-4 SSN.  For example, 3 patients that have the same last-4 SSN of 1234:
        
^DPT("BS",1234,1)=""    SSN=509-61-1234
         	^DPT("BS",1234,2)=""    SSN=512-88-1234
         	^DPT("BS",1234,3)=""    SSN=489-22-1234
 
The procedure would start with the base prefix of 101-01.  The "01" portion is incremented for each record, so the resulting scrambled SSNs would be:
         
         	^DPT("BS",1234,1)=""    SSN=101-01-1234
         	^DPT("BS",1234,2)=""    SSN=101-02-1234
         	^DPT("BS",1234,3)=""    SSN=101-03-1234
•	The effect of the name scrambling algorithm that leaves the first letter of the last name intact, in conjunction with the new SSN scrambling algorithm that leaves the last 4 digits of the SSN intact allows for Test system users to lookup patient records by the first-letter-of-last-name+last-4-SSN as they would on the production system.

This Utility is comprised of six routines namespaced NVSPDS:

	^NVSPDS	This is the main Patient Data Scrambler routine
	^NVSPDS1	First Patient Data Scrambler routine
	^NVSPDS2	Second Patient Data Scrambler routine
        	^NVSPDS3	Third Patient Data Scrambler routine
	^NVSPDS4	New Person and Paid Employee File data scrambler routine
	^NVSPDS5	SSN Scrambler
	^NVSPDS6	DISUSER User Accounts Utility
	^NVSPDSU	Scrambler Functions and Utilities routine
	^NVSPDSU1	Scrambler Progress Monitor Utility

This Utility creates a temporary tracking global, ^XTMP(“NVSPDS”,...).  Following is a data dictionary for this global:

	^XTMP(“NVSPDS”,0)=”purge date^create date^NVS Patient Data Scrambler Utility”
	^XTMP(“NVSPDS”,”JOB”)=piece 1^piece 2^piece 3^piece 4^piece 5^piece 6
		piece 1=label
		piece 2=reserved
		piece 3=date and time when Scrambler was started
		piece 4=last DFN processed
		piece 5=total records in ^DPT
		piece 6=number of records processed so far
	^XTMP(“NVSPDS”,"E",n,0)=non-fatal (data inconsistencies) error messages
	^XTMP(“NVSPDS”,”FATAL_ERROR”,data.time,err#,0)=”fatal” error messages during
  scrambling

This tracking global is very important.  As the Scrambler process runs, updates are made in order to keep track of where in the Patient file the Scrambler is working.  While error trapping and logging is set up in this procedure, in the event the Scrambler is aborted before completion, this tracking global will be useful in restarting the process from where it left off.

The error nodes (^XTMP(“NVSPDS”,"E",n,0)) are used to log any errors reported.  Because VA File Manager is called to do a large portion of the field edits, errors may occur that you should know about (e.g., invalid data in the fields).  Once the entire process is completed, you should check the error node using your system's global list utility.  Note, however, that most of these messages indicate that one field or other can’t be edited because data is missing or invalid in some other field.  These notification messages can be ignored on the Test system.

Before editing the Patient file, several actions are necessary to prevent unwanted mail message and/or alert generation.

	1.  Three IVM/PPP-related cross references in the Patient file are permanently removed.  These cross references, #301 on the NAME field (.01), and #9 and #301 on the SSN field (.09), are used by the IVM and PPP packages to send notifications to IVM and updates to the PPP system regarding changes in names and social security numbers.  Since every patient name and SSN are edited, leaving these cross references in place will generate not only a large number of mail messages, but also, <NOSYS> errors when the tasked updates are attempted to the PPP system.  Since this is a "test" system, these kinds of updates will never be desired.  Therefore, the cross references are deleted.  Further, the compiled templates for these fields in the Patient file are recompiled to remove the execution of these deleted cross references.
	2.  The NOTIFICATIONS node in the MAS PARAMETERS file (^DG(43,n,"NOT")) are temporarily  removed.  This prevents various bulletins and triggers from being executed while the Scrambler edits the Patient file.  Any nodes at this location are replaced when the scrambling process completes.

With some exceptions, field edits in the Patient file are performed by a call to VA File Manager.  The function PFEDIT^NVSPDSU contains the FileMan call.  Also, all PDS functions and utilities are contained in ^NVSPDSU*.  Please refer to the modules indicated below for a description of the resulting scrambled data elements.

Fields edited by the Patient Data Scrambler Utility

FILE: 2, PATIENT (^DPT)

Field#	Field Title				Function Call
.01	NAME					$$REVN^NVSPDSU
.09	SOCIAL SECURITY NUMBER		Routine ^NVSPDS5
.092	PLACE OF BIRTH [CITY]		$$CITY^NVSPDSU
.093	PLACE OF BIRTH [STATE]		$$ST^NVSPDSU
.1112	ZIP+4					$$ZIP^NVSPDSU
.114	CITY					$$CITY^NVSPDSU
.115	STATE					$$ST^NVSPDSU
.116	ZIP CODE				$$ZIP^NVSPDSU
.117	COUNTY				$$CTY^NVSPDSU
.1184	*LEGAL RESIDENCE CITY		$$CITY^NVSPDSU
.1185	*LEGAL RESIDENCE STATE		$$ST^NVSPDSU
.1186	*LEGAL RESIDENCE ZIP		$$ZIP^NVSPDSU
.1187	*LEGAL RESIDENCE COUNTY		$$CTY^NVSPDSU
.12111	TEMPORARY ADDRESS COUNTY	$$CTY^NVSPDSU
.12112	TEMPORARY ZIP+4			$$ZIP^NVSPDSU
.1214	TEMPORARY CITY			$$CITY^NVSPDSU
.1215	TEMPORARY STATE			$$ST^NVSPDSU
.1216	TEMPORARY ZIP CODE		$$ZIP^NVSPDSU
.1219	TEMPORARY PHONE NUMBER		$$PHONE^NVSPDSU
.124	*PRIOR CITY				$$CITY^NVSPDSU
.125	*PRIOR STATE				$$ST^NVSPDSU
.126	*PRIOR ZIP				$$ZIP^NVSPDSU
.131	PHONE NUMBER [RESIDENCE]		$$SCR^NVSPDSU
.132	PHONE NUMBER [WORK]		$$SCR^NVSPDSU
.133	*PHONE #3				$$SCR^NVSPDSU
.134	*PHONE #4				$$SCR^NVSPDSU
.211	K-NAME OF PRIMARY NOK		$$REVN^NVSPDSU
.216	K-CITY					$$CITY^NVSPDSU
.217	K-STATE				$$ST^NVSPDSU
.218	K-ZIP CODE				$$ZIP^NVSPDSU
.219	K-PHONE NUMBER			$$SCR^NVSPDSU
.2191	K2-NAME OF SECONDARY NOK	$$REVN^NVSPDSU
.2196	K2-CITY				$$CITY^NVSPDSU
.2197	K2-STATE				$$ST^NVSPDSU
.2198	K2-ZIP CODE				$$SCR^NVSPDSU
.2199	K2-PHONE NUMBER			$$SCR^NVSPDSU
.220	ZIP+4					$$SCR^NVSPDSU
.2401	FATHER'S NAME			$$REVN^NVSPDSU
.2402	MOTHER'S NAME			$$REVN^NVSPDSU
.2403	MOTHER'S MAIDEN NAME		$RE(MOTHER'S MAIDEN NAME)
.251	SPOUSE'S EMPLOYER NAME		See module at ^NVSPDS2+40
.255	SPOUSE'S EMPLOYER'S CITY		$$CITY^NVSPDSU
.256	SPOUSE'S EMPLOYER'S STATE		$$ST^NVSPDSU
.257	SPOUSE'S EMP ZIP CODE		$$SCR^NVSPDSU
.258	SPOUSE'S EMP PHONE NUMBER	$$SCR^NVSPDSU
.2912	GUARDIAN (VA)			$$REVN^NVSPDSU
.2916	CITY (VA)				$$CITY^NVSPDSU
.2917	STATE (VA)				$$ST^NVSPDSU
.2918	ZIP (VA)				$$SCR^NVSPDSU
.2919	PHONE (VA)				$$SCR^NVSPDSU
.3111	EMPLOYER NAME			See module at ^NVSPDS2+68
.3116	EMPLOYER CITY			$$CITY^NVSPDSU
.3117	EMPLOYER STATE			$$ST^NVSPDSU
.3118	EMPLOYER ZIP CODE			$$SCR^NVSPDSU
.3119	EMPLOYER PHONE NUMBER		$$SCR^NVSPDSU
.3121	INSURANCE TYPE (multiple)		
	1	SUBSCRIBER ID				$$SCR^NVSPDSU
	2.015	SUBSCRIBER'S EMPLOYER NAME		$$REVN^NVSPDSU
	2.02	EMPLOYER CLAIMS STREET ADDRESS	See ^NVSPDS2+98
	2.03	EMPLOY CLAIM ST ADDRESS LINE 2		See ^NVSPDS2+99
	2.04	EMPLOY CLAIM ST ADDRESS LINE 3		See ^NVSPDS2+100
	2.05	EMPLOYER CLAIMS CITY			$$CITY^NVSPDSU
	2.06	EMPLOYER CLAIMS STATE			$$ST^NVSPDSU
	2.07	EMPLOYER CLAIMS ZIP CODE			$$ZIP^NVSPDSU
	2.08	EMPLOYER CLAIMS PHONE			$$SCR^NVSPDSU
	3.05	INSURED'S SSN					$$SCR^NVSPDSU
	3.06	INSURED'S STREET 1				See ^NVSPDS2+110
	3.07	INSURED'S STREET 2				See ^NVSPDS2+111
	3.08	INSURED'S CITY				$$CITY^NVSPDSU
	3.09	INSURED'S STATE				$$ST^NVSPDSU
	3.1	INSURED'S ZIP					$$ZIP^NVSPDSU
	3.11	INSURED'S PHONE				$$SCR^NVSPDSU
	9	*AGENT'S NAME				$$REVN^NVSPDSU
	10	*AGENT'S TELEPHONE NUMBER		$$SCR^NVSPDSU
	11	*AGENT'S STREET				See ^NVSPDS2+89
	12	*AGENT'S CITY				$$CITY^NVSPDSU
	13	*AGENT'S STATE				$$ST^NVSPDSU
	14	*AGENT'S ZIP CODE				$$SCR^NVSPDSU
	15	*GROUP NAME					$$SCR^NVSPDSU
	17	NAME OF INSURED				See ^NVSPDS2+94
.313	CLAIM NUMBER			$$SCR^NVSPDSU	
.3211	AGENT ORANGE REGISTRATION #	$$SCR^NVSPDSU
.328	SERVICE NUMBER [LAST]		$$SCR^NVSPDSU
.3294	SERVICE NUMBER [NTL]		$$SCR^NVSPDSU
.3299	SERVICE NUMBER [NNTL]		$$SCR^NVSPDSU
.33011	E-WORK PHONE NUMBER		$$SCR^NVSPDSU
.331	E-NAME				$$REVN^NVSPDSU
.331011	E2-WORK PHONE NUMBER		$$SCR^NVSPDSU
.3311	E2-NAME OF SECONDARY CONTACT	$$REVN^NVSPDSU
.3316	E2-CITY				$$CITY^NVSPDSU
.3317	E2-STATE				$$ST^NVSPDSU
.3318	E2-ZIP CODE				$$SCR^NVSPDSU
.3319	E2-PHONE NUMBER			$$SCR^NVSPDSU
.336	E-CITY					$$CITY^NVSPDSU
.337	E-STATE				$$ST^NVSPDSU
.338	E-ZIP CODE				$$SCR^NVSPDSU
.339	E-PHONE NUMBER			$$SCR^NVSPDSU
.34011	D-WORK PHONE NUMBER		$$SCR^NVSPDSU
.341	D-NAME OF DESIGNEE			$$REVN^NVSPDSU
.346	D-CITY					$$CITY^NVSPDSU
.347	D-STATE				$$ST^NVSPDSU
.348	D-ZIP CODE				$$SCR^NVSPDSU
.349	D-PHONE NUMBER			$$SCR^NVSPDSU

How to Use:

1.  Start this utility by issuing the command DO ^NVSPDS in the TST namespace or UCI and select option number 1:  Patient File Data Scrambler.  Note, you will be WARNED if the namespace/UCI in which you started this process doesn't appear to be your test/mirror system.

2.  Once started, you will be provided with a progress monitor.  The monitor output was borrowed from KIDS so that you can see what percentage of the process has completed.  You will also see any error messages generated during the procedure (don't worry about capturing these, they are also logged in the tracking global as described above.)

3.	The required time to run this procedure varies a great deal.  On some Avanti systems with Patient files of 50K-70K patient records, the procedure takes 4-6 hours.  On some DSM systems with total records in the 125K range, this procedure might require 12 hours or more.  I would recommend running this Utility on a completely quiet test system -- users locked out, Task Manager stopped, and as few processes running as possible.  Also, AXP/DSM sites should check with the AXP Team regarding VMS- or DSM-specific parameter settings that may reduce the amount of time for completion.  For either Cache or DSM, ensure that journaling is disabled.
4.	During processing you may see a variety of messages displayed indicating various fields may not have been edited.  Owing to the generic nature of the Scrambler software, attempts to file data in certain fields may fail because the input transforms or other data verification procedures in the Patient file are executed by File Manager.  This has been the case in all previous versions of the Scrambler and, to date, have not caused any problems on any site’s Test system.  In effect, these messages should be considered informational and no specific action is needed.
5.	Lastly, if you want to review the tracking global mentioned above, use your operating system’s global lister utility (e.g., ^%G on Cache systems) to list and examine the global ^XTMP(“NVSPDS”,…).  Note, again, that this global is NOT killed after the Scrambler completes.  If you wish to delete it, it must be done manually.

IF THE PDSU STOPS FOR ANY REASON, RESTART IT BY ISSUING THE COMMAND DO ^NVSPDS.  THE PDSU USES THE TRACKING GLOBAL TO BEGIN PROCESSING FROM THE POINT WHERE IT STOPPED.  IT IS RECOMMENDED THAT YOU DO NOT RESET ALL ERRORS AND START SCRAMBLING FROM THE BEGINNING:  SCRAMBLED NAMES WOULD BE UN-SCRAMBLED AS A RESULT.

- - - - - - - - - -

NEW PERSON AND PAID EMPLOYEE DATA SCRAMBLER UTILITY, v6.0, September 1, 2002

This optional utility scrambles the name, nickname, and social security number fields in both the NEW PERSON file (#200) and the PAID EMPLOYEE file (#450).  The scrambling algorithm for names and social security number is exactly the same as for the Patient Data Scrambler Utility described above.

Caution:  it should be emphasized that this utility is highly destructive.  Names in both files are completely scrambled – you will NOT be able to lookup users or employees by their “actual” names.  It is advisable to have a list of NEW PERSON record numbers (i.e., DUZs) to use to lookup the post-scrambled records.

This utility also maintains a tracking global.  This global is stored at ^XTMP(“NVSPDS4”,…).  It is initialized with a purge date 30 days in the future.  However, once the procedure successfully completes you will be prompted about deleting the tracking global – you can answer YES to delete it.

How to Use:

From a programmer prompt in the Test system namespace (e.g., TST on Avanti systems), issue the command DO ^NVSPDS and select option number 2:  New Person and Paid Employee File Scrambler.  You will be presented with a warning about not running this in a production account and various data about the NEW PERSON and PAID EMPLOYEE files’ record counts.  You will be prompted to continue with the scrambling procedure.  If the scrambler stops for whatever reason after it is started, restart the procedure by issuing the command DO RESTART^NVSPDS4.

How to “Undo”:

In the event that you do not like the results of running this utility, the only way you can reverse the scrambling of the New Person and PAID Employee files is to copy the globals ^VA(200) and ^PRSPC from the production account and restore the copies to your Test system.

- - - - - - - - - -

DISUSER User Accounts, v6.0, September 1, 2002

This new optional utility is contained in the routine ^NVSPDS6.  The procedure sets the DISUSER flag on all selected user accounts (in the New Person file (#200)).  Both the POSTMASTER account and that of the user running this utility are NOT disabled.  Further, there is an option to de-select user accounts.  These user accounts can either be selected individually, or by way of selecting a mail group.  If a mail group is selected, the accounts for all members of that group will not be disabled.

Caution:  if you plan to use the NEW PERSON/PAID EMPLOYEE SCRAMBLER utility (described above), and this DISUSER utility, you should run this one first.  After the NEW PERSON/PAID EMPLOYEE SCRAMBLER runs, you won’t be able to deselect user accounts from the DISUSER process because you won’t be able to recognize user names!

How to Use:

From a programmer prompt in the Test system namespace (e.g., TST on Avanti systems), issue the command DO ^NVSPDS and select option 3:  DISUSER User Accounts.  You will be notified that the POSTMASTER account will not be disabled.  Further, if DUZ is undefined, you will be asked to enter your user name, and then notified that your account will also not be disabled.  You will then be asked whether you wish to select any user accounts that should be excluded from the DISUSER action.  You can choose user accounts either individually or by selecting a mail group whose members’ user accounts will not be disabled.

How to “Undo”:

If you wish to re-enable accounts, simply use File Manager to remove the DISUSER flag from the account(s).

TEST ACCOUNT MAIL MESSAGE AND BASKET PURGE UTILITY, v6.0, September 1, 2002

This optional utility is comprised of a single routine, ^NVSMMP.  The routine purges (deletes) *ALL* mail messages from the Message file (^XMB(3.9)).  It also purges messages from user mail baskets.  Note, however, that the users' defined baskets are *NOT* deleted, but rather, just cleaned out.  The functional documentation is contained in the routine itself, but following is a brief description:

	1.  Purge all messages from ^XMB(3.9,...)
	2.  Kill all cross references in ^XMB(3.9,...) and reset ^XMB(3.9,0)
	3.  Delete all message references in user mail baskets in ^XMB(3.7,...)
	4.  Remove any forwarding addresses for all users
	5.  Ensure local delivery flag is ON for all users
	6.  Reset edited, message responded, and priority message fields and
	    cross references in ^XMB(3.7,...)
	7.  Reset new message count and message at reinstatement fields in ^XMB(3.7,...)
	8.  Clean up ^XMBPOST
	9.  Delete the network mail file ^XMB(3.9,"AI").

How to Use:

1.  Start the procedure by issuing the command DO ^NVSMMP.  An environment check is made to ensure it is being started in a test account.  Caution:  it is recommended that you NEVER UNLOAD THIS ROUTINE INTO YOUR PRODUCTION SYSTEM.

2.  As the procedure runs, you will receive messages about what is being done.

3.  Total elapsed time obviously will vary depending upon the number of messages at your site.

TEST SYSTEM : MODIFIED KERNEL ROUTINES

The NVSTAR routine set NO LONGER INCLUDES the four VA Kernel routines that are modified for use in your Test System.  The routines are available, however, in OS-specific files at the abovementioned ftp source site.  The files are:

	TEST_XQ_XU157.DSM		 DSM format
	TEST_XQ_XU157_Cache3.rsa	 Cache/NT version 3.2 format
	TEST_XQ_XU157_Cache4.rsa	 Cache/VMS version 4.x format

The routines involved are:

	^XQ, ^XQ12, ^XQ2, and ^XQTOC

There are no functional modifications to these Kernel routines.  The only modifications are to provide the words “<TEST ACCOUNT>” in front of menu lists and option prompts.

At the time these utilities were released, these XQ-namespaced routines were current through patch XU*8*157.  It is possible that future patches will be released that include updates to these routines that will not immediately be placed in the NVSTAR routine set.  If you encounter problems that look to be associated with any of these four routines, it is recommended that you re-copy them from your production system and call the National Help Desk to log a support call to get further assistance.
</pre>