#[1]Top DDT Primer and Reference Manual describing DDT version 696 _________________________________________________________ Next: [2]Conventions, Up: [3](DIR) DDT Primer and Reference Manual DDT is the top-level command interpreter most often used on the Incompatible Timesharing System (ITS). It provides three main types of service to the user: invocation of system programs, manipulation of files, and aid in debugging. ITS itself has no command processor, and can be used only via a program. What appears to a user as the "monitor command level" of ITS is actually DDT. This file (the primer, INFO;DDT >) treats the general aspects of DDT, grouping commands according to function; then, in the "reference section" (.INFO.;DDT ORDER), all the commands will be described in detail, in alphabetical order. Before using a command in a complicated way, refer to the detailed description to verify that it will function as intended. * [4]Conventions: Conventions Used in This Document * [5]Rubout: Type-in Conventions * [6]Startup: When DDT Starts Up * [7]Login: Logging in and out * [8]Files: File-Manipulation Commands * [9]Programs: Running Programs with DDT * [10]Jobs: Job Manipulation * [11]Returning: Returning Control to DDT from an Inferior Job * [12]Arithmetic: Arithmetic in DDT * [13]Sophisticated: Sophisticated Job Manipulation * [14]Loading: Loading and Dumping Jobs * [15]Communication: Communication with Other Users * [16]Announcements: Announcements * [17]XFILE: Commands from Files or Programs * [18]Symbols: Symbols * [19]Memory: Examining and Altering Memory * [20]Insns: PDP-10 Instruction Type-in * [21]Literals: Literals * [22]Text: Text Type-in * [23]Modes: Type-out Modes * [24]Type-out: Type-out Commands * [25]Bit: Bit Typeout Mode * [26]Pseudo: Pseudo-memory locations in DDT * [27]Rings: Address and Value Ring Buffers * [28]Execution: Controlling Execution While Debugging * [29]MAR: The MAR or address stop. * [30]Breakpoints: Breakpoints * [31]Stepping: Stepping * [32]Raid: Raid Registers (Self-updating display of memory) * [33]Searches: Word Searches * [34]Patching: Patching Several Instructions over One. * [35]Services: Services for Programs Running under DDT * [36]INLINE: Allows reading commands from TTY in XFILES etc. * [37]Command index _________________________________________________________ Next: [38]Rubout, Previous: [39]Top, Up: [40]Top Conventions Used in This Document When examples of DDT commands are given, upper case letters are intended to be typed in exactly as shown. Angle-brackets ("<" and ">") enclose "meta-variables" which stand for arguments to be supplied by the user. Uparrow ("^"), known to some as circumflex, is used for representing control characters: "^A" signifies a control-A. Other non-alphanumeric characters are to be typed in as shown; some special characters that would be confusing if represented by themselves are represented by "meta-constants", such as "" for a carriage-return. An alternate representation for a would be "^M". Other characters sometimes represented by meta-constants include , , , , , and . Altmode is represented by itself, and its appearance is $. These conventions may be violated in some places, but there will be a note to that effect near the scene of the crime. Numbers are octal, unless followed by a decimal point ("."), in which case they are decimal (this is the same convention as DDT uses for input). Following the ITS 1.5 manual, "bit ." means the 'th bit from the bottom of the 'th 9-bit byte from the bottom, out of the four 9-bit bytes in the 36.-bit word. Thus, bit 1.1 is 1, bit 1.3 is 4, bit 1.7 is 100, and bit 2.2 is 2000. Bit 3.1 is 1,, and bit 4.9 is the sign bit, 400000,, . The last sentence illustrates another convention, that ,, is shifted left 18. bits, or put in the left halfword. The term "ref " will mean "see under in the appropriate part of the reference section". "See the reference section " will mean to refer to the named part of the reference section. See [41]the reference section (ddtord), for the reference section. _________________________________________________________ [41] http://victor.se/bjorn/its/ddtord.html#Top Next: [42]Startup, Previous: [43]Conventions, Up: [44]Top DDT Type-in Conventions DDT has several special action characters that have a specific effect on whatever command is being typed, instead of simply becoming part of the command. They are used for editing input, for aborting operations, or for controlling where DDT's output goes. The most important input editing character is (ASCII code 177), which deletes the last input character. If possible, it will be erased from the screen; otherwise, it will be typed back out to show what is happening (sometimes deletes several characters. When that happens, it types them all out). Other input editing characters are ^D, which cancels ALL unprocessed type-in (in other words, as much as it's possible to cancel), and ^L, which clears the screen and then retypes the unprocessed input. ^S turns off DDT output to the terminal for the command in progress, and other all commands before the ^S itself. ^S is the right character to use if you don't want to see all of a file or directory listing you have printed. Many DDT commands will stop executing if they are silenced, if they think that they are no longer doing anything useful. ^G is a powerful abort command. It will return DDT instantly to its main command-reading level at almost any time. It is so strong that it is dangerous, because it can catch DDT in the middle of updating a data base, such as a job's symbol table or the list of jobs. ^G should be used as a last resort, when DDT hangs up in the middle of a command and ignores other input. In less extreme situations, ^S is usually enough. One time when ^G is ineffective is when DDT has given control of the terminal to another program. To stop the other program and tell DDT to resume reading commands, the character ^Z may be typed on the terminal (, on TV terminals). ^Z or is interpreted by ITS itself, and causes a special unconditionally fatal interrupt to the job that has control of the terminal. DDT notices the fatal interrupt and takes control; it never sees the ^Z per se. There is no reason to type ^Z when DDT itself has control of the terminal (assuming the DDT is top level, as usual), and it causes an error message "??" to be printed. The characters ^W and ^V are used to turn terminal output off and on for long periods of time – for example, if it is desired to execute several commands without any printout on the terminal. ^W turns typeout off, and ^V turns it back on. Typeout will also be turned on if any DDT command reports an error, or if any other program run by DDT returns abnormally. There are also characters ^E and ^B that turn off and on output to a script file. See [45]the reference section (ddtord), for more details. [45] http://victor.se/bjorn/its/ddtord.html#Command_002dlist ^_ (, on TV's) is another character that is interpreted by ITS directly. It is used for communicating with other users, and for specifying various options connected with ITS's handling of the terminal. See the file .INFO.;ITS TTY for details. _________________________________________________________ Next: [46]Login, Previous: [47]Rubout When DDT Starts Up This section's title is purposefully ambiguous. Since ITS has no internal command processor, it is impossible to do anything with a terminal unless some job is deliberately taking input from it. A free terminal is not being read by any job and what is typed on it is ignored. There is an exception, of course, or else it would be impossible to log in. When the character ^Z is typed on a free terminal (or CALL, on a TV) ITS itself loads a copy of DDT to read commands from the terminal. Through DDT, all of the system's facilities are accessible. On ITS, every running copy of a program must reside in a job, which is a virtual machine much like a PDP-10. Every job has two names: the UNAME which identifies the user it belongs to, and the JNAME which distinguishes between the jobs belonging to one user. The first job any user has is the one that ITS puts his DDT in; that job's JNAME is always "HACTRN" (a parody of "FORTRN"). Other jobs may be created by DDT to run other programs in. Note that "HACTRN" is the name of the job; "DDT" is the name of the program that normally runs in it. It is easy to make another copy of DDT run in a different job, and not very hard to get some other program running in the job HACTRN. The first thing DDT does when it starts up is print some status information about the system, including the name of the machine being used (AI, ML, DM, or MC), the version numbers of the DDT and ITS that are running, and the number of users on the system. This information can be obtained at any later time with the :SSTATUS and :VERSION commands. In addition, DDT prints the files SYS:SYSTEM MAIL and (except for network users) SYS:LOCAL MAIL, which contain notices so urgent that everyone should see them before using the system. The "fair share" included in the startup statistics is an indication of what fraction of the total CPU time is available to any one user. It is a measure of the load level on the system. If it is down to 10% or so, you might prefer to wait for the load to be less. _________________________________________________________ Next: [48]Files, Previous: [49]Startup, Up: [50]Top Logging in and out Logging in is the way a user identifies himself to the system and the other users. One should generally log in soon after the beginning of any session. Although being logged in is not actually necessary for most things, it is both convenient (mail you send will contain your name, etc.) and respectful to the other users. Logging in involves specifying a UNAME, or user name, of 6 characters or less (preferably letters). Each user has his own customary UNAME (or several). If you don't have your own UNAME, pick one that nobody else uses (do :WHOIS to find out whether a UNAME is in use already). Most users use their initials or one of their names for a UNAME. For more information on what DDT does with the UNAME specified, see the reference section [51]DDT's UNAMEs (ddtord), for more details. [51] http://victor.se/bjorn/its/ddtord.html#UNAMEs There are two commands for logging in: :LOGIN, which is a "colon command", and $U, which is a "DDT command". Colon commands all start with a colon, which is followed by the name of the command. After the command name come the arguments, if any. In the case of :LOGIN, the argument is the UNAME to log in as. After the arguments, a ends the command. If DDT is given a colon command with an unrecognized name, it tries to run the system program (if any) with that name. "DDT commands" all contain either a special character or at least one altmode (or both); they can take either prefix or suffix arguments depending on the command. As you see, the term "DDT command" is ambiguous, and can mean any command that DDT understands, or can exclude colon commands. The dichotomy of colon commands and DDT commands reflects DDT's evolution. Although most often used nowadays for file manipulation and for running system programs, DDT's original use was in debugging. The other functions were added when ITS was written and DDT was chosen as its executive program. When DDT was used only for debugging, there were no colon commands. Nowadays, the more cryptic DDT commands are (usually) assigned to operations that either pertain to debugging or are frequently used, while the longer but mnemonic colon commands are assigned to operations that are either obscure and infrequent or needed by unsophisticated users. Many important operations have both a DDT command to save typing for expert users and a colon command for new users. In such cases, the DDT command is called the "short form". Logging in is such an operation, with the colon command ":LOGIN" and the short form "$U". ITS normally knows the characteristics of hardwired terminals. For non-local terminals, it may not know them automatically. In that case, before you log in, you should tell ITS the terminal characteristics using the TCTYP program. In the simplest case, that is done by :TCTYP . For example, :TCTYP EXECUPORT tells ITS to treat the terminal as an execuport. :TCTYP by itself tells what ITS belives about the terminal at the moment. :TCTYP HELP will print more information on the TCTYP program. When you log in, if you have received mail from other users, or if there are announcements on the system that you have not yet seen (see :MSGS), DDT will normally offer to show them to you. The offer will look like "–Mail–" or "–MSGS–", and the proper responses are meaning "yes, show me the mail or the MSGS", or anything else, meaning "save them for later". This scheme has the property that an unexpected offer never causes interference: if you type a command after logging in, without waiting to see whether DDT offers mail or not, DDT will obey the command and skip the printing of the mail. DDT makes other offers at various times. They all begin and end with two dashes, and all are answered approximately the same way ( for "yes", anything else for "no"). See the reference section [52]Unsolicited Offers (ddtord), for full details. Meanwhile, :PRMAIL will print mail at any time, and :MSGS will print new system messages. [52] http://victor.se/bjorn/its/ddtord.html#Unsolicited When the :LOGIN or $U command is finished, it prints a "*". Many commands do this, to indicate that they are finished. The "*" is known as the "prompt character", but, unlike the prompt characters of many other programs, it means "operation completed" rather than "ready for more input". Input may be typed at any time, and will be saved by ITS until it is wanted. Some people like to change the "*" to some other string. Ref ":DDTSYM PROMPT" for how. DDT has an "init file" feature that allows a user to customize his DDT. The init file is a file of DDT commands that will be executed automatically on logging in. For details, see the section DDT Commands from Files. Here is a description of the :LOGIN command, in the format that will be used throughout this document: :LOGIN $U logs in as . Then, if there is a DDT init file, it is executed as DDT commands. Otherwise, DDT will offer to print user 's mail and any system messages he hasn't yet seen. After logging in, a second :LOGIN is not allowed. If is already logged in somewhere else, DDT will automatically try to log in as 0, 1, etc. instead, until it finds a name that isn't in use. But even if it logs in as 0, DDT will still remember that it was "supposed" to log in as (see the XUNAME in the reference section [53]DDT's UNAMEs (ddtord),) so it will print 's mail instead of trying to find mail sent to 0. [53] http://victor.se/bjorn/its/ddtord.html#UNAMEs :CHUNAM changes DDT's UNAME to . It has much the same effect as logging out and logging back in again as , except that any user options set in DDT by the previous user remain in effect. The same holds for any ITS options pertaining to the terminal. However, DDT will offer to –Reset All–, and if given a it will make a special effort to reset all such options to their normal states. This involves loading a new copy of DDT from the disk so that all variables in DDT are reinitialized (see $U. in the [54]reference section (ddtord).) [54] http://victor.se/bjorn/its/ddtord.html#Command_002dlist When finished using ITS for a time, you should "log out" to free your resources for other users. The operation of logging out is the inverse of typing ^Z and logging in. It destroys DDT and any other jobs it has created (except for any that have been disowned), so be sure to write out any files you are editing before logging out! The terminal becomes free again, and will ignore everything typed on it except for ^Z (or CALL) and ^_. ITS types a message on the console stating that it is free and also giving the time of day. :LOGOUT $$U logs the user out. Only the top-level job (HACTRN) can log out; if the command is given to a DDT in a job that is not top-level, it is an error. DDT allows the user to have an "exit file" of DDT commands to be executed when he logs out. See :LOGOUT and :OUTTEST in the reference section for full details. One commonly used exit file prints an amusing message or fortune; the file is called STAN.K;ML EXIT and you can use it by making your exit file be a link to it (see :LINK, below). :DETACH detaches the user's whole job-tree. The console becomes free just as if it had logged out, but the jobs are not destroyed. They remain in the system without a console. A detached job is just like a disowned job (see :DISOWN), but got that way differently. The opposite of detaching is attaching. There is a :ATTACH command which performs that operation, but it is too primitive to be convenient in the usual case (don't use it without reading the reference section). However, after logging in DDT automatically checks for the existence of a detached tree and offers to attach to it. After a is typed, the formerly detached tree will be connected to the console (which need not be the same one it was detached from). The new DDT that did the attaching will no longer exist. If something "goes wrong" with the console, a tree may be detached automatically by the system. For example, if a user coming over the ARPA network closes his connection, his tree will be detached. The same thing happens to all users of TV terminals if the TV front-end PDP-11 crashes. When this happens, the detached tree will be destroyed by the system after an hour goes by, unless it is attached first. As described above, logging back in will automatically tell the new DDT to look for the old detached one and offer to attach it. There is a program called REATTACH designed specifically for detaching jobs from consoles and attaching jobs to consoles. It can be used to move your jobs to another console, from either the old console, the new console, or someone else's console. :REATTACH HELP will print its documentation. _________________________________________________________ Next: [55]Programs, Previous: [56]Login, Up: [57]Top DDT's File-Manipulation Commands DDT provides commands for renaming, deleting, and copying files, as well as many other file operations. File commands are followed by the names of the files they operate on. If a command has several arguments, they should be separated by commas. The whole command must be ended with a . If not enough arguments are given before the , DDT will read another line of input, after describing what it wants for the next argument. Examples of file commands are :DELETE FOO BAR which deletes the file named FOO BAR in the current default directory, and :PRINT INFO;DDT > which prints the file DDT > in the directory INFO (this file!). An ITS file's name has four components: the device name, the SNAME (pronounced "S-name"), and two filenames, called the FN1 and the FN2 (The term "filename" is ambiguous, and can refer either to an FN1 or FN2 or to the whole set of four components). This document is a file, and its FN1 is "DDT", its FN2 is "DOC", its SNAME is ".INFO.", and its device name is "DSK". Commonly used device names include DSK which specifies the machine's disk file structure, and AI, ML, MC and DM, each specifying the disk file structure of the named machine (accessed via the ARPA network if necessary). The meaning of the SNAME depends on the device. For devices DSK and AI, ML, MC and DM, the SNAME is the name of the disk directory that the file is stored in. The FN1 and FN2 identify the file in the selected directory. More generally, the device name and SNAME are called the "directory". A directory listing on ITS lists all the FN1-FN2 combinations that happen to exist, at the moment, under a specific device-SNAME pair. A "filespec" is the character string that specifies a file's name. In DDT, a filespec can specify any or all of the four components of filenames. A device name should be followed by a colon; an SNAME, by a semicolon. The FN1 and FN2 have no special delimiter, but are identified by their order of appearance. Thus, DSK:RMS;FOO 100 specifies DSK as the device name, RMS as the SNAME, FOO as the FN1 and 100 as the FN2. On ITS, the FN1 of a file usually identifies the program or information it pertains to, and the FN2 is the type of file or the version number of the file. Thus, DDT's source file is SYSENG;DDT 626. Its binary file is SYSBIN;DDT BIN. When a listing is made, it has the file name DDT @XGP. The names BIN and @XGP indicate the type of file (binary and @-listing, respectively), while the common FN1 of the files indicates that they are all logically associated. The FN2 of the source file, namely 626, is composed of just digits; that identifies it as a version number. By convention, when DDT is edited the new version is written out with an FN2 that is 1 larger. To make this convenient, ITS interprets an FN2 of ">" specially: when reading, it refers to the largest version number that exists; when writing, it creates a new file with a version number 1 greater than the largest existing one. The name "<" is also special. It can be used to delete the oldest (actually, lowest-numbered) version of a file. Note that if there is no numbered version of a file that these will find but there are other files with that FN1, ">" or "<" will chose one of these to refer to, so you can screw yourself by deleting non-numeric ones if you are not careful. This can also be convenient however, if you're trying to refer to a single file where the FN1 is enough to be unambiguous. A filename component omitted in a filespec will be given a default value by DDT, usually the last value specified for that component in either the same command or an earlier one (filenames are "sticky"). For example, after specifying a particular SNAME, all file operations will use that SNAME until a new one is specified. To refer to the last file operated on, a null filespec will serve. New users are often afraid to rely on filename defaults because they aren't sure how exactly the defaults work. Such fear is reasonable, but DDT has a feature to help dispel it. If altmode is typed when DDT is reading a filename, DDT will print the defaults it is using, and go back to reading. If the altmode FOLLOWS a filespec, DDT will print the full name of the specified file, as obtained by merging the filespec with the defaults. Then it will read another filespec using the printed file names as the defaults. If the printed names themselves are satisfactory, a null filespec is enough. This altmode feature makes it easy to learn just what DDT will do with any filespec, and what defaults it uses. More information on features available in filespecs may be found in the reference section "Reading of Filenames". More information on filename defaulting is in that section and in the section "Defaulting of Filenames". Here are the simpler DDT file commands. Notice that some operations have colon commands, some have DDT commands, and some (such as the first one, :PRINT) have both. When there are both, they are equivalent unless otherwise noted. Since all commands that take a filespec as an argument must be terminated by a , the is not explicitly mentioned. :PRINT ^R types the file on the terminal. On display terminals, at the bottom of the screen DDT will pause and offer to print the rest of the file: "–More–". A will tell DDT to print the next screenful of the file. Any other command will be obeyed instead of printing the rest of the file. :DELETE ^O deletes the specified file. It cannot be undone. If you screw yourself, there is some chance that the file can be recovered from the magnetic tape backup storage. It is wise to follow with an altmode, so that you see exactly what file will be deleted, and have a chance for a second thought. Unless you tell it otherwise, DDT will supply the altmode for you (ref ..DELWARN). :LISTF ^F or ^F lists the files in the directory. A directory is specified in :LISTF just like a file, except that only the device name and SNAME are meaningful; the FN1 and FN2 are meaningless and if one is mentioned it will be taken to be the SNAME instead. The short form ^F has an idiosyncratic syntax: either a device name or an SNAME may be given as a prefix argument. With no argument, ^F is a very convenient way to list the directory you have been using recently. See the reference section for more details. Note that the text of the directory listing is generated by ITS, not by DDT. Many programs on ITS have the ability to list a directory, since it is so easy to do. $$^F This is one of DDT's harrier commands, but it can make examining a file directory in certain ways pretty convenient. It uses the DIR: device to print the current default directory. The DIR: device can make many types of abbreviated or sorted listings. (You can omit the and the arguments to this command.) The display you see is controlled by the table of two-word sixbit entries beginning at DIRFN1 (and DIRFN2) inside your DDT. For numeric argument n, the nth FN1 and FN2 are used as DIR: arguments. If the numeric arg is omitted it is assumed to be zero (and DDT uses the arguments at DIRFN1+0 and DIRFN2+0). If a DIRFN2 slot is zero: if there is no argument, we use the default :PRINT FN1; else if there is an argument we use it and set the default :PRINT FN1. If the DIRFN2 slot has something in it: if there is an argument, we use that argument instead. Here follow the DIR: arguments provided in DIRFN1. You can patch them with :SELF if you have another preference. DIRFN1: SIXBIT /NAME1/ ;Table of $$^F DIR: search options. DIRFN2: SIXBIT /UP/ SIXBIT /FIRST/ ;$$1^F finds FN1 0 SIXBIT /SECOND/ ;$$2^F finds FN2 SIXBIT /BIN/ SIXBIT /CDATE/ ;$$3^F ascending in creation age SIXBIT /DOWN/ SIXBIT /SIZE/ ;$$4^F descending in size SIXBIT /DOWN/ SIXBIT /NOT/ ;$$5^F not backed up SIXBIT /DUMPED/ SIXBIT /ONLY/ ;$$6^F just link pointers SIXBIT /LINKS/ Examples of use: FOO$$1^F Shows DIR:FIRST FOO and sets FN1 to FOO LISP$$2^F Shows DIR:SECOND LISP $$2^F Shows DIR:SECOND BIN $$3^F Shows DIR:CDATE DOWN UP$$3^F Shows DIR:CDATE UP PACK13$$6^F Shows DIR:ONLY PACK13 As an additional feature, if you set the DDT variable DIRDIR to -1, $$^F (without a numeric argument) sets your default :PRINT SNAME and otherwise ignores the argument. This lets you look at other directories. Examples: $$0^F Does DIR:NAME1 UP $$^F Still does DIR:NAME1 UP FOOBAR$$^F Changes default dir to FOOBAR and does DIR:NAME1 UP DOWN$$0^F Changes no defaults (now FOOBAR), does DIR:NAME1 DOWN :RENAME , $$^O , changes the specified file's name. Only the FN1 and FN2 can be renamed, so the second argument to :RENAME must not contain a device name or an SNAME. :TPL queues the file for printing on the line printer. Ref also :TPLN. :COPY , $^R , makes a new file containing the same data as an old one. The new file's creation date is made the same as the old one. When you are typing in , the defaults are set to , but to its ACTUAL name, rather than to the name you typed. Thus, if you gave FOO > for , then the default for might be FOO 4. Thus, it is easy to copy a file keeping the same version number. After the :COPY, the filename defaults revert to , as it was specified, in case you want to delete it or copy it to other places. See also th program INSTALL, which is useful for copying a file from one machine to one or more other machines. Also ref the :COPYN command. :MOVE , This is like :COPY, except that it deletes the old one when it's done. It defaults the filenames like :COPY does, as well. :LINK , creates a "link", which is a type of file that actually contains the name of another file to use instead. If RMS;MIDAS MID is the name of a link that points at MIDAS;MIDAS >, then any program that tries to read RMS;MIDAS MID will actually read MIDAS;MIDAS >. Such a link could be created by :LINK RMS;MIDAS MID,MIDAS;MIDAS >. Deleting or overwriting RMS;MIDAS MID will remove the link itself, but not touch the file MIDAS;MIDAS > linked to. :LINK sets the defaults for future commands from , not from . If already exists, :LINK will refuse to work, thus preventing accidental deletion of a file. :LINKN is an equivalent command that doesn't check, and can be used to replace a file with a link. Because many inexperienced users have assumed that ":LINK" set up a com link between terminals, if ..DELWARN is set to 3, :LINK and :LINKN are disabled with warning messages. :LINKF ("F" for "File"), however, is the same as :LINK, and will still exist. It does give a warning message, but does not abort out of it. The commands :SFDATE, :SFAUTH, :SFREAP, and :SFDUMP set various attributes of a file: its creation date, its author's name, its don't-reap bit, and its backed-up-on-tape bit. The commands ^T, $^T, $$^T, ^U, $^U, and $$^U control "filename translations". See the reference section for those commands. The :REAP command marks a file as unimportant, and worthy of deletion as soon as it is backed up on mag tape. There are several commands for handling microtapes: :UINIT, :ASSIGN, :DESIGN, and :FLAP. Since microtapes are hardwarily and softwarily unreliable on the ITS systems, their use is discouraged. _________________________________________________________ Next: [58]Jobs, Previous: [59]Files, Up: [60]Top Running Programs with DDT The simplest way to tell DDT to run a system program is to use the program's name as a colon command; for example, :TECO will load and start a copy of the text editor TECO. Of course, this will not work for a program whose name is identical to the name of one of DDT's built-in colon commands (such as the DUMP program). DDT looks for the program to be loaded as a file named TS , on any of several disk directories: the user's home directory first, then the several system program directories. The command :NFDIR (which see) can be used to add any other directories to the list. Once the other program is loaded and started, DDT gives it control of the terminal. Commands typed on the terminal will all go to the other program and not to DDT. DDT will not read any more commands until the program decides to "return to DDT" or gets a fatal error. However, you can at any time tell DDT to seize control and stop the program by typing ^Z (CALL, on TV's). ^Z acts instantaneously, and makes no attempt to be sure that the program has finished acting on the last command you gave it. If you tell TECO to write out your file, it is your responsibility to wait until the TECO says it is done before typing ^Z; otherwise the file may not really exist yet. If you don't want to wait, you might prefer to use ^_D (Control-_ followed by D; on TV's, Control-CALL), which stops the program only when the program "tries to read" the ^_D. Thus, the program will not be stopped until it finishes processing all previous input. So you can type the ^_D in advance, as well as commands for DDT to execute after the ^_D takes effect. Every user should know about the INFO program for perusing documentation files. Do :INFO and follow the instructions, which will teach you how to find the topic you are interested in. The INFO program is one of the two places to look for documentation on a program; the other is the .INFO.; directory (See File Manipulation) which contains the older documentation written before :INFO existed. As described above, every program resides in a job, which is identified by its UNAME and its JNAME. All the jobs created by DDT to run programs in are "inferiors" of the DDT's job; their UNAMEs are the same as DDT's, which was set by logging in, and their JNAMEs are normally the same as the names of the programs that were run in them. Thus, if user FOO runs TECO, it will be loaded into a new job named FOO TECO. He can also do :DDT to load an "inferior DDT" into the job FOO DDT, and that DDT can then do anything that the top-level DDT in the job HACTRN can do (except log out). The name of a program, such as TECO, is often used as a concrete noun to refer to jobs running copies of it, as in "Now kill your LISPs and start another TECO". Running one program has no effect on any other jobs the user may have, with other programs in them. Thus, after doing :TECO, using ^Z to get back to DDT, and doing :LISP, there will be two inferior jobs: TECO and LISP. LISP will be running, and will have the terminal; TECO will be stopped. The next section of this manual tells how to go back to using the TECO again (with the :JOB and :CONTINUE commands). When running a program, it can be given arguments by putting them between the program name and the . For example, :MIDAS FOO would run the MIDAS assembler and give it the string "FOO" as an argument. Programs treat their arguments in various ways; in this example, MIDAS would assemble the file FOO > and call the binary FOO BIN. Some programs ignore their arguments entirely. What happens if :TECO is done when there is already a job named TECO? That question is complicated, because the user has several options. The best way to explain them is to describe several other commands for running programs, which differ from : mainly in what they do in this problematical situation. The command ^H will run if it isn't already loaded, but simply simply give control back to an existing copy of if there is one. It can be thought of as giving control to the program , after loading it if necessary. The command ^K, on the other hand, always loads a fresh copy of , and destroys any old copy. For naive users (see ..CLOBRF and :LOGIN), ^K asks for confirmation when it is about to destroy a program. Note that "old copy" really means "anything in a job named ". TECO^K when there is already a job named TECO will overwrite whatever is in that job, no matter what program it was. :RETRY is equivalent to ^K, but makes it possible to specify an argument between and the . Finally, there is :NEW , which always loads a fresh copy of the program, but never overwrites any old one! It does this by choosing for the new job a JNAME that isn't in use yet. If there is a job named TECO already, :NEW TECO will load another copy of TECO into a job named TECO0; if TECO0 too is already in use, it will make a job called TECO1, etc. So what does : itself do when a job exists? It acts either like :RETRY or like :NEW , according to a switch that the user can set (..GENJFL – see the reference section). Normally, :NEW is chosen, but for naive users :RETRY is done instead, on some machines. That is to prevent them from unwittingly making many copies of programs. The commands to run programs have features that can be used to load programs from any directory, and to request loading of the program's symbols. The latter is useful mainly when the program is to be debugged. See the reference section "Colon Commands" for full details. _________________________________________________________ Next: [61]Returning, Previous: [62]Programs, Up: [63]Top Job Manipulation After using the commands :, :NEW, ^K, or ^H of the previous section to load programs, one might want to start them and stop them, and eventually get rid of them. DDT has commands for all of those operations. Jobs in ITS are arranged into trees. Each job is either "top level" or has a specific "superior" job. A job can have up to eight "inferiors"; it is their superior. The HACTRN job is always top-level, and the jobs created by it are its inferiors (unless DDT disowns them - see :DISOWN). DDT is capable of examining any job in the system, but full control (starting, stopping, and depositing in memory) is available only for direct inferiors. Even indirect inferiors (inferiors of DDT's inferiors, etc.) can only be examined. In order to act on a job, DDT must know which of the up to eight jobs it has it should act on. For brevity of typing, the commands don't say which job. Instead, most of them act implicitly on the job DDT calls the "current" job. The :JOB command can be used to make any of the existing jobs current, so it can be operated on: :JOB $J if DDT knows about a job named , makes the job current. Otherwise, if such a job actually exists (presumably not a direct inferior of DDT, since DDT always keeps track of those) DDT will henceforth know about it. If it was a disowned job (see :DISOWN), and the top of a tree (disowned jobs too can have inferiors), it is "reowned", which means that it becomes DDT's inferior. In that case, ":$REOWNED$" is printed. If there is no job at all with the name (and the same UNAME as DDT, of course), DDT will create an inferior with that name. A job created in this way has 1K (1024. words) of core (all zero), and no symbols. Its uses might include explicitly loading a program into it, or depositing instructions with DDT and executing them. Whenever the new current job is not a direct inferior of DDT, DDT types a "#" to tell the user. Whenever :JOB selects a job that DDT didn't already know about, "!" is typed. :JOB $J picks a new current job "conveniently". If DDT knows about any jobs other than the current one, one of those others becomes current. Its name is printed out inside an $J command, so that the user can see which job DDT chose. Jobs that need attention (are "waiting to return to DDT" because they have received fatal interrupts) are chosen first. Repeated $J commands will choose different jobs, and won't return to any job until all the other jobs have been current. Thus, repeated $J's are an easy way to visit all of DDT's jobs. Once a job is current, it can be acted on with these commands: :CONTINUE $P makes the current job resume running, and gives it control of the terminal. DDT stops reading commands, and type-in goes to the program in the current job instead. Hardly anyone uses or talks about the long form of this command or the following one, so everyone should know the short forms $P and ^P. $P undoes the effect of stopping a job with ^Z (remember that ^Z stops a job and makes DDT take back control of the terminal). Thus, after using a program, ^Z goes "back up to DDT", and $P can then be used to go "back down into the program". If the current job is already running, but without the terminal (see :PROCEED below), $P just gives it the terminal. :PROCEED ^P makes the current job resume running, but DDT keeps control of the terminal. The job's program is not allowed to read from or type on the terminal, but as compensation DDT continues to read commands even while the job is running. If you should change your mind and decide to give the terminal to the program, use $P. A ^P'd job will keep running even if DDT no longer considers it current; therefore, ^P can be used to make several programs run at once. If ^P is done on a job that is already running (eg, it has been ^P'd already), it has no effect. ^P is not the only way to make a job run without the terminal, but it is the most common way, so jobs running without the terminal are often described as "^P'd" regardless of how they actually got that way. $$^P causes the current job to run without the terminal, like ^P, except that it IS allowed to type out. It can't read anything, however; instead, DDT continues to read commands. Use this for a job which you expect will type out briefly and infrequently in the middle of its processing, so you can let it run while using the terminal primarily with another job. Only one thing inhibits $$^P'd jobs from typing out; that is when the terminal belongs, not to DDT, but to another inferior which has the 40 bit set in its ..URANDM word. The bit can be set by the user (by deposit commands) or with a .VALUE instruction. ^X stops the current job, assuming it was ^P'd. ^X is analogous to ^Z – they both leave a job in the same state – but they are effective in different situations: ^Z stops a job that DOES have the terminal, while ^X stops a job that DOESN'T have the terminal. The reason that they both exist is that ^Z is an ITS command, that tells ITS to stop whatever job has the terminal, while ^X is a DDT command, and can't be obeyed by DDT if DDT has given the terminal away and isn't paying any attention to it. :KILL $^X. "kills" the current job. It ceases to exist, and any data in it is lost. Be sure not to kill a TECO without filing away any information being edited in! The short form $^X does not take effect until a period is typed, because it is so dangerous. After killing a job, DDT tries to find a new current job by doing an $J without argument. The new current job's name is printed inside an $J (select job) command, as in ":KILL TECO$J", showing that the job TECO is now current (DDT often says what it is doing by printing the very commands that the user could give to request what DDT did). $^X kills the job named . It asks for confirmation by typing "–Kill–"; a space tells it to go ahead. Whether you confirm the killing or not, the current job afterward is the same as it was before (unless it was the one you killed). Although DDT can handle up to eight jobs at once, it is good usership to kill jobs that are no longer needed to free their resources for others. Some programs will commit suicide after finishing their work; when that happens, DDT informs the user by printing out ":KILL " just as if the user had killed the program explicitly. The :MASSACRE command kills all your jobs. :LISTJ $$V prints a list of all the jobs DDT knows about. Each job gets its own line, which contains the job's JNAME, status, and job number. The current job is indicated by a "*" at the front of its line. A job's status is usually "P" if it is stopped (proceedable) and "R" if it is running; other states include "-" meaning "never started" ($P isn't allowed), and W meaning "interrupted and waiting to return to DDT". Example: TECO P 34 * DEBUG - 25 SRCCOM R 7 TECO is stopped, DEBUG has never been started, and SRCCOM is running. See the reference section for more details. For users on slow terminals, the $$J command prints out just the line describing the current job. :START $G starts a job at the starting address of the program in it, unlike $P, which starts a job where it last stopped. Many programs do something useful if they are started at their starting addresses after running for a while. For example, a TECO that is hung can be made usable again in that way, without losing any of the data being edited. The $G command is useful also after explicitly loading a program into a job with $L. When DDT creates a job, it gives the job the name of your working directory (in the variable .SNAME, which ref). Most programs will use that variable as the default SNAME for files they reference. Of course, many allow the SNAME to be specified explicitly in their commands. The working directory name is known as the MSNAME (for "Master SNAME"), and it is used also for many other purposes, to be described when they are relevant (ref ..MSNAME). For convenience's sake, 0^F is equivalent to ^F; it lists the working directory. The MSNAME can be set explicitly: :CWD $$^S sets the MSNAME to . Any jobs created subsequently will be passed as the default SNAME to use. Jobs that already exist will not be affected. The MSNAME is to be distinguished from the HSNAME, or home directory, which is initialized the same way as the MSNAME but which is not changed by :CWD. Most programs do not refer to the HSNAME; it is used for finding files that "belong to you", such as your RMAIL file. :CWD $$^S Reset your MSNAME to be your HSNAME. :UJOB Selects the specified job (which can be any job in the system) for examination. If the job is disowned, it will have it's UNAME changed to your UNAME and will be reowned. Otherwise it will remain a foriegn job, i.e. can be examined but not modified or proceeded. :FJOB Is just like :UJOB, except the job will never be reowned. Use this if you ONLY wish to examine the job, but not touch it. :FJOB :FJOB with only one argument assumes the is your own UNAME, and is otherwise identical to :FJOB with two arguments. :JOBP returns 0 if the job exists, non-zero otherwise. :SELF Selects the DDT executing it as the current job, regardless of JNAME. :JOB HACTRN isn't adaquate because the DDT may be running as an inferior, with a different JNAME (say, "DDT), so init files need a different mechanism. _________________________________________________________ Next: [64]Arithmetic, Previous: [65]Jobs, Up: [66]Top Returning Control to DDT from an Inferior Job When DDT runs a program, it gives control of the terminal to that program. From then on, DDT expects that your commands are intended for the program instead of for DDT. Three things can change DDT's mind: * The program can get into severe trouble * The program can tell DDT that it is finished * You can insist, by typing ^Z or ^_D. If any of those three happens, DDT takes the terminal back from the inferior job and resumes reading commands. We say that the job has "returned to DDT" (which does not imply that the return was voluntary). To inform the user of what has happened, DDT prints a description of the job's status and why the it returned to DDT. The conditions that can cause the job to return are called "fatal interrupts", and each one has a name. DDT usually simply prints the names of whichever fatal interrupts happened, but DDT understands some interrupts more and can provide a more hand-tailored response. When a job returns to DDT, DDT's actions depend on the reason for the job's return. If the job is returning because it requested to do so, DDT simply does whatever the program wanted it to do (but the user can disable this; ref ..PERMIT). In this case, DDT is likely just to print a "*" indicating completion of a command, or ":KILL " indicating that the job decided it was done or useless, and DDT got rid of it. If the job returned because it tried to read past a ^_D, DDT just types a "[DDT]". If the job was stopped by a ^Z, DDT normally prints [DDT], but if ..C.ZPRT is set to zero, or if the job is stopped for an error, DDT prints a message containing the job's PC and the next instruction it will execute if $P'd. This information is provided for debugging's sake, and you should not be worried by it. 105) JRST 105 is the sort of message DDT prints when a program is stopped with a ^Z (or a ^X!). ILOPR; 0>> 0 indicates that the program ran into trouble: namely, an ILOPR (illegal operation, in this case executing a zero). In general, the ">>" indicates that the program encountered an error, and the type of error is named. A complete list of error condition names can be found in the reference section "Returning to DDT". Instructions which cause errors are usually "aborted", which means that any side effects are undone and the PC is left pointing at the instruction itself (instead of the next one). As a result, the instruction printed by DDT is not only the next to be executed, but also the one responsible for the problem. An unfortunate exception is the PDLOV (stack overflow or underflow) error, which does not abort the instruction; either the offending instruction is the one before the instruction printed, or the .JPC (address of last jump instruction) points to it. If you see other names in parentheses, as in ILOPR; (REALTM;) 0>> 0 they are names of other non-fatal interrupts which are pending for the job. They are printed for debuggers' convenience, and have no necessary relationship to the reason the job returned. If a program has been ^P'd and is running without control of the terminal, that doesn't stop it from getting into trouble or finishing, and then trying to return. But since the terminal is being used for DDT or some other program, DDT doesn't allow the program to return just yet. Instead, the program has to wait, and in a :LISTJ or $$V its status will be "W" for "waiting". DDT announces this development to the user with a message such as "Job interrupting: ILOPR", "Job finished", or "Job wants the TTY", or something else similar. When an $J with no argument is done, the job will be allowed to return, and DDT will print the appropriate message. "Job wants the TTY" indicates that the job tried to read from or type on the terminal when the terminal belonged to DDT or some other job. "... finished" means that the program has finished its task and has asked DDT to kill its job. In some cases, the job will in fact be killed at the same time you receive the "finished" message. "... interrupting ..." means that the job has encountered an error condition, whose name is printed. _________________________________________________________ Next: [67]Sophisticated, Previous: [68]Returning, Up: [69]Top Arithmetic in DDT DDT's role as a debugging aid requires that it be able to serve as a desk calculator. Expressions involving numbers (fixed or floating point) and arithmetic operators such as +, -, etc. are evaluated, and can be used as arguments to appropriate commands. One command that makes it easy to learn how expressions in DDT behave is the "=" command, which prints the value of the expression preceding it. For convenience in debugging a machine which uses binary arithmetic, numbers input to DDT are normally interpreted as octal. However, if a number is followed by a decimal point then it is (naturally) treated as decimal. Thus, 12 and 10. are equal. A number which has a decimal point in the middle or at the front is interpreted as floating point. Floating point numbers are always read as decimal, and can end with "E" followed by an exponent of ten, as in 1.1e5 which is the same as 110000.0 . These conventions NEVER vary. DDT has separate operators for fixed point arithmetic and floating point arithmetic. This is because once a number has been read in DDT does not remember which one it was. There is no way for DDT to know whether two numbers must be added using fixed point arithmetic or floating point arithmetic, so the user has to specify one or the other for every arithmetic operation. In this matter DDT resembles the machine language that it was intended to debug, rather than high level languages. Specifying the mode is not difficult, however, because the floating point arithmetic operators are just the fixed point operators with a single extra altmode. Thus, floating point addition is done with $+, and floating point multiplication with $*. The = command always prints its argument as a fixed point number. Its floating point equivalent, $=, always prints its argument as a floating point number. Feeding fixed point numbers to the floating point arithmetic operators or $=, and the reverse, will produce seemingly insane results. This are a good way to learn about the PDP-10's floating point number representation and the quirks of its floating point arithmetic instructions. Here is a list of all DDT arithmetic operators: + fixed addition $+ floating addition - fixed subtraction $- floating subtraction * fixed multiplication $* floating multiplication ! fixed division $! floating division # bitwise exclusive-or & bitwise and $_ logical shift $$_ floating scale The &, # and _ operations are done first, multiplication and division second, and addition and subtraction last. The subtraction and division operators may be unary, as in "-50" which has the obvious meaning. Unary fixed point division is rather useless, but "$!2.0" is 0.5. The logical shift and floating scale operations are defined by the PDP-10 instructions LSH and FSC. They LSH or FSC their first operands by a number specified by their second operands. DO NOT use extra spaces inside arithmetic expressions. They are not ignored and will alter the value. This results from the PDP-10 instruction type-in features, to be described later. Terms in expressions can include symbols and some special quantities, as well as numbers. Symbols always have numeric values if they are defined at all, so they are used just like numbers. Since they are useful mainly for debugging, their detailed description is postponed. _________________________________________________________ Next: [70]Loading, Previous: [71]Arithmetic, Up: [72]Top Sophisticated Job Manipulation This section describes other things that DDT can do with jobs, that are less often useful or more difficult to understand than those in the previous section. :UJOB is somewhat like :JOB. It is used to select some other user's job, usually for examination only. It makes it possible to specify the UNAME of the job to be selected instead of just the JNAME. When a :UJOB is done, there are three major possible situations and outcomes: 1. User doesn't exist, or has no job named . In that case, :UJOB doesn't create a job – it is an error. 2. The specified job exists and is disowned. In that case, the job is reowned. 3. The job exists and is not disowned. In that case, it is selected for examination only. Once another user's job has been made known to DDT with :UJOB, just plain $J can be used to make it current again. That $J will print :UJOB to show you what is happening. The same thing will be printed by a $J with no argument, if it selects the foreign job. Commands to run programs, such as ^K, ignore totally any jobs whose unames differ from yours; they go ahead and create an inferior in addition to the unsuitable job. :DISOWN $$^K "disowns" the current job. The job continues to exist, and if it was running continues to run, but it ceases to be DDT's inferior. Any information DDT has about the job that is not actually in the job itself is lost (for example, the starting address and symbols of the program). When a job has been disowned it no longer has a terminal, and if it tries to read from or print on its terminal it will halt. Disowning allows a job to continue to exist after the DDT that created it has logged out or been killed. It makes it possible to leave a job running without tying up a terminal. A disowned job can be reowned by selecting it with :JOB. What's more, any user can reown a job no matter who disowned it, using the :UJOB command and specifying the UNAME of the disowned job, as in :UJOB FOOSH TECO to reown the TECO that user FOOSH disowned. This makes it possible to hand a job to another user. :ATTACH makes the current job (which must be running) become the top level job, in place of DDT. That job's name is changed to HACTRN, and the existing HACTRN job (containing DDT) is killed, along with any other inferiors it may have. :ATTACH is very dangerous for that reason. Its main use is to set up a program other than DDT as the top-level command processor. It is possible to use :ATTACH to do the opposite of :DETACH. Just reown the detached former HACTRN (now called HACTRO or HACTRP or ...) using :JOB, and then :ATTACH it. However, it is probably safer to use the REATTACH program. Type :REATTACH ? for information. :FORGET makes DDT forget that the current job exists. The job is untouched, and even remains DDT's inferior, but DDT no longer knows about it. Why do this? So that DDT will no longer mention the job, and :MASSACRE won't kill it, but the job will remain in your tree (so it can type out on the terminal if it has been $$^P'd). :SNARF When a HACTRN is detached because of trouble with the terminal, but is still basically healthy, it can be attached. When a HACTRN is detached because of fatal errors, it stops running and can't be attached (and, having run into such trouble, it would probably be useless if it were attached). However, its inferiors are likely to be unharmed. The :SNARF command exists to rescue those inferiors from under the sinking DDT. It is meant to be used after reowning that DDT as a subjob of a new, healthy DDT. The dead DDT should be the current job. :SNARF takes away the current job's inferior named and makes it a direct inferior of the DDT executing the :SNARF. Thus, after a HACTRN dies while having a TECO under it (and thus changes to a HACTRO), one can do (in a new HACTRN) :JOB HACTRO to reown the dead DDT, and :SNARF TECO to take the TECO away from it. The job TECO is then an inferior of the new HACTRN, and the HACTRO job can be killed without harm to the TECO. If you try to :SNARF a nonexistent job, a "No such job" error will result. :SNARF works by writing into the current job a program to disown any inferior named , and then doing a :JOB . Thus, :SNARF can garbage the job snarfed from. This is small loss when the job is already dead. $$J changes the current job's name to . The job's contents are unchanged, and so is what DDT knows about it; only the name is changed. Another command, :GENJOB, changes the job's name to a "generated name" chosen not to conflict with any other job. :GZP starts the current job at its program's starting address, without giving it control of the terminal. :GZP is like an instantaneous sequece of $G (:GO), ^Z, and ^P, which is how it got its name. :JCL clears out the current job's comand buffer. ^K clears the command buffer of the job it creates. :JCL puts in the current job's command buffer. must end with a ^C or . : does a :JCL to the job it creates. Note that the command buffer is actually stored inside DDT. Programs use it by reading its contents with a .BREAK instruction, and :JCL cannot retroactively alter what previous .BREAK instructions have read. _________________________________________________________ Next: [73]Communication, Previous: [74]Sophisticated, Up: [75]Top Loading and Dumping Jobs :LOAD $L loads the binary file into the current job, after resetting it. Resetting a job destroys all its core and reinitializes most of its system variables (filename translations are the main exception). Symbols are forgotten and replaced by those loaded from the file. Breakpoints, raid registers and JCL remain set. $L does not use the same set of default filenames that the "File manipulation commands" above use; instead, each job has its own default filenames that $L and all other loading and dumping commands use when acting on that job. When a job is created by $J (:JOB), its loading default names are initialized as DSK:; BIN. Thus, the easiest way to start debugging the file TECO BIN is to do TECO$J $L. When a job is created by a program-running command, the loading and dumping filename is set to the name of the program run. You can specify a list of directories for $L to search for files in using :NFDIR (ref :NFDIR). For more information, see the reference section under "Defaulting of Filenames", and under $L. Some very old binary programs may not load with $L and will require the :OLOAD command (ref :OLOAD). $0L loads a core-image file instead of a binary file. Of course, that's a matter of a different interpretation of the file, since files do not say that they are binary or core image. What actually happens is that the file's contents are copied directly into the memory of the job. This makes it possible to use DDT's debugging commands to examine the contents of the file. The current location address (".") is set to the first word not loaded, to make it possible to find the end of the data easily. The $L command has two other options, which may be used with either $L or $0L. Two altmodes instead of one ($$L or $$0L) cause a merge-load, which does not throw away the core and symbols the job already has. The data in the file replace the data in core, but locations not loaded by the file are unchanged. Symbols already defined are kept, along with any symbols in the file. Also, the job's system variables are not reinitialized. An infix 1 ($1L or $$1L) loads a binary file without its symbols. $L loads with an offset of . A binary file has added to all the addresses it specifies loading into (unfortunately, addresses in the program cannot be relocated). A core image file ($0L) is simply read in starting at . $Y dumps the contents of the current job's core as an SBLK file. :PDUMP dumps the contents of the current job's page map as a PDUMP file. SBLK and PDUMP files have different advantages and disadvantages. SBLK files remember the contents of the job's accumulators, and take up less space because (when dumped by DDT) they are zero- compressed. Zero-compression means that the contents of each nonzero location is recorded; nothing is said about locations containing zero. Because of this, the size of the file varies with the amount of nonzero data in it. Zero-compression facilitates merging programs, since loading a zero-compressed file alters only the locations specifically mentioned in the file. The disadvantage is that a zero-compressed file does not distinguish between memory that is all zero and memory that (virtually) does not exist at all. PDUMP files remember the entire state of the page map. Thus, they record which pages are read only, and record gaps of non-existent memory between existing regions, as well as mapped system pages and pages shared between two slots in the address space. All of that information is used to reconstruct the page map when the file is loaded. The most important use of PDUMP files is for sharable system programs, because when a PDUMP file is loaded all read-only pages remain shared with the file, and will therefore be shared between all jobs that load the file. Both kinds of binary files will contain the job's symbol table and start address. :PDUMPI , This command writes a PDUMP file like :PDUMP, but gives it an indirect symbol table pointer to . This saves space, where the program being dumped is going to map in file to get symbols from anyway, for example LISP. The $Y command provides other types of dumping operations: $0Y writes the core of the current job directly into , as a core-image. If the job has 5K of core, the file will be exactly 5K long. $,$Y dumps, as an SBLK file, the range of core from to , inclusive. Other core locations in the job's memory will simply not be mentioned in the SBLK file and will not be altered if the file is loaded. $,$0Y writes out words through of the current job into as a direct core image. Exactly -+1 words are written. Related commands include :LFILE, which prints out the name of the last file loaded (not necessarily the same as the current $L default file), and $$Z, which sets all or a specified range of the job's memory to a specified value (usually zero). _________________________________________________________ Next: [76]Announcements, Previous: [77]Loading, Up: [78]Top Communication with Other Users The three forms of inter-user communication commonly found on various timesharing systems all exist on ITS. They are known as "sending", "linking", and "mailing". In sending, you compose a message, and when finished cause it to appear all at once on the other user's terminal. Linking (NOT to be confused with file links or :LINK) puts two or more users into a "com link", after which any character typed by any of the users appears on all of the linked terminals. Mailing writes a message that another user will see when he next logs in; unlike sending and linking, it does not require that the other user be logged in when it is done. Com links are good for carrying on a conversation, especially a many-way one, but they have the disadvantage of interfering more with doing work at the same time. Com links really have nothing to do with DDT, since they are implemented by ITS directly. For information on them, see the file .INFO.;ITS TTY. :SEND ^C :SEND @ ^C sends to . Nothing actually happens until the ^C is type. ^C -- Sends the message ^D -- Flushes the message ^K -- Retypes the message, without clearing the screen ^L -- Clears the screen and retypes the message ^R -- Retypes the current line ^U -- Kills the an input line ^W -- Kills a word The message can be any number of lines long. When the ^C is typed, will see printed on his console: [MESSAGE FROM at