GLOBAL XTMP - Revision history

DavidWhitten: Redirected page to GLOBAL ^XTMP

2019-11-14T17:53:10Z

Redirected page to GLOBAL ^XTMP

← Older revision		Revision as of 17:53, 14 November 2019
Line 1:		Line 1:
	~~= ^XTMP Global =~~		#REDIRECT[[GLOBAL ^XTMP]]

	~~also indexed by: [[GLOBAL ^XTMP]] [[^XTMP GLOBAL]] [[~~#REDIRECT~~[[GLOBAL XTMP]]~~
	==

	There is a recurring need by VistA software to store data in a translated global for relatively short periods of time. However, this data needs to be accumulated for a period longer than an individual user's logon session and longer than the time a specific process/job might run. The [[GLOBAL ^UTILITY(\| ^UTILITY]], [[GLOBAL ^TMP(\|^TMP]] and [[GLOBAL ~~^XUTL(\|^XUTL]] globals do not meet the basic requirements for storing this type of data due to the following:~~

	* These globals are ''not'' translated, and thus, ''cannot'' be relied upon for transferring data from one job to another.
	* The data is not stored for excessively long periods of time and is constantly being processed and purged.
	* The data is stored in an intermediate form, temporarily, so that it can be further processed in an efficient manner.
	* The original data is stored in a VA FileMan file from which the temporary data can be recreated,
	*: or on another system (usually non-VistA) from which it can be resent, if necessary.
	*: Hence, the creation of a VA FileMan file, while feasible, would add unnecessary overhead to the VistA systems.

	~~Therefore, the [[SACC\| Standards and Conventions Committee (SACC) ]] asked Kernel to establish the [[~~^XTMP ~~global~~]]~~, which can be used by any VistA software application. This global is dynamic in size and activity, with one copy accessible to all members of a [[UCI~\|UCI]], and should be placed accordingly.~~


	~~== '''Rules for Use of the ^XTMP Global''' ==~~

	~~The structure of each top node of the ^XTMP global shall have the following format:~~

	~~: ^XTMP(namespaced- subscript,0)=purge date^createdate^optional descriptive information (both dates must be in [[VA FileMan internal date format]])~~

	As per the Standards and Conventions (SAC, Section 2.11.8), developers are encouraged to include other descriptive information on the third piece of the 0 node of the ^XTMP global (e.g., task description and creator DUZ).

	~~1. '''First Subscript Must Be Namespaced'''~~
	~~: The first subscript of the ^XTMP global ''must'' be [[VA Namespacing\|namespaced]].~~
	:: However, other characters can follow the namespace. For example, if the namespace for the software is "RA," the first subscript could be "RA"_DUZ, "RA"_literal, "RA"_$J, etc. This allows the developer to use the global in different parts of the software.

	~~2. '''0 Node Must Exist'''~~
	: There must be a 0 node for the global in which the first piece contains the PURGE DATE in VA FileMan internal date format, and the second piece contains the CREATE DATE in VA FileMan internal date format.
	~~:: For example: ^XTMP("RA1",0)=2920416^2920401~~

	~~3. '''KILL ^XTMP After Use'''~~
	~~: The developer is responsible for KILLing ^XTMP(x) when its use is complete (where "x" is their namespaced subscript).~~

	~~4. '''Code Cleanup'''~~
	~~: Kernel has included the necessary code in the [[ROUTINE XQ82\|^XQ82]] routine to clean up the ^XTMP global (e.g., ^XTMP("RA1").~~
	~~: It KILLs this global under any of the following conditions:~~
	~~:: a) There is no 0 node (e.g., ^XTMP("RA1",0).~~
	~~:: b) The 0 node does not contain a purge date as the first piece.~~
	~~:: c) The date in the first piece of the 0 node is the same as or before the system date.~~


	~~SAC Exemptions~~

	~~As of May 17, 2002, the Standards and Conventions (SAC) document has the following exemptions regarding the ^XTMP global:~~

	* Section 2.3.2.1—Subscripts used in the ^TMP and ^XTMP globals can be lowercase.
	* Section 2.3.2.5—The ^TMP, ^UTILITY, and ^XTMP globals do not have to be VA FileMan compatible.
	* Section 2.3.2.5.2—The ^XTMP global will be translated, with one copy for the entire VistA production system at each site.
	* Section 2.7.3.3—All documented temporary scratch global nodes (e.g., ^TMP and ^UTILITY) are created by a called supported reference, with the exception of ^XTMP global data.
	* Section 2.7.3.4—All local variables, locks, and scratch global nodes (except ^XTMP, or other scratch globals designed to be passed between parts of a package) are created by the application.

	~~: A new extension ''must'' be added to the SAC stating that this global should be used as a scratch area when a translated scratch global is required by software applications.~~


	~~To view the entire SAC document, please visit the SACC home page at the following Web address:~~
	~~http://vaww.vista.med.va.gov/sacc/~~

	[[Category:GLOBAL]]		[[Category:GLOBAL]]

DavidWhitten at 17:51, 14 November 2019

2019-11-14T17:51:35Z

DavidWhitten at 17:16, 14 November 2019

2019-11-14T17:16:01Z

← Older revision		Revision as of 17:16, 14 November 2019
Line 1:		Line 1:
	=~~= [[GLOBAL^XTMP]] [[~~^XTMP Global~~]] =~~=		= ^XTMP Global =

	~~There is a recurring need~~ by VistA software to store data in a translated global for relatively short periods of time. However, this data needs to be accumulated for a period longer than an individual user's logon session and longer than the time a specific process/job might run. The [[GLOBAL ~~UTILITY\|~~ ^~~UTILITY~~]], [[~~GLOBAL TMP\|~~^~~TMP]] and [[~~GLOBAL ~~XUTL\|^XUTL~~]] ~~globals do not meet the basic requirements for storing this type of data due to the following:~~		also indexed by: [[GLOBAL^XTMP]] [[^XTMP GLOBAL]] ==

	* These globals are not translated, and thus, cannot be relied upon for transferring data from one job to another.		There is a recurring need by VistA software to store data in a translated global for relatively short periods of time. However, this data needs to be accumulated for a period longer than an individual user's logon session and longer than the time a specific process/job might run. The [[GLOBAL ^UTILITY(\| ^UTILITY]], [[GLOBAL ^TMP(\|^TMP]] and [[GLOBAL ^XUTL(\|^XUTL]] globals do not meet the basic requirements for storing this type of data due to the following:

			* These globals are ''not'' translated, and thus, ''cannot'' be relied upon for transferring data from one job to another.
	* The data is not stored for excessively long periods of time and is constantly being processed and purged.		* The data is not stored for excessively long periods of time and is constantly being processed and purged.
	* The data is stored in an intermediate form, temporarily, so that it can be further processed in an efficient manner.		* The data is stored in an intermediate form, temporarily, so that it can be further processed in an efficient manner.
	* The original data is stored in a VA FileMan file from which the temporary data can be recreated,		* The original data is stored in a VA FileMan file from which the temporary data can be recreated,
	* or on another system (usually non-VistA) from which it can be resent, if necessary.		*: or on another system (usually non-VistA) from which it can be resent, if necessary.
	* Hence, the creation of a VA FileMan file, while feasible, would add unnecessary overhead to the VistA systems.		*: Hence, the creation of a VA FileMan file, while feasible, would add unnecessary overhead to the VistA systems.

	Therefore, the [[SACC\| Standards and Conventions Committee (SACC) ]] asked Kernel to establish the ^XTMP global, which can be used by any VistA software [[application~~~\|Application]]~~. This global is dynamic in size and activity, with one copy accessible to all members of a [[UCI~\|UCI]], and should be placed accordingly.		Therefore, the [[SACC\| Standards and Conventions Committee (SACC) ]] asked Kernel to establish the [[^XTMP global]], which can be used by any VistA software application. This global is dynamic in size and activity, with one copy accessible to all members of a [[UCI~\|UCI]], and should be placed accordingly.


	Rules for Use of the ^XTMP Global		== '''Rules for Use of the ^XTMP Global''' ==

	The structure of each top node of the ^XTMP global shall have the following format:		The structure of each top node of the ^XTMP global shall have the following format:

	* ^XTMP(namespaced- subscript,0)=purge date^createdate^optional descriptive information (both dates must be in [[~~Timson Format\|~~VA FileMan internal date format]])		: ^XTMP(namespaced- subscript,0)=purge date^createdate^optional descriptive information (both dates must be in [[VA FileMan internal date format]])

	As per the Standards and Conventions (SAC, Section 2.11.8), developers are encouraged to include other descriptive information on the third piece of the 0 node of the ^XTMP global (e.g., task description and creator DUZ).		As per the Standards and Conventions (SAC, Section 2.11.8), developers are encouraged to include other descriptive information on the third piece of the 0 node of the ^XTMP global (e.g., task description and creator DUZ).

	1. First Subscript Must Be Namespaced		1. '''First Subscript Must Be Namespaced'''
	: The first subscript of the ^XTMP global must be namespaced. However, other characters can follow the namespace. For example, if the namespace for the software is "RA," the first subscript could be "RA"_DUZ, "RA"_literal, "RA"_$J, etc. This allows the developer to use the global in different parts of the software.		: The first subscript of the ^XTMP global ''must'' be [[VA Namespacing\|namespaced]].
			:: However, other characters can follow the namespace. For example, if the namespace for the software is "RA," the first subscript could be "RA"_DUZ, "RA"_literal, "RA"_$J, etc. This allows the developer to use the global in different parts of the software.

	2. 0 Node Must Exist		2. '''0 Node Must Exist'''
	: There must be a 0 node for the global in which the first piece contains the PURGE DATE in VA FileMan internal date format,		: There must be a 0 node for the global in which the first piece contains the PURGE DATE in VA FileMan internal date format, and the second piece contains the CREATE DATE in VA FileMan internal date format.
	: and the second piece contains the CREATE DATE in VA FileMan internal date format.
	:: For example: ^XTMP("RA1",0)=2920416^2920401		:: For example: ^XTMP("RA1",0)=2920416^2920401

	3. KILL ^XTMP After Use		3. '''KILL ^XTMP After Use'''
	: The developer is responsible for KILLing ^XTMP(x) when its use is complete (where "x" is their namespaced subscript).		: The developer is responsible for KILLing ^XTMP(x) when its use is complete (where "x" is their namespaced subscript).

Line 55:		Line 57:
	To view the entire SAC document, please visit the SACC home page at the following Web address:		To view the entire SAC document, please visit the SACC home page at the following Web address:
	http://vaww.vista.med.va.gov/sacc/		http://vaww.vista.med.va.gov/sacc/

			[[Category:GLOBAL]]

DavidWhitten: /* ^XTMP Global */

2019-11-14T17:06:20Z

^XTMP Global

← Older revision		Revision as of 17:06, 14 November 2019
Line 1:		Line 1:
	== ^XTMP Global ==		== [[GLOBAL^XTMP]] [[^XTMP Global]] ==

	There is a recurring need by VistA software to store data in a translated global for relatively short periods of time. However, this data needs to be accumulated for a period longer than an individual user's logon session and longer than the time a specific process/job might run. The [[GLOBAL UTILITY\| ^UTILITY]], [[GLOBAL TMP\|^TMP]] and [[GLOBAL XUTL\|^XUTL]] globals do not meet the basic requirements for storing this type of data due to the following:		There is a recurring need by VistA software to store data in a translated global for relatively short periods of time. However, this data needs to be accumulated for a period longer than an individual user's logon session and longer than the time a specific process/job might run. The [[GLOBAL UTILITY\| ^UTILITY]], [[GLOBAL TMP\|^TMP]] and [[GLOBAL XUTL\|^XUTL]] globals do not meet the basic requirements for storing this type of data due to the following:

NeilArmstrong: Added glossary link to Application~

2012-02-22T16:05:29Z

Added glossary link to Application~

← Older revision		Revision as of 16:05, 22 February 2012
Line 10:		Line 10:
	* Hence, the creation of a VA FileMan file, while feasible, would add unnecessary overhead to the VistA systems.		* Hence, the creation of a VA FileMan file, while feasible, would add unnecessary overhead to the VistA systems.

	Therefore, the [[SACC\| Standards and Conventions Committee (SACC) ]] asked Kernel to establish the ^XTMP global, which can be used by any VistA software application. This global is dynamic in size and activity, with one copy accessible to all members of a [[UCI~\|UCI]], and should be placed accordingly.		Therefore, the [[SACC\| Standards and Conventions Committee (SACC) ]] asked Kernel to establish the ^XTMP global, which can be used by any VistA software [[application~\|Application]]. This global is dynamic in size and activity, with one copy accessible to all members of a [[UCI~\|UCI]], and should be placed accordingly.


Line 48:		Line 48:
	: Section 2.3.2.5.2—The ^XTMP global will be translated, with one copy for the entire VistA production system at each site.		: Section 2.3.2.5.2—The ^XTMP global will be translated, with one copy for the entire VistA production system at each site.
	: Section 2.7.3.3—All documented temporary scratch global nodes (e.g., ^TMP and ^UTILITY) are created by a called supported reference, with the exception of ^XTMP global data.		: Section 2.7.3.3—All documented temporary scratch global nodes (e.g., ^TMP and ^UTILITY) are created by a called supported reference, with the exception of ^XTMP global data.
	: Section 2.7.3.4—All local variables, locks, and scratch global nodes (except ^XTMP, or other scratch globals designed to be passed between parts of a package) are created by the application.		: Section 2.7.3.4—All local variables, locks, and scratch global nodes (except ^XTMP, or other scratch globals designed to be passed between parts of a package) are created by the [[application~\|Application]].

	: A new extension must be added to the SAC stating that this global should be used as a scratch area when a translated scratch global is required by software ~~applications~~.		: A new extension must be added to the SAC stating that this global should be used as a scratch area when a translated scratch global is required by software [[application~\|Application]]s.


	To view the entire SAC document, please visit the SACC home page at the following Web address:		To view the entire SAC document, please visit the SACC home page at the following Web address:
	http://vaww.vista.med.va.gov/sacc/		http://vaww.vista.med.va.gov/sacc/

DavidWhitten at 15:46, 27 June 2009

2009-06-27T15:46:25Z

New page

== ^XTMP Global ==

There is a recurring need by VistA software to store data in a translated global for relatively short periods of time. However, this data needs to be accumulated for a period longer than an individual user's logon session and longer than the time a specific process/job might run. The [[GLOBAL UTILITY| ^UTILITY]], [[GLOBAL TMP|^TMP]] and [[GLOBAL XUTL|^XUTL]] globals do not meet the basic requirements for storing this type of data due to the following:

* These globals are not translated, and thus, cannot be relied upon for transferring data from one job to another.
* The data is not stored for excessively long periods of time and is constantly being processed and purged.
* The data is stored in an intermediate form, temporarily, so that it can be further processed in an efficient manner.
* The original data is stored in a VA FileMan file from which the temporary data can be recreated,
* or on another system (usually non-VistA) from which it can be resent, if necessary.
* Hence, the creation of a VA FileMan file, while feasible, would add unnecessary overhead to the VistA systems.

Therefore, the [[SACC| Standards and Conventions Committee (SACC) ]] asked Kernel to establish the ^XTMP global, which can be used by any VistA software application. This global is dynamic in size and activity, with one copy accessible to all members of a [[UCI~|UCI]], and should be placed accordingly.

Rules for Use of the ^XTMP Global

The structure of each top node of the ^XTMP global shall have the following format:

* ^XTMP(namespaced- subscript,0)=purge date^createdate^optional descriptive information (both dates must be in [[Timson Format|VA FileMan internal date format]])

As per the Standards and Conventions (SAC, Section 2.11.8), developers are encouraged to include other descriptive information on the third piece of the 0 node of the ^XTMP global (e.g., task description and creator DUZ).

1. First Subscript Must Be Namespaced
: The first subscript of the ^XTMP global must be namespaced. However, other characters can follow the namespace. For example, if the namespace for the software is "RA," the first subscript could be "RA"_DUZ, "RA"_literal, "RA"_$J, etc. This allows the developer to use the global in different parts of the software.

2. 0 Node Must Exist
: There must be a 0 node for the global in which the first piece contains the PURGE DATE in VA FileMan internal date format,
: and the second piece contains the CREATE DATE in VA FileMan internal date format.
:: For example: ^XTMP("RA1",0)=2920416^2920401

3. KILL ^XTMP After Use
: The developer is responsible for KILLing ^XTMP(x) when its use is complete (where "x" is their namespaced subscript).

4. Code Cleanup
: Kernel has included the necessary code in the [[ROUTINE XQ82|XQ82]] routine to clean up the ^XTMP global (e.g., ^XTMP("RA1").
: It KILLs this global under any of the following conditions:
:: a) There is no 0 node (e.g., ^XTMP("RA1",0).
:: b) The 0 node does not contain a purge date as the first piece.
:: c) The date in the first piece of the 0 node is the same as or before the system date.

