IA #	Name	Type	Custodial Package	Date Created	DBIC Approval Status	Status	Usage	File #	General Description	Remote Procedure	Routine	Date Activated
IA #	Name	Type	Custodial Package	Date Created	DBIC Approval Status	Status	Usage	File #	General Description	Remote Procedure	Routine	Date Activated
49	DBIA49	File	MAILMAN	1990/08/07		Retired	Private	3.7	The only package granted a DBA to extract data from MailMan's file 3.7 is Albany's Site Installation Report. References and extracts data from ^XMB global. $O's thru the Postmaster's basket, ^XMB(3.7,.5.2."B" ,to get IFN for SIR.REDACTED basket, then $O's thru messages in the basket & extracts data into a FM file. DURATION: Till next version of Fileman (v.18) when filegram and mail server functionality is available. If this DBA is NOT OUT-OF-DATE and to be deleted, please note change suggested below.
239	DBIA239-A	File	MAILMAN	1993/06/15	APPROVED	Active	Private	4.3
247	DBIA247	File	MAILMAN	1991/12/01		Retired	Private	3.9	Refenences to the MESSAGE File (3.9) ^XMB(3.9,i,0) Field .01 Subject ^XMB(3.9,i,2,j,0) Field 3 Text
248	DBIA248	File	MAILMAN	1991/12/01	APPROVED	Active	Controlled Subscription	4.2	ROES acesses the following entities in Kernel: 1) DOMAIN - DIC 4.2 ^DIC(4.2,i,0) Field .01 Name (Cross-reference) ^DIC(4.2,"B",NAME,i) Name 2) KERNEL SITE PARAMETERS - DIC 4.3 ^XMB(1,1,0) Field .01 Domain Name 3) SECURITY KEY - DIC 19.1 (Cross-reference) ^XUSEC(KEY,DUZ) Field 2 Holder
286	DBIA286	File	MAILMAN	1993/10/05	APPROVED	Active	Private	4.2	MailMan v 7.1 will invoke a QA conversion in MailMan's post init. It will manipulate the fields as follows: DBIA for MailMan with the QUALITY ASSURANCE SITE PARAMETERS file (#740). This DBIA is for the purpose of a post-init conversion of two free-text pointers to the DOMAIN file (#4.2). Read/write access to the following fields: 740,740.02 EWS DOMAIN (0;3) 740,740.04 NQADB DOMAIN (0;5)
709	DBIA239-B	Routine	MAILMAN	1993/06/15		Retired	Private				XMA21
711	DBIA241-B	File	MAILMAN	1993/06/15	APPROVED	Active	Private	4.2
910	DBIA910	Other	MAILMAN	1994/07/20		Retired	Private		Lab is requesting a new domain for the purpose of uploading a monthly laboratory workload reports to Austin. The increase in traffic should be less than 30K per institution once per month. Typically a message is about 200 lines. NAME: REDACTED FLAGS: S RELAY DOMAIN: REDACTED DHCP ROUTING INDICATOR:LAB PHYSICAL LINK DEVICE: MINIOUT TRANSMISSION SCRIPT: SCRIPT TEXT:
1019	BULLETIN FILE	File	MAILMAN	1994/10/07	APPROVED	Active	Private	3.6	Kernel Installation and Distributions System needs to update the Bulletin file, 3.6. KIDS needs to extract data from this file during Package transportations. KIDS also needs to update this file during Package installation.
1034	FILEGRAMS use of MESSAGE file	File	MAILMAN	1994/10/18	APPROVED	Active	Private	3.9	VA FileMan looks directly at the MESSAGE file in processing FILEGRAMS. FM is requesting the DBIA for FM Version 21. We will include the migration of the Filegram processor to use the SERVER protocol to our V22 to-do-list; it will then be prioritized along w/ the n number of things already planned for V22.
1035	TRANSFER TEXT FROM MAIL MESSAGE	File	MAILMAN	1994/10/18		Retired	Private	3.9	VA FileMan looks directly at the MESSAGE file to transfer text from one mail message to another, using the UTILITY, TRANSFER TEXT option in the line editor. FM is requesting the DBIA until mailman provides the interface for transferring message text.
1040	LIST INDEX OF MESSAGE RESPONSES	Routine	MAILMAN	1994/10/24	APPROVED	Active	Supported		This API may be called in a roll and scroll mode to list the responses of a message.		XMAH
1042	USE OF XMSUB IN FM SCREEN EDITOR	Other	MAILMAN	1994/10/25		Retired	Private		The Screen Editor in VA FileMan checks for the existence of the variable XMSUB. If XMSUB exists, the Screen Editor displays the first 30 characters of that variable between "greater than" and "less than" symbols (< and >) on the top ruler line of the screen. When an original MailMan message is edited, XMSUB contains the subject of the message; when a response is edited, XMSUB contains an "R" concatenated with the number of the original message.
1048	MAILMAN: Initialize Mailman Environment	Routine	MAILMAN	1994/11/01		Retired	Supported		NOTICE! NOTICE! NOTICE! XMGAPI1 is being RETIRED as a supported reference. Use INIT^XMVVITAE instead. This routine contains two application programmer entry points: $$EN^XMGAPI1(DUZ,.HEADERS) which initializes mailman to access DUZ's mail and is the preferred technique for programs to use. OPTIONS should continue to invoke EN^XM. $$READ^XMGAPI1() which returns the "next" line in the body of a message -- typically for a server		XMGAPI1
1131	XMB('NETNAME')	File	MAILMAN	1995/02/09	APPROVED	Active	Supported		^XMB("NETNAME") contains the human-readable form of the name of the local domain. It is a copy of the .01 field of the record in the DOMAIN file 4.2 pointed to by the .01 field of the only record in the MAILMAN SITE PARAMETERS file 4.3. You may reference this global in any routine.
1132	TEST FORWARDING ADDRESS	Routine	MAILMAN	1995/02/21	APPROVED	Active	Supported		This API sends a test message from the Postmaster to the forwarding address of a user. If the MAILMAN SITE PARAMETER field 7.01, FWD TEST MESSAGE TO POSTMASTER, is not set, the Postmaster is a recipient. The message will either be successful or a message will be returned to the Postmaster from the remote system identified in the forwarding address explaining that the message could not be delivered. This entry point is not normally used by application programmers. Usage: D ^XMUT7(Y), where Y is the DUZ of the user whose forwarding address is to be tested.		XMUT7
1136	ENCODE/DECODE CARETS AND CTRL CHARS	Routine	MAILMAN	1995/02/21	APPROVED	Active	Supported		This API contains the following functions: $$ENCODEUP^XMCU1(STRING) - convert all "^" to "~U~" $$DECODEUP^XMCU1(STRING) - convert all "~U~" to "^" $$STRAN^XMCU1(STRING) - convert all control characters to printables $$RTRAN^XMCU1(STRING) - undo the conversion by $$STRAN^XMCU1		XMCU1
1140	MAILMAN: (old) Message Forwarding (Extr.Fun.)	Routine	MAILMAN	1995/02/19		Retired	Supported		NOTICE! NOTICE! NOTICE! XMDF is being RETIRED as a supported reference. Use ENT1^XMD instead. $$ENT^XMD is an interface in the same routine as the other interfaces for forwarding messages. It has identical parameters and results and calls this one -- which will remain supported since documented first. $$ENT^XMDF is a newly created extrinsic function to forward a message for immediate delivery TO LOCAL RECIPIENTS ONLY. This is processed while the user waits. It is not passed on to background filer(s) as with most mail messages. Usage: S X=$$ENT^XMDF(RECIPIENT,TOBASKET,MESSAGE,FORWARDER) Where: RECIPIENT = Recipient DUZ (Pointer to the New Person file) TO_BASKET = Number of Basket (to recipient; typically null; if less than 1, set to 1 (IN)) MESSAGE = IEN of message in the Message file (XMZ) FORWARDER = DUZ of person who forwarded message Output: If successful, +X>0.(1 or 10) ...or If unsuccessful, X=Human readable error (+X<1); for example: "-0: Already a recipient" Example: S X=$$ENT^XMDF(.5,"",XMZ,DUZ) I X<1 W 7,!,"*** Message NOT forwarded: ",X		XMDF
1141	MAILMAN: Ext. Fun. to view/edit Info. Only Flag	Routine	MAILMAN	1995/02/20		Withdrawn	Supported		$$INFO^XMA11 This extrinsic function allows the user to view and, potentially, change the type of a message to "Information Only". Usage: S X=$$INFO^XMA11(XMZ) Where: XMZ = Message Number (IEN in file 3.9) Always returns a "0" (zero) and whatever would be returned by a DIE call. Invokes DIE call in interactive mode. Example: S X=$$INFO(XMZ) INFORMATION ONLY?: ? If "YES", the message will be considered "INFORMATION ONLY" for all recipients. Choose from: y YES n NO INFORMATION ONLY?: ?? This field, if set to "YES", will cause all recipients to be considered "INFORMATION ONLY", which disables responses to the message. If a sender wishes to individually restrict responses, "INFO:" before the recipient's names will restrict their responses. Messages which are broadcast (by naming a recipient "*"), are automatically set to INFORMATION ONLY. Choose from: y YES n NO INFORMATION ONLY?:
1142	MESSAGE SUBJECT API	Routine	MAILMAN	1995/02/20	APPROVED	Active	Supported		This API contains the following functions: $$SUBCHK^XMGAPI0 - validate a proposed message subject $$SUBGET^XMGAPI0 - retrieve the subject of a message		XMGAPI0
1143	MESSAGE HEADER API	Routine	MAILMAN	1995/02/20	APPROVED	Active	Supported		This API contains the following function: $$NET^XMRENT - Get message header information		XMRENT
1144	MESSAGE INFO API	Routine	MAILMAN	1995/02/20	APPROVED	Active	Supported		This API contains the following function: $$HDR^XMGAPI2 - retrieve information about a message.		XMGAPI2
1145	REPLY TO / ANSWER A MESSAGE API	Routine	MAILMAN	1995/02/20	APPROVED	Active	Supported		The APIs (functions) in this DBIA send non-interactive replies and answers. $$ENT^XMA2R - Send a reply to a message. Add a response to the response chain of original message. $$ENTA^XMA2R - Send an answer to a message. Create a new message (rather than adding a response to the response chain of original message).		XMA2R
1146	MAIL GROUP API	Routine	MAILMAN	1995/02/20	APPROVED	Active	Supported		This mail group API contains the following entry points: $$DM^XMBGRP Delete local members from a mail group. $$MG^XMBGRP Create a new mail group or add local members to an existing mail group.		XMBGRP
1147	LOOKUP / CREATE BASKET	Routine	MAILMAN	1995/02/20	APPROVED	Active	Supported		This function looks up a mail basket name and returns its IEN. If the basket doesn't exist, the basket will be created and the IEN of the newly created basket will be returned.		XMAD2
1148	MAILMAN: Interactive control of a port	Routine	MAILMAN	1995/02/20	APPROVED	Active	Supported		Device and Line Checking GO^XMCTLK This routine allows one to interactively use a device and displays keyboard entry and data coming down the line. Usage: D GO^XMCTLK Note: DHCP programming environment is assumed (initialized through the execution of D ^XUP or sign-on through ^XUS). All I/O from the keyboard and device chosen are echoed on screen. It is good for testing devices, Network outgoing points, etc. What is displayed on the screen may be captured into a mail message. Type an "A" to communicate with TalkMan.		XMCTLK
1149	MAILMAN: User Question & Answer Driver and Validator	Routine	MAILMAN	1995/02/20		Retired	Supported		NOTICE! NOTICE! NOTICE! XMAREAD supported calls are being RETIRED. Use FileMan's ^DIR instead. ^XMAREAD contains the following application programmer functions: $$READ^XMAREAD(prompt,question_type,default,anti-illegals_flag,.help_array) is a question and answer driver that will allow the caller to specify a question type, a prompt and a default. $$CHECK^XMAREAD(question_type,string-to-be-tested) is a silent form of $$READ^XMAREAD, e.g. it does not ask questions. $$READ^XMAREAD(prompt,question_type,default,anti-illegals_flag,.help_array) This function is a question and answer driver that will allow the caller to specify a question type, a prompt and a default. The senders' exact input or the default (except in the case where a "Yes" or "No" question is answered) is returned to the caller. All basic input checking is completed without changing or setting any variables. Suggestions for Improvement to this interface are welcomed. The way the function is used is as follows: Usage: S X=$$READ^XMAREAD(A,B,C,D,.E) Where: A (prompt) is a string that will be used as a prompt B (question_type) is a question type C (default) is the default answer to the questions D (no_illegals_flag) If non-zero, do not store illegal characters E (.help_array) is the array of help text (leading period is required!) There are four different types of questions (second parameter): U Abort (This question type will always append the message "Enter <RET> to continue, "^" to abort") F Free Text N Number Y Yes or No Illegal characters are control characters and any of these: @^!()#~_-=%$\|[]\"">< The value returnable for each type is: Type Handling U Whatever the user types -- the caller must interpret it. F A string of 3-30 characters which does not contain any control characters or @, ^, !, (, ), #, -, _, =, %, $, \|, [, ], \,", <, >. If the third parameter is non-zero and not null or the variable XMREADNO exists, special characters are allowed. Otherwise only numbers, spaces and letters are accepted. N Only integers are acceptable inputs. Y Any leading substrings of "Yes" or "No" are acceptable. In either case, "1" is returned for Yes, "0" for No. $$CHECK^XMAREAD(Y,Z) This function is the same as $$READ^XMAREAD, except it does not ask questions. It merely puts any answers through a validity check. Usage: S X=$$CHECK^XMAREAD(Y,Z) Where: Y = The Type (U,N,F, or Y) Z = The input to be validated If the input is valid, the null string is returned. If the input is NOT valid, a text string which documents why the string is not valid is returned.		XMAREAD
1150	RESEQUENCE MESSAGES API	Routine	MAILMAN	1995/02/20	APPROVED	Active	Supported		This API resequences the messages in your basket.		XMA03
1151	MAILMAN: Server API	Routine	MAILMAN	1995/02/20	APPROVED	Active	Supported		^XMS1 contains the following application programmer functions: $$STATUS^XMS1(MSGIEN,RDUZ) which extracts the status from network messages only. $$SRVTIME(MSGIEN,RDUZ,Status) which sets status of recipients in a message. Appendix 1 -- Message Server Protocol Overview A server is an option which is invoked when a mail message that has been addressed to it has been delivered. As an option, many of the parameters associated with the servers are embedded in the definition of the option. Therefore, in order to understand servers completely, you should refer to the server documentation in Kernel 7.0 manuals. Options are listed in the Menu Management documentation. Servers may or may not receive data. The received data usually comes in the form of the text of the message being delivered to it, but the data may also be pointed to by the message, and exist in the system either because it was there in the beginning, or because it arrived independently. Servers may be addressed from a remote site. A server on DNS may receive a message addressed to it from DNS. In fact, this is very common. There are security features as parameters of the option that has been designated as a server because of the fact. Please be aware of these security parameters. Messages addressed to servers will not be scheduled if security is not passed. Filegrams work through use of a server. Data is loaded into a mail message, addressed and when delivered, processed by the filegram server into the receiving database. Servers are always invoked through tasks that are set up when the message is delivered into the system locally or over the network. One of the options is to "Run Immediately". Then the task is scheduled to run "NOW". However, tasks may not need to be scheduled at all because the system manager has stated so in the entry for the server in the Option file or because of a problem. See the Menu Management documentation in the MailMan Technical Manual and Systems Management Guide for more information concerning this. Server Statuses Server recipients are recorded in the recipient chain of a message and appear similarly to other users. MailMan enters statuses on its own as stages in the server process are reached. First, the message is marked as "Awaiting Server". This indicates that the message has been received and the option is a valid one. At this point, a task has been created to actually invoke MenuMan to schedule or perform the service (option) required. The last status which MailMan sets is "Served", which means that MenuMan has been called successfully and MenuMan has either performed the task in the case of a server that runs immediately, or that some other action has been done. At this point, a task could be scheduled to invoke the server or simply a message could be sent to indicate that the task exists and needs to be scheduled, or some other action that was required was performed. MenuMan has its own statuses which will be used. $$SRVTIME^XMS1 This extrinsic function sets status of recipients in a message. Usage: S X=$$SRVTIME^XMS1(A,B,C) Where: A = XMZ (message number) B = A string representing the recipient name C = Status is free-text (String less than nine (9) characters in length) If successful, X = 0 ...or If unsuccessful, X will be a number followed by a human readable error Addressing a Server To address a server, precede the recipient name with "S." (e.g., S.XMECHO). This example sends a message to the Mail Man Echo Tester server. "S." must be followed by an option name from the Option file in the Target Domain. If not, a "Recipient not Found" error will occur. A "Recipient Ambiguous" error will occur, if there is more than one option whose name partially matches the name addressed. The District Registry server for admitting a new patient could be addressed as follows: S.DGDISTADMIT@DNS The message is destined for the DGDISTADMIT option at San Francisco. Replies to this message would be from this same name. Writing a Server Program The server communicates with mail messages in specific ways. Code is used to interface the server to the message system. The code below returns the original message to the sender: ECHO ; K XMY S XMSUB=$E("Server echo of'"_XMBSUB_"`",1,65) S XMY(XMFROM)="",XMTXT="^XMB(3.9,"_XMZ_",2," D ^XMD Q In this example, the variable XMFROM contains the sender address and is supplied to the server when invoked. Other variables also exist upon invocation of the server. The XMF.1 example server program is supplied with MailMan. XMF1 uses some of the other variables supplied to the server. Execute variable XMREC to read a line of the message. XMER and XMRG are returned. XMER This variable returns the execution status of XMREC. XMER<0, if there is no more message text to read. The value of XMER will be zero (0), if XMRG is being returned as non-null. XMRG, in that case, will have as its value the text of the next line of the message. XMRG The value of XMRG will be the next line of message text. XMRG will always be defined, though it will be null when XMER<0. XMPOS This variable contains the current position of the text returned in the variable XMGR. It is initialized if it is undefined, but should be killed by the server when it is finished "Reading" the message. Here's another example of code, this time from XMF1: S XMA=0 A ; X XMREC ; Receive a line I $D(XMER) G Q;XMER<0 ; Check for end of message S XMA=XMA+1 ; Increment local line count S XMTEXT(XMA)=XMRG ; Set local array G A ; Go back for another line Double Serving Messages On occasion, the transmission/receive process is interrupted by a system back-up. It appears to result in the same message being served twice. The Audit Log for the Options file shows two messages with the same message number and subject, but with different Date/Times and Job Numbers. To avoid this, application servers should be written such that they check for and avoid processing of the same message being delivered to any particular server. MailMan transparently checks this and does not deliver twice to mail boxes. However, devices and servers do not have mail boxes to check against. Servers can have some understanding of special mail baskets in the Postmaster's mail box and can be written to check for duplicate deliveries (See reference XMAIC entry points in the Callable Routines section of the Technical Manual and System Manager's Guide).		XMS1
1165	DBAI1165	File	MAILMAN	1995/03/14		Withdrawn	Private	4.2	Used to build PPP DOMAIN XREF file (#1020.8). This is a file of station numbers and domains.
1201	KERNEL transport MM routine	Routine	MAILMAN	1995/04/20	APPROVED	Active	Private		Kernel needs to transport MailMan routine XMGAPI4 to sites untill MailMan 7.2 is installed. KIDS will check and only install the routine if it doesn't already exist.		XMGAPI4
1230	PRINT A MESSAGE API	Routine	MAILMAN	1995/05/17	APPROVED	Active	Supported		The entry points in this API print messages: - PR2^XMA0 print a message with a header - HDR^XMA0 print a message without a header - ENTPRT^XMA0 interactive print a message		XMA0
1232	INTERACTIVE REPLY TO A MESSAGE API	Routine	MAILMAN	1999/06/23	APPROVED	Active	Supported		This API lets the user interactively reply to a message in his mailbox. There are two ways to invoke it: D ^XMAH1 or D ENTA^XMAH1.		XMAH1
1233	INTERACTIVE ANSWER OR SEND A MESSAGE API	Routine	MAILMAN	1995/05/24	APPROVED	Active	Supported		This API lets the user answer a message or send a message. When you send an answer to a message, the original message is copied into the answer, the user edits the answer, the user's network signature is appended to the end of the answer, and the whole thing is automatically addressed to the sender of the original message.		XMA11A
1283	MAILMAN - Access 'as if' a server	Routine	MAILMAN	1995/06/28	APPROVED	Active	Supported		Invoking GET^XML with XMCHAN="SERVER" (or any other appropriate channel) sets up the variables available to servers (that channel) invoked during normal delivery. Note that before XMREC is executed, XMZ must be defined; XMER and XMRG are defined by executing XMREC. XMPOS can be changed by the user if appropriate. ========================================================================== Execute variable XMREC to read a line of the message. XMER and XMRG are returned. XMER This variable returns the execution status of XMREC. XMER<0, if there is no more message text to read. The value of XMER will be zero (0), if XMRG is being returned. XMRG, in that case, will have as its value the text of the next line of the message. (Note: which may be null, i.e. a blank line; you cannot test it for being done!) XMRG The value of XMRG will be the next line of message text. XMRG will always be defined, though it will be null when XMER<0. XMPOS This variable contains the current position of the text returned in the variable XMGR. It is initialized if it is undefined and should be killed by the server when it is finished "Reading" the message. Prototype Message Body Reader S XMCHAN="SERVER" GET^XML N A,TEXT ; N MIRROR S A=0 A ; X XMREC ; Receive a line I $D(XMER) G Q:XMER<0 ; Check for end of message S A=A+1 ; Increment local line count S TEXT(A)=XMRG ; Set local array ; S MIRROR(XMPOS)=XMRG ; MIRROR will have the same subscripts ; as the original message G A ; Go back for another line VARIABLES: XMZ Input The internal number of the message to be processed. XMPOS Input The number of the last line read (or null). XMPOS Output The number of the "next" line in the message; if no further lines, XMPOS="" XMER Output 0 unless no lines greater than XMPOS, then -1 XMRG Output line XMPOS of message XMZ		XML
1284	INTERACTIVE READ/MANAGE MESSAGES OPTION	Routine	MAILMAN	1995/07/05	APPROVED	Active	Supported		This API lets the user read and manage the messages in his mailbox.		XMA
1406	BULLETIN	File	MAILMAN	1995/11/08		Retired	Private	3.6	Nursing has permission to access the Bulletin (3.6) file as described in this DBIA.
1563	DBIA1563	File	MAILMAN	1996/07/19	APPROVED	Active	Private	3.8	As part of the installation process, the Ambulatory Care Reporting Project is granted permission to add 'XXX@Q-ACD.DNS' to the REMOTE MEMBER multiple (#12) of the 'SCDX AMBCARE TO NPCDB' entry in the MAIL GROUP file (#3.8).
1564	DBIA1564	File	MAILMAN	1996/07/19	APPROVED	Active	Private	3.6	As part of the installation process, the Ambulatory Care Reporting Project is granted permission to add the mail group contained in the OPC GENERATE MAIL GROUP field (#216) of the MAS PARAMETER file (#43) to the MAIL GROUP multiple (#4) of the 'SCDX AMBCARE TO NPCDB SUMMARY' entry in the BULLETIN file (#3.6).
1966	DBIA1966	File	MAILMAN	1997/03/25	APPROVED	Active	Controlled Subscription	4.2				2017/02/14
2061	DBIA2061	File	MAILMAN	1997/07/11	APPROVED	Active	Controlled Subscription	3.8	This is an agreement for FileMan read/write access to subfile 3.812, (#12) MEMBERS - REMOTE.
2264	DBIA2264	File	MAILMAN	1998/01/12	APPROVED	Active	Private	3.7	Clinical Reminders (PCE) would like to use : ^XMB(3.7,"M",XMZ,XMDUZ,BASKET,NUMBER) as part of a DIC lookup screen in an application that lets sites exchange reminder definitions via MailMan messages. The lookup is done on ^XMB(3.9) and the screen is used to filter out messages that have been deleted i.e., they are not in a basket.
2487	CMOP MAILGROUP ACCESS	File	MAILMAN	1998/07/28	APPROVED	Active	Private	3.8	The Consolidated Mail Outpatient Pharmacy (CMOP) package requires access to the "B" cross reference in the Mailgroup (3.8) File. This access will be limited to CMOP V 2.0 software and the routine PSXPOST.
2496	MAILMAN SITE PARAMETERS	File	MAILMAN	1998/08/11	APPROVED	Active	Private	4.3	Pharmacy Benefits Managment is an extract program. It will extract Pharmacy IV, Unit dose, prescription, Controlled substance and ward stock order information along with Procurement and a limited amount of laboratory data. The data will be sent via MailMan message to Pharmacy Benefits Management section at Hines and incorporated into their national database. These messages will be very long and we wanted to make sure that the PBM software 'honored' the sites wishes to limit their message line #. If we do not find a number in the NETWORK -MAX LINES @ SEND TO field, the program will limit the message to 10,000 lines.			2012/06/26
2611	TIME ZONE DIFFERENTIAL	File	MAILMAN	1998/11/20	APPROVED	Active	Private	4.4	CIRN would like an agreement to do a direct global read of the DIFFERENTIAL (#2) field in the MAILMAN TIME ZONE file (#4.4). This is used in conjunction with the CIRN REPOSITORY SITE PARAMETER file (#990.8) fields, (#10) STANDARD TIMEZONE and (#11) DST TIMEZONE, to automatically identify the current time and time differential for HL7 messaging.
2723	MAILBOX AND BASKET API	Routine	MAILMAN	1999/01/25	APPROVED	Active	Supported		The APIs in this DBIA perform mailbox and basket actions. If any errors occur, the following variables will be defined: XMERR - The number of errors ^TMP("XMERR",$J,<error number>,"TEXT",<line number>)=<error text> Following is information on some common input parameters: XMDUZ - The user (DUZ or enough of the user's name, alias, initials, or nickname for a positive ID) for whom the API is being called. An FM lookup into the ^VA(200, NEW PERSON file will be performed. XMK - The basket (IEN or enough of its name for a positive ID) for which the API is being called. XMTROOT - (optional) The target root to receive the requested list. This quoted string must be a closed root. The node "XMLIST" will be added underneath it. This is an optional parameter. It defaults to ^TMP("XMLIST",$J).		XMXAPIB
2728	USER ENVIRONMENT API	Routine	MAILMAN	1999/01/27	APPROVED	Active	Supported		Create the MailMan environment in which the user will operate while in MailMan. Set up the user's XMV array, which contains vital user information, user preferences, and, if the user is a surrogate, the user's level of authorization. The information in this array is used throughout MailMan. If any errors occur, the following variables will be defined: XMERR - the number of errors ^TMP("XMERR",$J,<error number>,"TEXT",<line number>)=<error text>		XMVVITAE
2729	MESSAGE ACTION API	Routine	MAILMAN	1999/01/27	APPROVED	Active	Supported		The APIs in this DBIA perform message actions. They are designed to be used individually or incorporated into a MailMan front end. For usage instructions, please refer to the Programmer Manual, available at the Infrastructure web site. When used as part of a MailMan front end, INIT^XMVVITAE should be called to create the MailMan environment in which the user will operate. Please see DBIA 2728 for information on the XMVVITAE APIs. When used individually, from a routine, the XMVVITAE APIs should not be called. After every API call, the calling routine should check for the existence of XMERR. If any errors occur, the following variables will be defined: XMERR - the number of errors ^TMP("XMERR",$J,<error number>,"TEXT",<line number>)=<error text> Parameter definitions: XMDUZ User's DUZ or enough of the name for a positive ID. XMINSTR (optional) Array of special instructions ("ADDR FLAGS") Special addressing instructions, any or all of the following: I Do not Initialize (kill) the ^TMP addressee global, because it already contains addressees for this message, as a result of a previous call to an API. R Do not Restrict message addressing: - Ignore 'domain closed' - Ignore 'keys required for domain' - Ignore 'may not forward to domain' - Ignore 'may not forward priority mail to groups' - Ignore 'message length restrictions to remote addressees' X Do not create the ^TMP addressee global, because addressees are only being checked for validity. ("FLAGS") Message is any or all of the following: P Priority I Information only (may not be replied to) X Closed message (may not be forwarded) C Confidential message (surrogate may not read) S Send to sender (make sender a recipient) R Confirm receipt (return receipt requested) ("FROM") String saying who the message is from (default is user, as identified by XMDUZ parameter). This string is placed in field 1 'from' in the message file. Must not be any real person, except for Postmaster. DUZ is not captured in field 1.1 'sender' of message file, thus making this option well-suited for messages from VISTA packages. ("FWD BY") String saying who forwarded the message (default is user, as identified by XMDUZ parameter). This string is placed in field 8 'forwarded by' in the recipient multiple of the message file. Must not be any real person, except for Postmaster. DUZ is not captured in field 8.01 'forwarded by (xmduz)' in the recipient multiple of message file, thus making this option well-suited for messages forwarded by VISTA packages. ("HDR") Print the messages with a header? (0=no; 1=yes) Default is yes. ("LATER") Date/time (any format understood by FM) on which to send this message. Default is now. ("NET REPLY") Should reply be sent over the network? (0=no; 1=yes) Default is no. Currently valid only if sender of original message is remote. ("NET SUBJ") Subject of reply to be sent over the network. Default is "Re: <subject of original message>". Ignored unless XMINSTR("NET REPLY")=1. ("RCPT BSKT") Basket to deliver to for all recipients. Default is IN basket. Recipients must have specified in their personal preferences that such targeted basket delivery is allowed. Otherwise, this option is ignored. ("RECIPS") Print recipients along with the message? 0 No (default) 1 Print summary recipients 2 Print detailed recipients ("RESPS") Print which responses? * Original message and all responses (default) 0 Original message only range list (e.g. 0-3,5,7-99) - Print this range of responses. Ignored if more than one message is printed. This parameter is not checked. It must be correct. Range list may also be open-ended (e.g. 1,2,5- means print responses 1 and 2 and responses 5 to the end). ("SCR KEY") Scramble key (implies that message should be scrambled). Must be 3-20 characters long. ("SCR HINT") Hint for scramble key (mandatory if message is to be scrambled). Must be 1-40 characters long. ("SELF BSKT") Basket to deliver to if sender is recipient. Default is IN basket. ("SHARE BSKT") Basket to deliver to if SHARED,MAIL is recipient. Default is IN basket. ("SHARE DATE") Date/time (any format understood by FM) to delete this message from SHARED,MAIL if SHARED,MAIL is recipient. ("STRIP") String containing characters to strip from the message text (XMBODY). Must be 1-20 characters long. ("TO PROMPT") During interactive message addressing, contains the suggested initial addressee. Default is the user identified by XMDUZ. ("TYPE") Message type is one of the following special types: D Document S Spooled Document X DIFROM O ODIF B BLOB (reserved for future use) K KIDS ("VAPOR") Date/time (any format understood by FM) on which to delete (vaporize) this message from recipient baskets. Recipients may override this date. Also used to set vaporize date/time for messages already in one's own baskets. ("WHEN") Date/time (any format understood by FM) on which to print messages. Default is now. [.]XMTO Addressee or addressee array (if array, must be passed by reference). May be or contain any of the following: User's DUZ, or enough of user's name for a positive ID eg: 1301 or "lastname,firs" or ARRAY(1301)="" ARRAY("lastname,firs")="" G.group name (enough for positive ID) S.server name (enough for positive ID) D.device name (enough for positive ID) You may prefix each addressee (except devices and servers) by: I: for 'information only' recipient (may not reply) eg: "I:1301" or "I:lastname,firs" C: for 'copy' recipient (not expected to reply) eg: "C:1301" or "C:lastname,firs" L@datetime: for when (in future) to send to this recipient (datetime may be anything accepted by FM) eg: "L@25 DEC@0500:1301" or "L@1 JAN:lastname,firs" or "L@2981225.05:1301" (may combine IL@datetime: or CL@datetime:) To delete recipient, prefix with - eg: -1301 or "-lastname,firs" Append "@<sitename>" for any addressees at another site: eg: "I:G.group@site.dsn" or "LAST,FIRST@site.dsn" XMK and XMKZ for APIs which act on one message: XMK (optional, depending on XMKZ) Basket (IEN or name) containing the message. XMKZ Identifies the message. Must be one of the following: Message number (XMZ) in Message global (XMK must not be specified) Message number in the basket (XMK must be specified) XMK and XMKZA for APIs which act on groups of messages: XMK (optional, depending on XMKZA) Basket (IEN or name) containing the messages. XMKZA Identifies messages, using a list or list array, which may end in a comma. Must be one of the following: Message numbers (XMZ) in Message global (XMK must not be specified, AND ranges are not allowed): - List: "1234567" or "1234567,9763213" - List array: ARRAY(1234567)="" ARRAY(9763213)="" Message numbers in the basket (XMK must be specified, ranges are OK): - List: "1" or "1,3,5-7" - List array: ARRAY("1,3")="" ARRAY("5-7")=""		XMXAPI
2730	MESSAGE EDIT API	Routine	MAILMAN	1999/01/27	APPROVED	Active	Supported		These APIs are intended for use by MailMan front ends. They edit different parts of a message. They may only be used by the message sender, and, with the exception of INFO^XMXEDIT, may only be used before the message has been sent to anyone besides the sender. The APIs do not contain any checks to ensure that it was appropriate to call them. That is the responsibility of the calling routine. For these APIs, it is expected that: INIT^XMVVITAE has been called to set up the user's XMV array, with vital user information, user preferences, and, if the user is a surrogate, determine level of authorization. See DBIA 2728 for information on INIT^XMVVITAE. The calling routine has determined that the user is authorized to see the message. If the message is in the user's mailbox, then that's enough. Otherwise, $$ACCESS^XMXSEC should be used to determine authorization. See DBIA 2731 for information on $$ACCESS^XMXSEC. OPTMSG^XMXSEC2 has been called and has given its permission to edit the message or to toggle information only. (Note: $$EDIT^XMXSEC2 will also let you know whether the user may edit the message.) See DBIA 2733 for information on OPTMSG^XMXSEC2A and $$EDIT^XMXSEC2. OPTEDIT^XMXSEC2 has been called and has given its permission to edit the particular thing we are editing here. See DBIA 2733 for information on OPTEDIT^XMXSEC2. INMSG2^XMXUTIL2 has been called to set XMINSTR. These routines expect that XMINSTR has been correctly set. They will change XMINSTR according to the item being edited. See DBIA 2736 for information on INMSG2^XMXUTIL2.		XMXEDIT
2731	SECURITY, PERMISSIONS, & RESTRICTIONS API	Routine	MAILMAN	1999/01/27	APPROVED	Active	Supported		These APIs perform security and permission functions. Please see the Programmer Manual on the Infrastructure web site for further information about the APIs and how to use them.		XMXSEC
2732	SECURITY, PERMISSIONS, & RESTRICTIONS API	Routine	MAILMAN	1999/01/27	APPROVED	Active	Supported		These APIs perform security and permission functions. Please see the Programmer Manual on the Infrastructure web site for further information about the APIs and how to use them.		XMXSEC1
2733	SECURITY, PERMISSIONS, & RESTRICTIONS API	Routine	MAILMAN	1999/01/27	APPROVED	Active	Supported		These APIs perform security and permission functions. Please see the Programmer Manual on the Infrastructure web site for further information about the APIs and how to use them.		XMXSEC2
2734	MESSAGE & MAILBOX UTILITIES API	Routine	MAILMAN	1999/01/27	APPROVED	Active	Supported		These APIs are general message and mailbox utilities. Please see the Programmer Manual on the Infrastructure web site for further information about the APIs and how to use them.		XMXUTIL
2735	DATE & STRING UTILITIES API	Routine	MAILMAN	1999/01/27	APPROVED	Active	Supported		These APIs perform date and string manipulation. Please see the Programmer Manual on the Infrastructure web site for further information about the APIs and how to use them.		XMXUTIL1
2736	MESSAGE INFORMATION API	Routine	MAILMAN	1999/01/27	APPROVED	Active	Supported		These APIs return all kinds of information about a message. - Information that can be displayed. - Information that can be used to determine what may (and may not) be done with the message. Please see the Programmer Manual on the Infrastructure web site for further information about the APIs and how to use them.		XMXUTIL2
2737	MESSAGE INFORMATION API	Routine	MAILMAN	1999/01/27	APPROVED	Active	Supported		These APIs provide information about how a message was addressed and who has read it. Please see the Programmer Manual on the Infrastructure web site for further information about the APIs and how to use them.		XMXUTIL3
2774	INTERACTIVE API	Routine	MAILMAN	1999/03/09	APPROVED	Active	Supported		These APIs are interactive. Please see the Programmer Manual on the Infrastructure web site for further information about the APIs and how to use them.		XMXAPIU
2856	DBIA2856	Routine	MAILMAN	1999/06/25	APPROVED	Active	Private		AR $Orders thru ^XMB(3.9,"B",XMSUBJ,XMZ) to retrieve mail messages. AR references a messages first line in global ^XMB(3.9,XMZ,2,1,0). AR calls D KILL^XMA32A(XMZ,.XMKILL,XMABORT) to delete a message.		XMA32A
2860	DBIA2860-A	File	MAILMAN	1999/07/07	APPROVED	Active	Private	3.9	The Radiology/Nuclear Medicine package requests permission to lookup the DATE ENTERED value for a message in file 3.9 of the Mailman package.
2861	DBIA2860-B	File	MAILMAN	1999/07/07	APPROVED	Active	Private	3.6	The Radiology/Nuclear Medicine package requests permission to lookup the IEN of a bulletin and the ien of the mail group that's linked to the same bulletin.
2862	DBIA2860-C	File	MAILMAN	1999/07/07	APPROVED	Active	Private	3.8	The Radiology/Nuclear Medicine package requests permission to lookup the type of a mailgroup.
3006	MAIL GROUP API	Routine	MAILMAN	1999/11/30	APPROVED	Active	Supported		The APIs in this DBIA perform mail group functions and actions. If any errors occur, the following variables will be defined: XMERR - The number of errors ^TMP("XMERR",$J,<error number>,"TEXT",<line number>)=<error text> Following is information on some common input parameters: XMGROUP - Mail group IEN or name (exact, case-sensitive)		XMXAPIG
3100	MPI-DNS domain set to send	File	MAILMAN	2001/03/22	APPROVED	Active	Private	4.2	CIRN Patient Demographics has an agreement to do a read with FileMan on the NAME (#.01) and FLAGS (#1) fields in the DOMAIN (#4.2) file, as well as the TRANSMISSION SCRIPT (#4) multiple, the TRANSMISSION SCRIPT (#.01) field, NETWORK ADDRESS (MAILMAN HOST) (#1.4) field and OUT OF SERVICE (#1.5) field. This is used in environment check routine, RGP13ENV, to ensure that the instructions in informational patch XMDBA144 have been followed for domain MPI-DNS. The environment check routine will not allow patch RG1.013 to be installed in the production environment unless the FLAGS field (#1) has been set to "S", the NETWORK ADDRESS (MAILMAN HOST) (#1.4) field contains the correct address and the OUT OF SERVICE (#1.5) field is null.
3231	LOCAL TIMEZONE	File	MAILMAN	2000/10/27	APPROVED	Active	Controlled Subscription	4.3	The Vista Imaging application supports site reporting on a monthly basis and the reporting of critical events that require customer support intervention. Tracking these events remotely is easier if the "TIMEZONE" associated with these events is included in the message. We seek direct read access to the ^XMB("TIMEZONE") for this purpose.			2023/04/05
3240	Mailgroup Updates	File	MAILMAN	2000/11/01	APPROVED	Active	Private	3.812	In order to meet the FDA requirements to track the usage of the medical device known as "Vista Imaging" (the IMAGING package) VA maintains a Vista mailman mail server. The server processes monthly site usage parameters and critical event driven alerts. The 2 issues: 1) We create and populate a local mail group, "MAG SERVER", into which we add the local installer and our own, "G.IMAGING DEVELOPMENT TEAM@DNS", remote member. We also, as cleanup, remove a formerly installed remote member which failed often as a result of mail scripts not always having our development domain in place, "G.MAG SERVER@LAVC.DNS". 2) Also, for clarity and because remotes may not have access to the resolved DUZ of local recipient's we place the entire recipient list in the text of the message so when coordinating efforts to resolve critical events, the contacts are most assuredly identified.
3242	DIRECT READ OF XMB(3.9	File	MAILMAN	2000/11/02	APPROVED	Active	Private	3.9	NDF requests a one time agreement with MailMan to do direct global reads to XMB(3.9,DA(1),2,DA Patch PSN441 identified several entries in file 50 as being improperly matched to NDF. Many of these entries were incorrectly so identified. The patch generated a message to users listing the items. Sites have requested a supplemental list showing not only the name of the item, but also the IEN, inactivation date, and whether the item is an investigational drug. The data in file 50 which was used to identify these items was deleted by patch PSN441. The only way to generate these new lists is to read the original message and use the B cross reference in file 50 to get the requested information. LIST^DIC will be used to identify and retrieve the messages.
3341	DBIA3341	File	MAILMAN	2001/03/26		Pending	Private	3.8	Add POSTMASTER as member to MAIL GROUP "YS GAF TRANSMISSION ACK", if no member(s) exist(s).
3359	DBIA3359	File	MAILMAN	2001/04/23	APPROVED	Active	Private	3.8	This DBIA allows Accounts Receivable to delete a mail group. The Accounts Receivable code will first look to see if the mail group exists in file 3.8 by looking at the B cross reference on the NAME (.01) field. If the mail group exists, the code will next loop the AD cross reference on the MEMBER GROUP NAME sub-field (.01) of the MEMBER GROUPS field (11) in file 3.8. If the mail group is a member of another mail group, the mail group will be removed from the MEMBER GROUPS field using DIK. Finally, the mail group will be removed using DIK. The following is an example of the code that deletes the IRS mail group: S RCMIRSDA=+$O(^XMB(3.8,"B","IRS",0)) I RCMIRSDA D . ; check to see if IRS mail group is a member of another . ; mail group. If so, delete it from the other mail group. . S RCDA(1)=0 F S RCDA(1)=$O(^XMB(3.8,"AD",RCMIRSDA,RCDA(1))) Q:'RCDA(1) D . . S RCDA=0 F S RCDA=$O(^XMB(3.8,"AD",RCMIRSDA,RCDA(1),RCDA)) Q:'RCDA D . . . S DA(1)=RCDA(1),DA=RCDA,DIK="^XMB(3.8,"_RCDA(1)_",5," . . . D ^DIK . ; . ; delete the mail group . S DA=RCMIRSDA,DIK="^XMB(3.8," . D ^DIK
3452	MAIL.CIO.DNS Domain	File	MAILMAN	2001/09/13	APPROVED	Active	Private	4.2	CIRN MPI/PD has an agreement to do a read with FileMan on the NAME (#.01) field in the DOMAIN (#4.2) file. This is used in environment check routine, RGP22ENV, to ensure that the instructions in informational patch XMDBA139 have been followed for domain "MAIL.CIO.DNS". The environment check routine will not allow patch RG1.022 to be installed unless the "MAIL.CIO.DNS" entry exists. Patch RG1.022 is in support of GCPR.
3569	REQUEST TO ACCESS THE 'NAME' NODE OF XMB	File	MAILMAN	2002/04/26		Withdrawn	Private		IB needs to determine Production or Test account and would like to use ^XMB("NAME") and ^XMB("NETNAME") to compare with each other and to determine if the first "." piece of this value indicates we're in the test account. We're looking for TEST, MIRROR, TRAIN, MIR, etc. in the node name.
3779	LOOKUP AND READ	File	MAILMAN	2002/10/07	APPROVED	Active	Controlled Subscription	4.2	Permission is granted to: 1. Perform a FileMan lookup on file #4.2, DOMAIN, using the B and C cross references. 2. Read the FLAGS field #1, using either direct global access or FileMan read.
3886	XM OPTION ON SECURITY OFFICER MENU	Other	MAILMAN	2003/02/03	APPROVED	Active	Private		Health Information Security Service is requesting to place a XM option on INFORMATION SECURITY MENU [XUSPY]. XM SUPER SEARCH on XUAUDIT MAINT menu.
3890	BULLETIN LOOKUP AND EDIT	File	MAILMAN	2003/02/11	APPROVED	Active	Supported	3.6	MailMan does not have any APIs which enable a package to edit its own bulletins. Therefore, for the purpose of editing an existing bulletin, owned by a package, permission is granted to: 1. Look up a bulletin using FileMan's ^DIC, such as $$FIND1^DIC. 2. Add/edit data in the bulletin using FileMan's ^DIE, such as UPDATE^DIE or FILE^DIE.
3992	DBIA3992	File	MAILMAN	2004/05/05		Pending	Private	4.2	The API in patch SD5.3301 makes a call to the DOMAIN file (#4.2) to pull the STATION field (#5.5). This AI will allow the Scheduling software to access this data to provide it to application teams in the encapsulation process of Scheduling Replacement.
4020	DBIA4020	File	MAILMAN	2004/05/05		Pending	Private	4.3	The API in patch SD5.3301 makes a call to the MAILMAN SITE PARAMETERS file (#4.3) to pull the NAME field (#.01). This AI will allow the Scheduling software to access this data to provide it to application teams in the encapsulation process of Scheduling Replacement.
4036	XMAPHOST User Interactions	Routine	MAILMAN	2003/03/25	APPROVED	Active	Private		Kernel requests an IA to use entry points in routine XMAPHOST to be called by routine ZISPL, which converts spool documents to mail messages.		XMAPHOST
4141	Closing Legacy Queues	File	MAILMAN	2003/07/02	APPROVED	Active	Private	4.2	When CoreFLS is implemented at a site, the IFCAP and Engineering (AEMS/MERS) packages will be inactivated by the Legacy Software Shut Down patch and there should not be transmission of documents to the domains or queues set up to support their business. As the deployment of CoreFLS nationally will be phased in over a period of a few years, it seems more appropriate that the software involved in the inactivation of IFCAP and Engineering, rather than an nationally released MailMan patch, should close these domains/queues. It is requested that as part of the Legacy Software Shut Down process, PRCL namespaced code be allowed to set the DOMAIN file (#4.2) entry's FLAGS field (#1) to 'C' (CLOSED) and delete the current value of the RELAY DOMAIN field (#2) for the following domains: CONST.RD4-REGION4.DNS NESC.DNS Q-CRD.DNS Q-EDP.DNS Q-EDV.DNS Q-FAM.DNS Q-FMZ.DNS Q-ISM.DNS Q-LOG.DNS Q-PRC.DNS Before filing the changes, the current values of those domains/queues will be extracted and stored in the LEGACY SOFTWARE SHUT DOWN file (#449.1), so that they are available for restoration if necessary. As part of this integration agreement, we are also requesting that the software be permitted to file the original values back into the DOMAIN file entries, in the remote likelihood that the CoreFLS implementation needs to be temporarily reversed. The extraction of current values and the filing would be performed by calls to supported FileMan database server APIs.
4319	KERNEL ACCESS TO TIME ZONE INFORMATION	File	MAILMAN	2003/12/26		Withdrawn	Private	4.3	This IA is used to allow Kernel access time zone information that is owned by MailMan, specificaly field 1 of file 4.3.
4320	KERNEL ACCESS TO MAILMAN'S TIME ZONE INFORMATION	File	MAILMAN	2003/12/26		Withdrawn	Private	4.4	This IA is used to let the part of VDEF that is in the custody of Kernel to access time zone information in the custody of MailMan.
4439	MAIL GROUP REMOTE MEMBER	File	MAILMAN	2004/06/30	APPROVED	Active	Private	3.8	Integrated Billing needs a ONE-TIME ONLY Integration Agreement to allow manipulation of the data in a mail group entry set up with a server option as a remote member. Since no utility exists to delete a remote member from the mail group file, the following access is requested: 1. The ability to read the remote members from one mail group, add them to another mail group, and delete them from the original mail group. This would be done once, in the Post-install routine IBY232PO. The following code would be used: N IBMCR,IBMCH,DLAYGO,DIC,DIK,DA,D0,DD,Z,Z0 S IBMCR=+$O(^XMB(3.8,"B","MCR",0)),IBMCH=+$O(^XMB(3.8,"B","MCH",0)) S Z=0 F S Z=$O(^XMB(3.8,IBMCR,6,Z)) Q:'Z S Z0=$P($G(^XMB(3.8,IBMCR,6,Z,0)),U) I Z0'="" D . I '$D(^XMB(3.8,IBMCH,6,"B",Z0)) D .. S DLAYGO=3.812,DIC(0)="L",X=Z0,DA(1)=IBMCH,DIC="^XMB(3.8,"_DA(1)_",6," D FILE^DICN K DO,DD,DA,DLAYGO,DIC .. I Y>0 S DA(1)=IBMCR,DA=Z,DIK="^XMB(3.8,"_DA(1)_",6," D ^DIK
4585	XM-MESS	Other	MAILMAN	2004/12/29	APPROVED	Active	Private		Because two jobs are being tasked off, the info in ^TMP("XM-MESS" is being saved so that after the first job is queued and ZTLOAD cleans-up ^TMP("XM-MESS",$J), it can be recreated for the second task job. Any output from both jobs ends up as separate messages. If the output from the SORT is not needed the print job could be tasked first but not scheduled and then the sort could be scheduled.
4649	STOP/START MAILMAIL BY FILE	File	MAILMAN	2005/03/24	APPROVED	Active	Private	4.3	This is a IA for KIDS new auto patch utility to start and stop MailMan. In the code KIDS will make set the "BACKGROUND FILER RUN FLAG" and the "TCP/IP POLLER RUN FLAG" to 1=stop running or 0=okay to run. Some patches require that MailMan be stopped. This will work in conjunction with IA #4650.
4650	START MAILMAN BY ROUTINES	Routine	MAILMAN	2005/03/24	APPROVED	Active	Private		This is a IA for KIDS new auto patch utility to start and stop MailMan. In the code KIDS will make reference to START^XMKPL. Some patches require that MailMan be stopped. This will work in conjunction with IA #4649.		XMKPL
4980	Remote Member (#3.812) multiple	File	MAILMAN	2007/05/01		Pending	Private	3.8	This IA allows the subscribing package to reference the Remote Member (#3.812) multiple in the Mail Group (#3.8) file.
5475	MAILMAN Option Access		MAILMAN	2011/01/26		Withdrawn			The Consolidated Patient Accounts Center (CPAC) has requested the ability to access data across all VA Medical Center VistA System by using the telnet feature in CAPRI-Remote. CPAC needs access to the MAILMAN XMEDITMG option in order to perform its business office functions.
5526	SPN ACCESS TO MESSAGE FILE (#3.9)	File	MAILMAN	2010/04/06	APPROVED	Active	Private	3.9	The Spinal Cord Dysfunction package (SPN), requests permission to directly access the global for the Message file (#3.9). This is for a one-time emergency patch, SPN2.027. The SPN package needs to resend Mailman messages that failed to be delivered during a several day period in March 2010. Delivery failed because the Austin Automation Center inadvertently deactivated the domain of the server. The post-install routine SPNP27 will locate the messages by referencing the Message file at these locations: 1) "B" cross-reference 2) first line of the TEXT sub-file (#3.92) 3) "C" cross-reference ont he RECIPIENT sub-file (#3.91) 4) 0 node of the RECIPIENT subfile (#3.91)			2010/04/07
5529	SPN EDITS MAIL GROUP	File	MAILMAN	2010/05/10	APPROVED	Active	Private	3.8	The Spinal Cord Dysfunction package needs to change the recipient of its HL7 messages that are sent via MailMan. To accomplish that it needs one-time permission to delete the old Remote Member and add a new Remote Member of the Mail Group that is used to addres its HL7 messages. This will be used in patch SPN2.026. The lookp is done via the "B" cross-reference. The adding and deleting of the remote members are done via Fileman APIs.			2010/05/10
5805	One Time Exception Domain File (#4.2) Write	File	MAILMAN	2012/05/30	APPROVED	Active	Private	4.2	Integrated Billing application requesting onetime exception write privileges to create new domains needed by Electronic Insurance Identification module. The domains are being created by Integrated Billing patch IB2457 and informational patch XMDBA176 will be released to address documentation needs for the new domains.			2012/06/05
5812	MAX LINES SEND/RECEIVE	File	MAILMAN	2012/06/13	APPROVED	Active	Controlled Subscription	4.3	The Mental Health package requests permission to 'Read with FileMan' the following fields from the MAILMAN SITE PARAMETERS file (#4.3): NETWORK - MAX LINES SEND (#8.3) NETWORK - MAX LINES RECEIVE (#8.31)			2018/05/01
6202	MAIL GROUP MEMBER	File	MAILMAN	2015/06/04	APPROVED	Active	Private	3.8	The PTF module of the REGISTRATION package requests permission to read the MEMBER multiple (#2) of the MAIL GROUP (#3.8) file for patch DG5.3884. This is a one-time use to populate the new PTI mail group with the same MEMBERS as the existing PTT mail group. This will save the IRMS staff from having to manually enter the information and save possible data entry errors. Also, we request permission to read the B cross-reference this one time in order to find the existing PTT mail group.			2015/06/22
6276	DIC(4.2	File	MAILMAN	2015/11/24		Withdrawn	Controlled Subscription	4.2	The Enterprise Health MGMT Platform (HMP) uses site hashing to identify the individual sites that have treated a patient. The HMP code is looping thru the Domain file (#4.2) using direct global access (read only) in order to read the date in the Station field (#5.5) in order compare the results to the Institution field (#.02) from the Treating Facility List file (#391.91). When a match is made, the domain name (.01) field The Name (#.01) from the Domain file (#4.2) for the matching entry is is used to create the unique hash identified for the treating site. All access to the Domain file is via direct global reads and with FileMan.
6814	MAIL GROUP REMOTE MEMBER DELETION	File	MAILMAN	2017/09/12	APPROVED	Active	Private	3.812	Accounts Receivable needs a ONE-TIME ONLY Integration Agreement to allow deletion of remote members from a mail group. Since no utility exists to delete a remote member from the mail group file, the following access is requested: 1. The ability to Fileman read ^XMB(3.8) using $$FIND1^DIC 2. The ability to Fileman/global read the remote member subfile 3.812 in global ^XMB(3.8,,6) 3. The ability to remove the remote members from a specific mail group using the ^DIK utility. This would be done once, in the Post-install routine RCP321, to update the RCDPE AUDIT mail group.			2017/09/26
6908	MAILMAN SET FROM	Routine	MAILMAN	2018/04/18		Pending	Private		This integration agreement allows Enterprise Manager/Watchdog to call SETFROM in routine XMD to verify and define the FROM User prior to calling to send the message. Code reference D SETFROM^XMD(.DSIWFROM,.DSIWXMIN)		XMD
7086	MAIL GROUP REMOTE MEMBER AND DESCRIPTION	File	MAILMAN	2019/07/01		Withdrawn	Private	3.8	Accounts Receivable needs a ONE-TIME ONLY Integration Agreement to allow manuipulation of the data in a mail group entry to add an Outlook mailing list as a remote member and update the mail group's description to warn users not to send PII/PHI to this mail group. Since no utility exists to add a remote member to or edit the description of an entry in the mail group file, the following access is requested: 1. The ability to add a remote member to a mail group. This would be done once, in the Post-Install routine RCP349. 2. The ability to edit the description of a mail group to add text warning users not to send PII/PHI to this mail group. The following code would be used to accomplish both tasks: N FDA,IEN,I,WPDATA D BMES^XPDUTL("Add Outlook email group to RCDPE PAYMENTS EXCEPTIONS mail group") S IEN=$$FIND1^DIC(3.8,,"X","RCDPE PAYMENTS EXCEPTIONS") I 'IEN D Q . D BMES^XPDUTL("Warning: Could not find RCDPE PAYMENTS EXCEPTIONS mail group. Addresses not added.") ; IA TBD S FDA(3.812,"?+"_I_","_IEN_",",.01)="DNSpayerinquiry@DNS" D UPDATE^DIE(,"FDA") ; Update mail group description to warn against sending PII/PHI S WPDATA(1,0)="* DO NOT SEND PII/PHI! This Mail Group sends to an Outlook email address and" S WPDATA(2,0)="should not be used to send data containing PII/PHI *" D WP^DIE(3.8,IEN_",",3,"A","WPDATA")
7419	MAILMAN TIME ZONE FILE ACCESS	File	MAILMAN	2023/03/22	APPROVED	Active	Private	4.4	The Advanced Prosthetics Acquisition Tool (APAT) requests access to the MAILMAN TIME ZONE (#4.4) FILE to read CODE and TIME ZONE NAME for the purpose of documenting the accurate timing of local events.			2023/03/29
7549	XMVSM APIs	Routine	MAILMAN	2025/04/28	APPROVED	Active	Private		The purpose of this Routine is to provide read-only APIs returning MailMan operational status. The VistA System Monitor (VSM) will use this data to display this operational state data in a real-time VistA Operations Dashboard. VSM functionality consuming these APIs will initially be deployed via patch KMP4.05.		XMVSM	2025/04/29
10064	PROGRAMMER API	Routine	MAILMAN	1995/01/31	APPROVED	Active	Supported		^XM contains these programmer entry points: ^XM is the normal routine programmers invoke to use MailMan directly. No menu item leads to ^XM. KILL^XUSCLEAN is invoked so only basic Kernel parameters survive call. EN^XM is the entry action for the top-level interactive MailMan option. It invokes INIT^XMVVITAE to set up the user's MailMan environment. It invokes HEADER^XM to greet the user and inform the user of new messages. It is normally used only in top-level options; other types of uses should invoke the individual entry points directly. CHECKIN^XM is the entry action for subordinate interactive MailMan options. CHECKOUT^XM is the exit action for all interactive MailMan options. HEADER^XM greets the user and informs of new messages. KILL^XM kills MailMan variables. $$NU^XM Returns the number of new messages a user has and may display the message: "You have # new messages." N1^XM and NEW^XM create a mailbox for a user.		XM
10065	DELETE/SAVE MESSAGE API	Routine	MAILMAN	1995/01/31	APPROVED	Active	Supported		These APIs let you delete a message from a basket and/or save it to a basket: - KL^XMA1B delete a message from a basket (presumes S2 used later) - KLQ^XMA1B delete a message from a basket and put it in .5=WASTE - S2^XMA1B save a message to a basket		XMA1B
10066	CREATE A MESSAGE STUB API	Routine	MAILMAN	1994/11/02	APPROVED	Active	Supported		The API in this routine is the first step in sending a message, when the message text will be loaded directly into the mail global by the calling application (rather than being copied from a temporary "build site" as with ^XMD). This first step is to create a message stub, which is an entry in the Message file (3.9), with no text or recipients. The next step is to add the text into the text field of the message (DBIA 10113). Optionally, the next step is to set any special handling fields: S DIE=3.9,DA=XMZ,DR="<field #>////<value>" D ^DIE Field # Value Causes message to be ------- ----- -------------------- 1.7 P Priority 1.95 y Closed 1.96 y Confidential 1.97 y Information only Example: To force message 100213 to be priority and closed: S DIE=3.9,DA=100213,DR="1.7////P;1.95////y" D ^DIE The final step is to address and send the message, using ENT1^XMD or ENT2^XMD (DBIA 10070).		XMA2
10067	ADDRESSING API	Routine	MAILMAN	1995/02/07	APPROVED	Active	Supported		This routine has four APIs to perform address lookup. They are generally used to address messages and bulletins. Compare them to TOWHOM^XMXAPI (DBIA 2729) and TOWHOM^XMXAPIU (DBIA 2774). DEST^XMA21 Perform an interactive recipient lookup showing XMDUN as the default for the FIRST recipient DES^XMA21 Perform an interactive recipient lookup showing XMMG as the default for the NEXT recipient WHO^XMA21 Perform a non-interactive recipient lookup if X is a local name or network address. INST^XMA21 Same as WHO^XMA21. This one has nothing to do with addressing: CHK^XMA21 Check to see if a user is a member of a mail group.		XMA21
10068	START BACKGROUND DELIVERY TASK	Routine	MAILMAN	1995/02/07	APPROVED	Active	Supported		This routine starts the background mail filer for local mail delivery.		XMADGO
10069	SEND A BULLETIN API	Routine	MAILMAN	1995/02/08	APPROVED	Active	Supported		This API sends bulletins and has the following entry points: ^XMB - Create and send a bulletin in the background (task). EN^XMB - Create and send a bulletin in the foreground (while you wait). BULL^XMB - Interactively select a bulletin, define its parameters, and send it. See the MailMan Programmer Manual, Appendix D, Setting up Bulletins, for information on bulletins, how to set them up, and how to create a bulletin cross reference.		XMB
10070	SEND / FORWARD A MESSAGE API	Routine	MAILMAN	1995/02/19	APPROVED	Active	Supported		Contains the following APIs related to creating, sending, and/or forwarding messages: ^XMD create, address, and send a message EN1^XMD add text to a message, address it, and send it ENL^XMD add text to a message ENT^XMD interactive create, address, and send a message ENT1^XMD forward a message ENT2^XMD forward a message and prompt user for more recipients See the MailMan Programmer Manual, Appendix B, Efficient Use of the API, for some suggestions on how to efficiently create huge messages used for data transfer. I/O variables for the various APIs: DUZ (in, optional) User's DUZ. This is who is actually sending the message. If DUZ is not defined, it defaults to the Postmaster (.5). XMDUZ (in, optional) User's DUZ or free text. This is from whom the message will appear to be. If it is not defined, it defaults to DUZ. If it is free text, it must not be more than 70 characters. XMSUB (in) Subject of the message. Must be from 3 to 65 characters long. If it is less than 3 characters, then "..." will be appended to it. If it is more than 65 characters, it will be truncated. XMTEXT (in) The root of the array, in open format, which contains the text of the message. The array may be a local or global variable, and it must be in a format acceptable to FileMan word-processing APIs. XMSTRIP (in, optional) Characters that should be stripped from the text of the message. Default is none. XMDF (in, optional) If $D(XMDF), addressing restrictions are waived: - ignore 'domain closed' - ignore 'keys required for domain' - ignore 'may not forward to domain' - ignore 'may not forward priority mail to mail groups' - ignore 'message length restrictions to remote addressees' XMMG (in, optional) If XMY is not supplied and the process is not queued, XMMG may be used as the default for the first 'send to:' prompt. (out) Contains an error message if an error occurs. Otherwise, undefined. XMZ (in) Message IEN in MESSAGE file (3.9) of message to be forwarded or altered. (out) Message IEN in Message file (3.9) of message created/sent. XMY( (in) Addressee array. May contain any of the following: User's DUZ, or enough of user's name for a positive ID eg: XMY(1301)="" or XMY("lastname,firs")="" G.group name (enough for positive ID) eg: XMY("G.MY GROUP")="" S.server name (enough for positive ID) eg: XMY("S.YOUR SERVER OPTION")="" D.device name (enough for positive ID) eg: XMY("D.MY PRINTER")="" You may prefix each addressee (except devices and servers) by: I: for 'information only' recipient (may not reply) eg: XMY("I:1301")="" or XMY("I:lastname,firs")="" C: for 'copy' recipient (not expected to reply) eg: XMY("C:1301")="" or XMY("C:lastname,firs")="" L@datetime: for when (in future) to send to this recipient (datetime may be anything accepted by FileMan) eg: XMY("L@25 DEC@0500:1301")="" or XMY("L@1 JAN:lastname,firs")="" or XMY("L@2981225.05:1301")="" (may combine IL@datetime: or CL@datetime:) To delete recipient, prefix with - eg: XMY(-1301)="" or XMY("-lastname,firs")="" Append "@<sitename>" for any addressees at another site: eg: XMY("I:G.group@site.DNS")="" or XMY("lastname,firs@site.DNS")="" or XMY("6102@site.DNS")="" If the sender (XMDUZ) is a recipient, you may specify the basket in the sender's mailbox to which the message should be delivered. eg: XMY(XMDUZ,0)=5 (basket IEN) or XMY(XMDUZ,0)="MY BASKET" (full basket name) If SHARED,MAIL is a recipient, you may specify the basket in SHARED,MAIL's mailbox to which the message should be delivered. eg: XMY(.6,0)=5 (basket IEN) or XMY(.6,0)="MY BASKET" (full basket name) If SHARED,MAIL is a recipient, you may specify the date on which the message should be deleted from SHARED,MAIL's mailbox, eg: XMY(.6,"D")=<date> (any date recognized by FileMan) Sample XMY entries: XMY("USER,LOCAL")="" Addressed to a local user, whose name is USER,LOCAL. XMY("G.MAIL_GROUP)="" Addressed to a local mail group, whose name is in the MAIL GROUP file. XMY("LAST,FIRST@domain_name")="" Addressed to a user, at the site named domain_name. LAST,FIRST must be in the NEW PERSON file at that site. If the local system domain name is domain_name, it will be a local recipient. XMY("G.MAIL_GROUP@domain_name")="" Addressed to a mail group, at the site named domain_name. MAIL_GROUP must be found in the MAIL GROUP file at that site. XMY("D.DEVICE@domain_name")="" Addressed to a device, at the site named domain_name. DEVICE must be found in the DEVICE file at that site. XMY("S.OPTION@domain_name")="" Addressed to an option, at the site named domain_name. OPTION must be found in the OPTION file at that site. XMY("INFO:MAIL_GROUP@domain_name")="" Addressed to a mail group at a remote site. The message will be delivered "information only" to that group, meaning that they will not be able to reply to it.		XMD
10071	GLOBAL PACKMAN MESSAGE API	Routine	MAILMAN	1995/02/19	APPROVED	Active	Supported		This routine contains the following API: ENT^XMPG - Create and send a PackMan message with globals		XMPG
10072	SERVER MESSAGE API	Routine	MAILMAN	1995/02/06	APPROVED	Active	Supported		This API deals with server messages: - REMSBMSG^XMA1C remove a message from a server basket - SETSB^XMA1C put a message into a server basket Server messages are usually placed in one of the Postmaster's server baskets (using SETSB^XMA1C) upon receipt of the message, and deleted from the basket (using REMSBMSG^XMA1C) upon successful processing of the message by the application to which the server belongs. See the Kernel Systems Manual for more information on servers.		XMA1C
10073	MAILMAN: Message Body Access, including Servers	Routine	MAILMAN	1995/02/19	APPROVED	Active	Supported		^XMS3 contains the following application programmer entry point: REC^XMS3 to obtain the next line in a message		XMS3
10091	MAILMAN SITE PARAMETERS	File	MAILMAN	1999/06/23	APPROVED	Active	Supported	4.3
10111	MAILMAN: Maintenance of Mail Groups	File	MAILMAN	1995/01/23	APPROVED	Active	Supported	3.8
10113	MAILMAN: Message Text - Direct Entry	File	MAILMAN	1995/02/20	APPROVED	Active	Supported	3.9	Summary Sites complain about the way their machines seems to slow down considerably when Austin DPC transmissions are created. Large messages may be created in a more efficient way than is being used by most applications. Since all DHCP sites are mandated to migrate to Kernel 7.1 by 12/01/93, all applications can now use this method of creating a message. Technical Background The simplest approach is probably the one people are using. It is pretty straight forward: Load the text of a message into an array Set a couple of variables D ^XMD With short messages, this is also fairly efficient if a local array is used. However, when a large message is built, it usually must be stored in a global array. Then, MailMan must read it and re-write it. This effectively doubles the amount of work the system must do to compile the text of the message. The killing of the temporary global array built to store the data passed to the MailMan programmer interface eats up additional resources. So why not write the text of the message (the data) directly into the message, especially now that it is possible and that all the entry points have been made available and are documented? Examine the examples on the following lines. Example The following steps assume that the standard variables already exist in the partition from either Log-on or because the job is a TaskMan task. Step 1 -- Create a Message with No Text S XMSUB="LARGE DATA TRANSMISSION"; Initialize Subject S XMDUZ="Application X" ; Sender D GET^XMA2 ; Call Create Message Module See Note 1 below! I XMZ<1 G RETRY ; Abort or retry, if returned value <1 Step 2 -- Put Text into Message F L=1:1 S X=$$data^routine Q:X="stop value" S ^XMB(3.9,XMZ,2,L,0)=X S ^XMB(3.9,XMZ,2,0)="^3.92^"_L_"^"_L_"^"_DT Step 3 -- Deliver Message to Recipients S XMDUN="SENDER,LARGEMESSAGE"; A Sender can be free text or you can ; Leave the variable undefined and the ; message will appear to be from the ; user who was logged on. S XMY ("XXX@Q-AUSTIN_'Q'_DOMAIN")="" ; Remote Recipient S XMY(234567)="" ; Individual as a recipient S XMY(234567)="basket name" ; Individual as a recipient in a basket . . . D ENT^XMD ; Call for MailMan Delivery The message will now be delivered. This may not happen immediately because the job of delivery the message is passed off to a 'background filer'. ------------------------------------------------------------------------ Note 1: In versions of MailMan previous to Kernel Version 7, Step 1 may occasionally fail! The interface, upon failing, will cause the job to halt. Because some applications require that a message be created as a result of a background task, a new entry point has been created for Kernel 7 that will not cause the process to be halted. It will instead pass back to the caller an indication of success (XMZ>0) or failure (XMZ<1). The use of this new entry point is illustrated below. IT IS RECOMMENDED that all applications that use the GET^XMA2entry point migrate to the XMZ^XMA2 entry point unless the developers (being aware of the potential problem) decide otherwise. If XMZ=-1 condition is not checked, this large message creation technique will stuff data into ^XMTS(3.9,-1. This may lead to other problems later on! Note 2: There is a way to tell MailMan to run silently via remote domain when ENT1^XMD is called with the XMY("XXX@DOMAIN") set. If the XMCHAN or ZTQUEUED variables are set, MailMan is usually silent. MailMan is silent when ZTQUEUED is present because it is a background job. However, DO NOT set the ZTQUEUED variable yourself! If anyone other than TaskMan ever sets ZTQUEUED, the whole intent of the variable is lost. Callers to the MailMan API functions and callable entry points should set XMCHAN to ensure silent operation. Be sure to kill XMCHAN when completed.

All ICR List

Package: MailMan ICR List