PMDF User's Guide
OpenVMS Edition
PMDF-USR-VMS-6.0

7.9.3 Using a "kept" editor

Normally, for each editing operation, PMDF MAIL starts up a new editing session. This may even involve spawning a new subprocess for every operation. This overhead can be avoided by keeping an editing subprocess and attaching to it for each editing operation. When PMDF MAIL is invoked with the command

$ PMDF MAIL/EDIT=KEPT

it will attempt to attach to the subprocess with the name Edit_x whenever the editor is needed. x is the name of the PMDF MAIL process's terminal device with all underscores, dashes, and colons removed. For instance, for the terminal device _FTA123: the expected subprocess name would be Edit_FTA123. The name is truncated to fifteen characters.

If no subprocess exists with the name Edit_x, or if that subprocess cannot be attached to, then PMDF MAIL will attempt to spawn a process with that name and have it execute the command specified with the MAIL$EDIT logical. Appended to this command will be the four parameters described in Section 7.9.1.2 ; the job logical names described below will also be defined. This behavior allows PMDF MAIL to actually create the editing subprocess itself if it does not already exist.⁶ For this reason, it is recommended that in your login command procedure you define MAIL$EDIT to be the name of a command procedure to invoke your editor; e.g.,

$ DEFINE MAIL$EDIT "@PMDF_ROOT:[DOC.EXAMPLES]MAILEDIT.COM"

This procedure would then simply invoke your editor. For instance, the command procedure shown below invokes TPU.

$ VERI = 'F$VERIFY(0)' 
$ ! MAILEDIT.COM - Startup TPU as this process's editor 
$ ! 
$ ! P1 = Input file name 
$ ! P2 = Output file name 
$ ! P3 = Ignored; used by PMDF MAIL 
$ ! P4 = Starting position 
$ ! 
$ DEFINE/NOLOG SYS$INPUT SYS$COMMAND: 
$ P2 = F$EDIT(P2, "COLLAPSE") 
$ P4 = F$EDIT(P4, "COLLAPSE") 
$ IF P2 .NES. "" THEN P2 = "/OUTPUT=''P2'" 
$ IF P4 .NES. "" THEN P4 = "/START_POSITION=''P4'" 
$ EDIT/TPU'P2''P4' 'P1' 
$ VERI = F$VERIFY (VERI)

Keep in mind that the MAIL$EDIT command procedure will be executed from a subprocess; there is no need for it itself to spawn out a subprocess to run your editor.

When the editor is attached to, it should make use of the following job logicals to determine which input file to edit and where to write its output:

Logical name Usage

PMDF_MAIL_INPUT_FILE Input file to edit.

PMDF_MAIL_OUTPUT_FILE Output file to generate; to cancel mail operation, do not generate an output file.

PMDF_MAIL_COMMAND Interactive PMDF MAIL command which requested the editing operation. Always one of EDIT, DIRECTORY, DIRECTORY/FOLDER, FORWARD, READ, REPLY, or SEND.

PMDF_MAIL_START_POSITION If possible, place the edit insert point on this line of the input file. That is, initial line of the file to place the cursor at. First line is line 1.

Logical name	Usage
PMDF_MAIL_INPUT_FILE	Input file to edit.
PMDF_MAIL_OUTPUT_FILE	Output file to generate; to cancel mail operation, do not generate an output file.
PMDF_MAIL_COMMAND	Interactive PMDF MAIL command which requested the editing operation. Always one of EDIT, DIRECTORY, DIRECTORY/FOLDER, FORWARD, READ, REPLY, or SEND.
PMDF_MAIL_START_POSITION	If possible, place the edit insert point on this line of the input file. That is, initial line of the file to place the cursor at. First line is line 1.

A "kept" editor used with PMDF MAIL should do the following:

When the editor subprocess is attached to it should check to see if the PMDF_MAIL_INPUT_FILE logical is defined. If it is, then it was invoked by PMDF MAIL. If the logical is not defined then ignore the following steps.
If PMDF_MAIL_INPUT_FILE translates to a single space character, then an EDIT command with no input file was specified. (PMDF_MAIL_COMMAND should translate to "EDIT".) In this case, do whatever seems appropriate. If PMDF_MAIL_INPUT_FILE does not translate to a single space, then it specifies a file to be edited. Present this file to the user for editing; if possible the editing cursor should initially be placed on the line of the input file specified by the PMDF_MAIL_START_POSITION logical.
When the user is finished editing, the edited message should be written to the file PMDF_MAIL_OUTPUT_FILE provided that it does not translate to a single space.⁷ The editor subprocess should then attach to its parent process, assumed to be the process running PMDF MAIL.
If the user wishes to cancel the operation which invoked the editor, then no output file should be generated. The editor subprocess should simply reattach to its parent.
Use the command
```
$ PMDF MAIL/EDIT=KEPT=process-name
```
to specify an explicit process name, process-name, for the editor subprocess. PMDF MAIL will then try to attach to the subprocess with the specified name; if no subprocess with that name exists, then a subprocess will be created and given that name.

Note

⁶ PMDF MAIL will not attempt to delete this process when exiting.

⁷ Note that at present if PMDF_MAIL_OUTPUT_FILE specifies a file name then it is the same name as that specified by PMDF_MAIL_INPUT_FILE unless the PMDF_MAIL_COMMAND translates to EDIT in which case the user may have explicitly specified a different output file name.

Previous | Next | Contents

PMDF User's Guide OpenVMS EditionPMDF-USR-VMS-6.0

7.9.3 Using a "kept" editor

Note

6 PMDF MAIL will not attempt to delete this process when exiting.

7 Note that at present if PMDF_MAIL_OUTPUT_FILE specifies a file name then it is the same name as that specified by PMDF_MAIL_INPUT_FILE unless the PMDF_MAIL_COMMAND translates to EDIT in which case the user may have explicitly specified a different output file name.

PMDF User's Guide
OpenVMS Edition
PMDF-USR-VMS-6.0

⁶ PMDF MAIL will not attempt to delete this process when exiting.

⁷ Note that at present if PMDF_MAIL_OUTPUT_FILE specifies a file name then it is the same name as that specified by PMDF_MAIL_INPUT_FILE unless the PMDF_MAIL_COMMAND translates to EDIT in which case the user may have explicitly specified a different output file name.