.comment .comment File: VTL.RNO .comment .comment Description: .comment .comment .comment .comment .comment .comment .comment .comment .comment Author: Rick Webster .comment MSDGO, Factory Automation Systems .comment Caterpillar Tractor Co. .comment .comment Date: August 2, 1984 .comment .comment Modified: .comment 12/19/84 additional documentation on restrictions .comment .PS 60,71 .LM 0 .NHD .OD; .HEADER .SUBTITLE VTL - Virtual Terminal Logger (RSX11M+ only) .HL 1 VTL - Virtual Terminal Logger (RSX11M+ only) .x VTL - Virtual Terminal Logger (RSX11M+ only) .lm +5 .P 0 VTL is a utility to allow a virtual terminal to be accessed from an actual physical terminal. Commands can be entered to the VTL> prompt the same as to an MCR prompt ">". VTL will spawn the command to MCR running on the virtual terminal that VTL creates. Any output directed to the virtual terminal by any spawned task will be displayed on the user's TI: Optionally, the data can be logged to a file at the same time, creating an exact log of all the data that appears on the screen during the interactive terminal session. While VTL is waiting for a spawned task to complete, the user can force VTL to detach his TI: so that he can do something else. In the meantime, VTL will still log everything that would have appeared on the screen to the log file. .LIT Usage: >VTL .eli .p 0 At this point VTL will inform you of the virtual terminal unit number it has created for this session with the message: .lit VTL -- Connected to VTn: where n is the unit number .eli VTL will then attempt to get your log in UIC from system accounting using the undocumented GIN$ directive. It then uses the login uic to log you on. After logon, it will attempt to spawn UIC (the LOG task from the MSDGEN distribution kit) to show the user where he is. If your system does not have system accounting active, the login will not be attempted and you will have to enter the HEL command line yourself. .p 0 As of update "D" of RSX11M+ V2.1 the following quirks are present in the HEL command when it is spawned on a virtual terminal. If your system has a SYSLOGIN.CMD file, it will always be executed. Since the system login file usually chains to a LOGIN.CMD file if present, your login command file will also execute. However, if SYSLOGIN.CMD does not exist then HEL will not execute any login command files. It never displays the LOGIN.TXT file. .p 0 Another inconsistency exists if you enter your own HEL command line to VTL either because SYSLOG (system accounting) is not running or because you previously entered a BYE command. If you enter your account or name followed by a /password, the login text is displayed and the login command file is executed. If you let HEL prompt for the password, the login text is never displayed and the login command file is not executed unless done through a system login command file. This inconsistency may be corrected in future releases of RSX11M+. .tp 10 .p 0 VTL will now issue the following prompt: .lit VTL> .eli This can be treated the same as you would an MCR prompt ">" on your "real" terminal. Anything you type in response to the prompt will be "spawned" to MCR on the virtual terminal. Any output from any tasks running on the virtual terminal will be directed to your terminal and interaction with the tasks is exactly the same as if the tasks were running on your "real" terminal except for some restrictions (See VTL Restrictions). .p 0 The following control characters, if entered in response to the prompt, have special meaning and will not be spawned to MCR: .ls .le;CTRL-Z .b Requests that VTL terminate. VTL will log off the virtual terminal, consequently aborting active tasks and the virtual terminal will be eliminated. .le;CTRL-A followed by .b Treated the same as CTRL-Z .le;CTRL-F followed by .b Toggles log file output. If not currently logging, then logging is enabled. If currently logging then logging is disabled. .els .hl 2 Log file operation .p 0 If logging is enabled, all data that appears on the screen whether input by you or output from a spawned task, is written to a log file which is named VTL.LOG and is placed in the UIC and on the SY: disk in effect on the "real" terminal when VTL was initiated (not necessarily to your current assignments on the virtual terminal). The "VTL>" prompt however is replaced with an MCR ">" prompt and VTL error messages are not entered into the log file. .p 0 The log file is created with the implied carriage control (FD.CR) attribute so that it can be typed on a carriage control device. If the data from any offspring tasks has imbedded carriage return, line feed combinations, VTL will break it up into multiple records stripping the out of the record. This makes the file easier to edit with EDT. .p 0 If the data will exceed the log buffer size, VTL writes out the buffer before loading the new data. This will cause an extra to occur when the file is printed. Since VTL has a 512. byte buffer, any log file in which this occurs can no longer be edited with EDT since EDT will not handle records larger than 255 characters. .p 0 A check is made every minute through a mark time directive to see if there is any data in the File Storage Region (FSR) that has not yet been output to the file. If so then VTL will flush the block buffer (using the FCS .FLUSH routine) and then update the files EOF block. This is done so that the log file can be read by other tasks using a "shared" read, even when VTL has it open. Also it makes the log file "crash-proof". The most that the file will lose is anything that has occurred in the last minute only. .hl 2 Operation After VTL has spawned the command line you entered, it waits for that command to complete before re-issuing the VTL> prompt. During this time, your terminal is attached for unsolicited CTRL-C input. If you enter CTRL-C at this time, VTL will allow you to enter additional commands to be spawned to MCR. VTL will display the following prompt: .lit VTL -- Command> .eli At which point you can enter another command to be spawned to MCR on the virtual terminal. This prompt will time out after 30 seconds if you don't enter a command, echo a _^U and continue where it left off. You can start as many tasks as you want to in this manner but it is important to note however that VTL will not wait for any such commands to complete. When the VTL> prompt is again displayed, it only means that the original command has completed, not any of the ones entered in response to the unsolicited CTRL-C VTL prompt. VTL does however set your terminal to FDX to allow such tasks to continue output to your terminal while the read for the next command is pending. .b The following control characters can also be entered in response to the unsolicited CTRL-C prompt: .ls .le;CTRL-Z or CTRL-A .b Requests that VTL terminate. The user will be asked if this is really what he intended. If so VTL will log off the virtual terminal, consequently aborting active tasks and the virtual terminal will be eliminated. .le;CTRL-F .b Toggles log file output. If not currently logging, then logging is enabled. If currently logging then logging is disabled. .le;CTRL-D .b This causes VTL to detach from TI:, freeing your terminal for other uses. CTRL-D forces logging to be enabled so that data will be logged to the log file but it won't be displayed on your terminal. The terminal will automatically be re-attached when either a spawned task or VTL itself requires input from the user. VTL also displays the last line that would have been written to the terminal had it been attached so that the user has some idea of what the task is asking for. .p 0 An alternate method to have VTL re-attach your terminal is to use the VTLON task. This program will cause VTL if running from the same terminal that VTLON is running on, to re-attach if it is currently detached. It need not be installed and can be activated with: .lit RUN $VTLON .eli .els .hl 2 Why use VTL .p 0 Just having the capability to log onto a virtual terminal and treat it like a "real" terminal may be "neat" but is not really of any great practical use. However the log file and detach features make VTL very useful in several cases. Consider the following scenarios: .ls .le;You want to run a long command procedure overnight and be able to check if it went successfully in the morning (like SYSGEN for instance). But you don't have a hard copy terminal available. If you run the procedure through VTL with logging enabled, it doesn't matter if error messages roll off the screen, they are in the log file. .le;You want to run a long command procedure (like SYSGEN again) and give the user a copy of how you answered the questions. You can do this on a hard copy but what if the paper jams or some other catastropy. Also you might want to have the print on a write only letter quality or laser printer. Again VTL with logging will solve the problem. .le;You need to do a taskbuild that will take an hour or so, you have other work to do in the mean time but you only have one terminal available. Run VTL, start the taskbuild and then use CTRL-D to detach your terminal. Any output or errors will be put in the log file. While this is going on you can use your terminal for something else. .le;You have to write documentation for an interactive command file or program but you don't want to type in the interactive session into a Runoff file. You would like to just run a live session and record all input and output to a file. That's one of the things the log file feature of VTL was designed for. .le;You are running a command file (again like SYSGEN) that asks questions throughout but sometimes has long pauses between questions (like between the executive assembly and SYSGEN phase II). You want to use your terminal for something useful during these pauses but you don't want to conflict with the command procedure and you would like something to get your attention when input is required. Run the command file using VTL and detach during the pauses. VTL will beep your terminal announcing that it is being re-attached when input is required. .els .hl 2 Restrictions .p 0 .ls .le;You can not provide input to tasks which rely on unsolicited character input for their commands (such as RMD). There is no way to pass unsolicited input to a task spawned on a virtual terminal. If you do start RMD for example, it will have to be aborted from another terminal or in response to a VTL unsolicited CTRL-C prompt. .le;You should not run tasks which use special QIO functions of the TT driver. The VT driver only handles a subset of the function codes (see the I/O Drivers Reference Manual). For example, FMS11 uses the IO.RTT function code. This is rejected by the VT driver as an illegal function code and will cause FMS applications to go into an error loop. .b There also appears to be a problem with EDT in screen mode. If you delete to end of line, move to the end of the line using EOL or insert a character on an empty line, EDT goes into some kind of loop and must be aborted. .le;If you use SET commands such as "SET#/VT100=TI:", "SET#/NOWRAP=TI:", etc., you will probably get the error message: .lit SET -- Virtual Terminal Error .eli Such commands are invalid on virtual terminals, but should cause no problems unless you have a command file which checks the exit status of SET commands. If you set up your command files to check if they are running on a virtual terminal and not issue such commands if so then it would make for a cleaner run. The following method can be used to determine if a command file is running on a virtual terminal: .lit .SETF VT ! Assume not a virtual term .TESTFILE TI: .TEST "VT" ! Is it a VT .IF NE 0 .SETT VT ! Yes, if non-zero .eli .le;VTL only knows how to wait for tasks it spawns. It does not know anything about tasks spawned by tasks it spawns. For example if Indirect is executed from VTL and the command file uses a ".XQT#task# or an "INS#task/RUN=REM/EST=NO" and then exits the command file before "task" completes, VTL will issue a prompt even though "task" is still active. This can also happen if you use WHEN (Task serialization utility from MSDGEN) to execute a series of tasks sequentially. VTL will prompt when WHEN exits, not when the last task WHEN spawns exits. If using the single line form of WHEN use: .lit WHEN taskA|taskB|taskC| instead of WHEN taskA|taskB|taskC .eli The trailing vertical bar will cause WHEN to wait until taskC completes. .le;As of Update "D" of RSX11M+ there is a bug in FCS which might make the output of your log file look incorrect if you PIP it to a terminal. If the log file contains escape sequences to position the cursor or whatever, the TT driver will perform a WRAP if more characters than the size of the terminal buffer (SET#/BUF) are output with no carriage return. This is to be expected. However, if you set the terminal to NOWRAP, wrap around still occurs. The culprit is the FCS PUT$ macro. It ignores the NOWRAP setting and performs the wrap unconditionally. .b If PIP used IO.WAL qio's there would be no problem, but PIP is using FCS. The same problem would occur if you wrote a FORTRAN program to read and display the logfile since FORTRAN writes eventually end up as a PUT$. .b If you have a log file that does not display properly (like a log file of RMD running for example), it will help if in addition to setting the terminal to NOWRAP, you also set the buffer to 255. .b An SPR has been sent to DEC on this problem. However it had to be re-submitted since the first one came back with the response that DEC did not plan on correcting this behavior. .le;VTL has no way of knowing if a spawned task issues an IO.KIL. Because of this, tasks using some means of time out on input may not function properly. For example, if you enter a HEL command but don't respond to the password prompt on a regular terminal, HEL will time out and print the message "HEL -- Timeout on response". On a virtual terminal however the Password: prompt will remain until a RETURN is entered. Then the HEL message will be printed if a timeout occurs. .b Another potential problem area is the use of time outs on .ASKx directives in Indirect. Even if the time has been exceeded, the prompt from the .ASKx will remain until a RETURN is entered. .els .lm -5