SAC Exemptions

As of May 17, 2002, the Standards and Conventions (SAC) document has the following exemptions regarding the ^XTMP global:

: Section 2.3.2.1—Subscripts used in the ^TMP and ^XTMP globals can be lowercase.
: Section 2.3.2.5—The ^TMP, ^UTILITY, and ^XTMP globals do not have to be VA FileMan compatible.
: Section 2.3.2.5.2—The ^XTMP global will be translated, with one copy for the entire VistA production system at each site.
: Section 2.7.3.3—All documented temporary scratch global nodes (e.g., ^TMP and ^UTILITY) are created by a called supported reference, with the exception of ^XTMP global data.
: Section 2.7.3.4—All local variables, locks, and scratch global nodes (except ^XTMP, or other scratch globals designed to be passed between parts of a package) are created by the application.

: A new extension must be added to the SAC stating that this global should be used as a scratch area when a translated scratch global is required by software applications.

To view the entire SAC document, please visit the SACC home page at the following Web address:
http://vaww.vista.med.va.gov/sacc/

← Older revision		Revision as of 17:51, 14 November 2019
Line 1:		Line 1:
	= ^XTMP Global =		= ^XTMP Global =

	also indexed by: [[GLOBAL^XTMP]] [[^XTMP GLOBAL]] ==		also indexed by: [[GLOBAL ^XTMP]] [[^XTMP GLOBAL]] [[#REDIRECT[[GLOBAL XTMP]]
			==

	There is a recurring need by VistA software to store data in a translated global for relatively short periods of time. However, this data needs to be accumulated for a period longer than an individual user's logon session and longer than the time a specific process/job might run. The [[GLOBAL ^UTILITY(\| ^UTILITY]], [[GLOBAL ^TMP(\|^TMP]] and [[GLOBAL ^XUTL(\|^XUTL]] globals do not meet the basic requirements for storing this type of data due to the following:		There is a recurring need by VistA software to store data in a translated global for relatively short periods of time. However, this data needs to be accumulated for a period longer than an individual user's logon session and longer than the time a specific process/job might run. The [[GLOBAL ^UTILITY(\| ^UTILITY]], [[GLOBAL ^TMP(\|^TMP]] and [[GLOBAL ^XUTL(\|^XUTL]] globals do not meet the basic requirements for storing this type of data due to the following:
Line 34:		Line 35:
	: The developer is responsible for KILLing ^XTMP(x) when its use is complete (where "x" is their namespaced subscript).		: The developer is responsible for KILLing ^XTMP(x) when its use is complete (where "x" is their namespaced subscript).

	4. Code Cleanup		4. '''Code Cleanup'''
	: Kernel has included the necessary code in the [[ROUTINE XQ82\|XQ82]] routine to clean up the ^XTMP global (e.g., ^XTMP("RA1").		: Kernel has included the necessary code in the [[ROUTINE XQ82\|^XQ82]] routine to clean up the ^XTMP global (e.g., ^XTMP("RA1").
	: It KILLs this global under any of the following conditions:		: It KILLs this global under any of the following conditions:
	:: a) There is no 0 node (e.g., ^XTMP("RA1",0).		:: a) There is no 0 node (e.g., ^XTMP("RA1",0).
Line 46:		Line 47:
	As of May 17, 2002, the Standards and Conventions (SAC) document has the following exemptions regarding the ^XTMP global:		As of May 17, 2002, the Standards and Conventions (SAC) document has the following exemptions regarding the ^XTMP global:

	: Section 2.3.2.1—Subscripts used in the ^TMP and ^XTMP globals can be lowercase.		* Section 2.3.2.1—Subscripts used in the ^TMP and ^XTMP globals can be lowercase.
	: Section 2.3.2.5—The ^TMP, ^UTILITY, and ^XTMP globals do not have to be VA FileMan compatible.		* Section 2.3.2.5—The ^TMP, ^UTILITY, and ^XTMP globals do not have to be VA FileMan compatible.
	: Section 2.3.2.5.2—The ^XTMP global will be translated, with one copy for the entire VistA production system at each site.		* Section 2.3.2.5.2—The ^XTMP global will be translated, with one copy for the entire VistA production system at each site.
	: Section 2.7.3.3—All documented temporary scratch global nodes (e.g., ^TMP and ^UTILITY) are created by a called supported reference, with the exception of ^XTMP global data.		* Section 2.7.3.3—All documented temporary scratch global nodes (e.g., ^TMP and ^UTILITY) are created by a called supported reference, with the exception of ^XTMP global data.
	: Section 2.7.3.4—All local variables, locks, and scratch global nodes (except ^XTMP, or other scratch globals designed to be passed between parts of a package) are created by the [[application~~~\|Application]]~~.		* Section 2.7.3.4—All local variables, locks, and scratch global nodes (except ^XTMP, or other scratch globals designed to be passed between parts of a package) are created by the application.

	: A new extension must be added to the SAC stating that this global should be used as a scratch area when a translated scratch global is required by software ~~[[application~\|Application]]s~~.		: A new extension ''must'' be added to the SAC stating that this global should be used as a scratch area when a translated scratch global is required by software applications.