Google
 

Trailing-Edge - PDP-10 Archives - SRI_NIC_PERM_SRC_1_19910112 - 7/documentation/exec.tco
There are 37 other files named exec.tco in the archive. Click here to see a list.
                               TCO-number:  7.1004



Written-by:  EVANS                            Creation-date:  28-May-87 16:48:56


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECDE




Problem:  STATSW, STAT, and NOSTAT flags were added to EXEC for compiling of statistics for the "NOS" project. 

Diagnosis:  These statistics are not needed, as "NOS" is no longer a viable project.
Solution:  Remove STATSW, STAT, and NOSTAT from EXECDE.MAC


                               [End of TCO 7.1004]
                               TCO-number:  7.1007



Written-by:  PRATT                            Creation-date:   2-Jun-87 10:06:51


Edit-checked:         Yes    Document:          Yes    TCO-tested:  Yes
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC


Problem:    

Coporate policy states that we will be obnoxious to hackers who are
trying to break into our systems. The EXEC doesn't know how to do this.

Diagnosis:   No code

Solution:    

Make the EXEC type the file SYSTEM:JOB-STARTUP-MESSAGE.TXT when it
starts up. Appropriate text can be placed in this file to either 
warn off intruders or to welcome real users.

The code will do a GTJFN on the file and then mimicking the HELP command,
it will call the TYPE command code.


                               [End of TCO 7.1007]
                               TCO-number:  7.1008



Written-by:  PRATT                            Creation-date:   3-Jun-87 09:41:45


Edit-checked:         Yes    Document:          No     TCO-tested:  Yes
Maintenance-release:  Yes    Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC0




Problem:    

SYSTAT has 2 problems in typing out the origin of a job:

	1)  "SYSTAT ALL" leaves the EXEC in a state where later attempts to
	    do a "SYSTAT username" causes the origin to typeout many 
	    columns away from where it shuold be typed out.

	2) LAT lines in hung in a funny state report 00-00-00-00-00-00
	   as the origin.

Diagnosis:    

1) "SYSTAT ALL" updated the header position word (HDRPOS) for the origin field.
The "SYSTAT username" erroneously used the left over HDRPOS value to skip over
to the incorrect column.

2) The origin code was not checking for a 0 node number.

Solution:    

1) Clear the HDRPOS word at the beginning of the command. 

2) Change the the origin code to skip the host number if its found to be zero.


                               [End of TCO 7.1008]
                               TCO-number:  7.1025



Written-by:  EVANS                            Creation-date:  21-Jul-87 14:46:44


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC1


Related-SPR:  	    95



Problem:  If a user attempts to expunge a directory and gets an error, an unusual
number of pages freed will be displayed.
Diagnosis:  Edit 3045 added an error return and check for "Structure not Mounted"
after the CALL EXPDO. Since EXPDO used to fall through to TYPFRE, the additional
error check caused an explicit CALL TYPFRE to be added to display the number of
pages freed. The error check for unmounted structure continued at label 
EXPUN2, the CALL TYPFRE, if the error was not STRX09. However, in ANY error
case, the "Pages Freed" message shouldn't be printed, anyway. In this case,
TYPFRE received a 36-bit directory number in AC1, when it expected the number 
of pages freed. Ergo, it displayed a very strange number to the user.
Solution:  Move the label EXPUN2: down one line, to the code which steps
to the next directory. This will mean that any failure case will come
here and miss the CALL to TYPFRE, so no "Pages Freed" will be displayed
on any error condition.


                               [End of TCO 7.1025]
                               TCO-number:  7.1031



Written-by:  EVANS                            Creation-date:  31-Jul-87 14:32:15


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECCA	EXECGL	EXECSE




Problem:  This is the first in a series of TCO's for implementation
of DQS and LAT remote printing support in the TOPS-20 EXEC.
Diagnosis:  This is for implementation of the SET REMOTE-PRINTING
SYSTEM-DEFINITIONS command.
Solution:  1. Add REMOTE-PRINTING to the $SET0 table in EXECCA.MAC
          2. Create table $RMPRT for CHARACTERISTIC, PRINTER, and
SYSTEM-DEFINITIONS, with the dispatch for all of them.
          3. Create small dispatch routines for CHARACTERISTIC and
PRINTER. These will display a message indicating that the feature
is not yet implemented, and return to EXEC propmt level.
          4. Create the routine for SYSTEM-DEFINITIONS. As with
the routines mentioned in 3, above, it will be in EXECSE.MAC.
It will set up AC2 with the filename SYSTEM:REMOTE-PRINTING.CMD
and call routine TAKSYS which will initiate the TAKE. A failure
return will output the last system message as an explanation, then
return the user to EXEC prompt level. Success will TAKE the file
then return the user to EXEC prompt level.

                               [End of TCO 7.1031]
                               TCO-number:  7.1061



Written-by:  EVANS                            Creation-date:  21-Sep-87 16:30:18


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECSE	EXECIN	EXECGL	EXECPR	EXECDE	EXECSU




Problem:  This is the second in a series of TCO's which will add the DQS
remote printing facility to the TOPS-20 EXEC. 
Diagnosis:  No code exists in the EXEC to create a table of CHARACTERISTICs
for use in remote printing.
Solution:  Add code in EXECSE.MAC to parse the SET REMOTE PRINTING CHARACTERISTIC
command, and to set up a job-wide table of CHARACTERISTICs for the user. In
addition, add code to EXECIN.MAC to retrieve these CHARACTERISTIC names and
display them on the user's terminal in response to an INFORMATION (ABOUT)
REMOTE-PRINTING command.

                               [End of TCO 7.1061]
                               TCO-number:  7.1068



Written-by:  EVANS                            Creation-date:  30-Sep-87 14:48:59


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECSE	EXECIN




Problem:  This is the third in a series of TCO's which implement the
DQS remote printing feature in the TOPS-20 EXEC.
Diagnosis:  This TCO will cover the addition of code to allow the user
to create "alias" names for remote (which is to say VMS) printer queue/node
name combinations. Each user (job) will be able to set up a list of REMOTE-
PRINTER aliases for use by that user (job).
Solution:  In EXECSE.MAC, create routines to parse the input, store the
"alias" names, queue names, and nodenames in freespace; and make a TBLUK
table for them. Also, create a routine to delete these entries. In EXECIN.MAC,
create a routine to step through the table of printers, and list them
to the user's terminal in a format which shows the relationships among the
"aliases" and either queue/nodename combinations, or other "aliases".

                               [End of TCO 7.1068]
                               TCO-number:  7.1071



Written-by:  EVANS                            Creation-date:  16-Oct-87 11:17:39


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execse




Problem:  SET REMOTE-PRINTING PRINTER help for parsing node name accepted
a node name only, and should accept a LAT Server name.
	Parsing SET REMOTE PRINTING PRINTER used the help string for 
characteristics.
	It was not possible to re-define a deleted alias to a new alias. The
entry stayed deleted.

Diagnosis:  Help string did not include the words "LAT Server".
	Wrong symbol used to move help string into FDB.
	Code did not check for deleted entry, and so used the zero in the
RH of the table to try to find the data to change.
Solution:  Add the words "LAT Server" to the help string.
	Use the correct symbol for the help string.
	Make an explicit check for zero in RH of table. If zero, set a flag
to show deleted entry. In any case, delete the entry and release the
freespace for the string. Then check the flag, and if the entry had been
previously deleted, simply continue and create the new alias. Otherwise,
release the physical printer data freespace and then go make the new alias.


                               [End of TCO 7.1071]
                               TCO-number:  7.1073



Written-by:  EVANS                            Creation-date:  20-Oct-87 14:40:23
Edited-by:   EVANS                            Edit-date:      21-Oct-87 13:25:11


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execqu




Problem:    This is the 4th in a series of TCO's which add the DQS printing
feature to the EXEC.

Diagnosis:    The SET commands for the user to create PRINTERs and CHARACTERISTICs
for use in printing remotely have previously been added to the EXEC. This
change will add part of the code needed to actually pass the information
to GALAXY.

Solution:    In EXECQU, add routines to parse the /CHARACTERISTIC: and 
/REMOTE-PRINTER: switches. Also add routines to place the data in the EQ block
for GALAXY.  Make the EXEC print out "[defaults not implemented]"
in response to  INFO DEFAULT PRINT for /CHARACTERISTICS and /REMOTE-PRINTERs.
Add code to store the queue name in the EQ block, and to light bit EQ.DLR to 
indicate to GALAXY we have a DQS or LAT printer.


                               [End of TCO 7.1073]
                               TCO-number:  7.1077



Written-by:  WONG                             Creation-date:  21-Oct-87 12:54:48


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC4	and	MONSYM




Problem:  SEMI-OPR - The EXEC doesn't know how to ^ECREATE or BUILD a user's
directory with SEMI-OPERATOR privilege.  Also, the INFORMATION DIRECTORY
command doesn't display the SEMI-OPERATOR privilege if the user has that
privilege.

Diagnosis:  This is a new feature and the EXEC doesn't have any code to
handle the above.

Solution:  Add an entry in $$CREAT and $CREAT to define the SEMI-OPERATOR
and NOT SEMI-OPERATOR keyword for the ^ECREAT and BUILD command.  Add a new
routine, ..SOPR, to process the SEMI-OPERATOR keyword.  The NOT SEMI-OPERATOR
keyword is already handled by routine CPRIV.  In routine PR2A, check for bit
SC%SEM and ETYPE the string "SEMI-OPERATOR" for the INFORMATION DIRECTORY
command.  All the code change is in EXEC4.

Also, define a new bit, SC%SEM, for SEMI-OPERATOR in MONSYM.  SC%SEM==1B28.


                               [End of TCO 7.1077]
                               TCO-number:  7.1083



Written-by:  GSCOTT                           Creation-date:  26-Oct-87 16:53:00


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECSU




Problem:  
The bit mask stored for the /CHARACTERISTIC switch for remote printing
is difficult for DQS LPTSPL to interpret.


Diagnosis:  

The design was a little unclear.


Solution:  

Rewrite code in NBTMSK in EXECSU to layout the characteristic into
four words, each containing four left justified 8 bit bytes.



                               [End of TCO 7.1083]
                               TCO-number:  7.1084



Written-by:  EVANS                            Creation-date:  27-Oct-87 15:09:20


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execqu




Problem:  The INFORMATION (ABOUT) OUTPUT and CANCEL PRINT commands do not
currently take a /DESTINATION-NODE: switch for use in the cluster printing
feature.
Diagnosis:  New feature.

Solution:  In EXECQU.MAC, add /DESTINATION-NODE to the switch tables for the
INFORMATION OUTPUT and CANCEL commands; add processing routines to send the
required information to GALAXY in order to receive the necessary data for
the nodename given. Existing code handles the display of the information.


                               [End of TCO 7.1084]
                               TCO-number:  7.1085



Written-by:  RASPUZZI                         Creation-date:  27-Oct-87 15:31:40


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECSU




Problem:  
Mysterious jobs keep appearing on the system with only "(LAT)"
or "(CTM)" as there source and these jobs cannot be logged out.

Diagnosis:  
Some flambyant editing was done to the EXEC. In particular, edit 3029
which is supposed to cause the current job to execute a DOBE% JSYS
until the "Autologout" message has appeared on the user's terminal.
This is bad if the origin somehow gets disassociated with the terminal
because the output of "Autologout" will never complete and the job is
now hung forever.

Solution:  
Instead of making the autologout code wait until the entire message
of "Autologout" is displayed, just have it sleep for 1 second. This
is ample time for the message to appear and then logout the job.


                               [End of TCO 7.1085]
                               TCO-number:  7.1089



Written-by:  RASPUZZI                         Creation-date:  27-Oct-87 16:02:47


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC0




Problem:  
1) User names no longer lineup when SYSTAT NODE is done.
2) SYSTAT NODE * Username does not search all nodes for user.
3) Cluster SYSTAT can be improved for some speed.

Diagnosis:  
1) Off by one error in spacing loop.
2) NODPRT (done when system header is displayed) sets up job range cache
   for SYSTAT. This may not happen if the system part is not requested.
3) Extraneous INFO% calls when getting job information from a remote
   system.

Solution:  
1) Fix loop error.
2) Write new routine CSHJOB to setup job range cache.
3) Rearrange code in NODCHK to not get job runtime using INFO%
   JSYS. Instead, go ahead and get job information and skip it
   if IN%RER is lit (meaning job is not logged in).


                               [End of TCO 7.1089]
                               TCO-number:  7.1091



Written-by:  EVANS                            Creation-date:  28-Oct-87 11:30:43
Edited-by:   EVANS                            Edit-date:      28-Oct-87 11:32:56


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execse




Problem:    EXEC wouldn't build. Got Multiply Defined Symbol error.

Diagnosis:    A new symbol was added to MONSYM. This symbol coincidentally
happened to be the same as a routine name in the EXEC.

Solution:    Since the routine was added as a maintenance edit and the symbol
was added for the 7.0 LAT development work, change the routine name and the
references thereto (from .LATTY to .LTTTY) so as not to wreak havoc on the
7.0 specs.


                               [End of TCO 7.1091]
                               TCO-number:  7.1092



Written-by:  EVANS                            Creation-date:  28-Oct-87 11:35:04


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECDE




Problem:  EXEC grump asks for EMCSSW (EMACS switch) to be set to 1.
Diagnosis:  EMCSSW is now =0
Solution:  Make EMCSSW=1

                               [End of TCO 7.1092]
                               TCO-number:  7.1093



Written-by:  RASPUZZI                         Creation-date:  28-Oct-87 14:01:54


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC0




Problem:  
SYSTAT N used to be short for SYSTAT NO. Now that the NODE keyword
has been added, this no longer works.

Diagnosis:  
N is not a synonym for NO anymore.

Solution:  
Make a new entry in the $SESTA table (SYSTAT keyword table) and
have N be an invisible abbreviation for NO.


                               [End of TCO 7.1093]
                               TCO-number:  7.1099



Written-by:  EVANS                            Creation-date:  29-Oct-87 15:19:39


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execse	execqu




Problem:  Help messages for parsing REMOTE-PRINTER and /REMOTE-PRINTER: switch
did not mention that LAT Port/Service names are limited to 16 characters.
Help message for parsing .CMCFM in SETting CHARACTERISTICs and PRINTERs 
was the default "confirm with carriage return"; did not indicate that to
do so would cause the entry to be deleted if CR typed in second field.
Diagnosis:  Coded that way.
Solution:  Change the code. When parsing REMOTE-PRINTER, have help list
"VMS queue - 31 characters or less or LAT Port/Service - 16 characters or less"

Change the help string for .CMFCM parsed in second field of SET REMOTE
command to  "Carriage return to delete (Characteristic/Printer) name".


                               [End of TCO 7.1099]
                               TCO-number:  7.1100



Written-by:  RASPUZZI                         Creation-date:  29-Oct-87 15:47:21


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC0




Problem:  
Class scheduling items are always displayed when doing a SYSTAT NOD *.

Diagnosis:  
The EXEC should not display these items if no systems in the cluster
are running class scheduling.

Solution:  
Make the EXEC check to see if any system is running class scheduling.
If no one is running class scheduling, then don't display these items.
Also, if a node in the cluster is not returning information, have
SYSTAT show the node name and state "Information unavailable" for that
system.


                               [End of TCO 7.1100]
                               TCO-number:  7.1101



Written-by:  RASPUZZI                         Creation-date:  29-Oct-87 15:55:37


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC1




Problem:  
Remote node not returning information errors out of ^ESEND.

Diagnosis:  
INFO% JSYS ERJMPs to command error parsing when it should be
fault tolerant.

Solution:  
Make REMLIN for loose when it comes to cluster state transitions
when a user is doing a ^ESEND.


                               [End of TCO 7.1101]
                               TCO-number:  7.1106



Written-by:  RASPUZZI                         Creation-date:  30-Oct-87 11:25:16


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC1




Problem:  
After typing ^ESEND /NODE:* USER Message the EXEC prompts for
a selection of node names if the user specified is logged into
multiple nodes. However, if the user is logged into only one terminal
on the selected node, then the EXEC still prompts the user for the
terminal.

Diagnosis:  
In RLICK, the EXEC does not check to see if the user is only logged
into one terminal on this node.

Solution:  
Have RLICK check to see if user is logged into only one terminal
and if so, make that be the victim of the send.


                               [End of TCO 7.1106]
                               TCO-number:  7.1109



Written-by:  EVANS                            Creation-date:   3-Nov-87 15:22:38


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execqu




Problem:  DQS-LPTSPL was not receiving the correct information for the
KILL message to CANCEL PRINT /DESTINATION-NODE:.
Diagnosis:  2 problems: 1) The EXEC was using an old block size which
did not include the two new words KIL.ND (node) and KIL.PD (PID).
2) EBD - Instead of moving the nodename from AC1 to KIL.ND, the code
was moving garbage from KIL.ND into AC2.
Solution:  1) Use KIL.SZ as the size. IT's the end of the block, and will
always be the correct block size.
2) Change "MOVE B" to "MOVEM A" [KIL.ND]


                               [End of TCO 7.1109]
                               TCO-number:  7.1110



Written-by:  EVANS                            Creation-date:   3-Nov-87 16:12:28


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execqu




Problem:  If a default DESTINATION-NODE: is set for PRINTing, it does
not over-ride the node name of the /REMOTE-PRINTER: name.
Diagnosis:  Default values are placed in the EQ block first. In this case,
the remote printer code was over-writing the default in the EQ block.

Solution:  AT RPRNT: check whether the EQ block already has a node name
filled in. IF it does, bypass the code which writes the remote printer
node name, and simply write the queue name into the EQ block.

                               [End of TCO 7.1110]
                               TCO-number:  7.1113



Written-by:  EVANS                            Creation-date:   4-Nov-87 14:00:32


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execqu




Problem:  The user may SET DEFAULT PRINT /REMOTE-PRINTER: or CHARACTERISTIC:, and is told only when typing INFO DEFAULTS that defaults  for remote-printing
are not implemented.
Diagnosis:  There seemed to be no way to determine if defaults were being set,
as the path through the code is identical to that when doing a PRINT command,
except that the default values eventually get stuffed onto a stack to remember 
them. However, a flag "SDF", which is non-zero if SETting DEFAULTs was found.

Solution:  At GPRNTR: and GCHAR:, first test the SDF flag, and if setting 
defaults, type an error message and  return to EXEC prompt level. Because
PRINTing and SETting DEFAULTs uses the same command table, the user will
still see the remote printing switches, but they will not be allowed to
enter a value and assume that the command has succeeded.

                               [End of TCO 7.1113]
                               TCO-number:  7.1118



Written-by:  EVANS                            Creation-date:   6-Nov-87 13:34:41


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execse




Problem:  Can't ^C after SET REMOTE-PRINTING SYSTEM-DEFINITIONS.
Diagnosis:  SETting CHARACTERISTICs code goes PIOFF, then JRSTs to
a routine to create the CHARACTERISTIC, which goes (you guessed it)
PIOFF again. It then goes PION when finished, but (correctly) only
once, leaving the EXEC PIOFF.
Solution:  At SRPCH2: delete an extraneous CALL PIOFF instruction.

                               [End of TCO 7.1118]
                               TCO-number:  7.1131



Written-by:  RASPUZZI                         Creation-date:  12-Nov-87 15:05:04


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC0




Problem:  
%Class scheduling is off on specified systems being displayed when
user does SYSTAT NODE * ALL USER

Diagnosis:  
EBD - wrong test when skipping over message.

Solution:  
Test the right bit, stupid.


                               [End of TCO 7.1131]
                               TCO-number:  7.1135



Written-by:  RASPUZZI                         Creation-date:  12-Nov-87 17:03:16


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC1




Problem:  
Can't send a message via the SEND command to a user that does not
exist on the local system but does exist on some remote system.

Diagnosis:  
SEND code parses user name string with .CMUSR function.

Solution:  
Have SEND code also parse .CMFLD if .CMUSR fails. This will enable
a user to do SEND /NODE:REMOTE FUNGO Message where FUNGO does not
have an account on the local system but is logged into node REMOTE.


                               [End of TCO 7.1135]
                               TCO-number:  7.1136



Written-by:  EVANS                            Creation-date:  16-Nov-87 11:47:21


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execse




Problem:  Once an alias was created, it was impossible to re-define it
if the alias name was the same as the queue/port/service name.
Diagnosis:  Just after field 2 was parsed, a check was made to see if
the user was attempting to set an alias to itself. If this was the case,
we simply returned without doing anything. Missing from this code was
an additional check for a node name, which, if present, would mean that
the user was re-defining something. In this case, the user would type
identical input to field 1 and field 2. This, of course, would fail the
test and simply RET without doing anything. The node name was ignored since
we hadn't been allowed the opportunity to even parse it.
Solution:  Move the check to after all parsing is completed. At DOSRPP:
the first check made is for node name, and if there is one present, we
JRST to another routine. At this point, add the check for field 1
and field 2 being the same (i.e., setting an alias to itself), and if
they are identical, simply RET.

                               [End of TCO 7.1136]
                               TCO-number:  7.1137



Written-by:  RASPUZZI                         Creation-date:  16-Nov-87 13:01:24


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC0




Problem:  
Cannot do a SYSTAT NOD FOO USER if USER is not a valid user name
on the local system even though it is perfectly valid on node
FOO.

Diagnosis:  
SYSTAT command does not parse non-user type name strings (meaning
plain old field via .CMFLD). This prevents the use of SYSTAT for
locating a non-local user.

Solution:  
Write a tremendous amount of code to use that wonderfully miserable
hack called SSTACK that introduces a new SSTACK item. This item will
be SSTACKed as function SY$FLD and the data field will contain a pointer
to a string. This string will either be a wildcarded string or it will
be a non-local user name. The non-local user name is obtained when
the SYSTAT command parses a .CMFLD.


                               [End of TCO 7.1137]
                               TCO-number:  7.1139



Written-by:  RASPUZZI                         Creation-date:  17-Nov-87 14:50:49


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC0




Problem:  
SYSTAT NOD * 0 only shows local system's job 0.

Diagnosis:  
SYSTAT loop uses job number as loop counter and once a job 0
is found, it moves onto the next job. Therefore, only the local
job 0 is noticed.

Solution:  
Check each system in cluster for job 0 before moving on to job
1, 2 etc.


                               [End of TCO 7.1139]
                               TCO-number:  7.1140



Written-by:  RASPUZZI                         Creation-date:  18-Nov-87 10:51:26


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC0




Problem:  
When doing a SYSTAT NOD * ALL, the class scheduling items are being
displayed for systems that are not running class scheduling. This
can be deceiving as these numbers are meaningless.

Diagnosis:  
At SYSCLS, the EXEC is not checking to see if the current node that
the current job is logged into is running class scheduling and therefore,
it attempts to display some numbers.

Solution:  
Enhance CHCLAS routine to light a bit in a mask for each system checked
in the cluster if it is running class scheduling. Then in SYSCLS, check
the bit setting for the current node and if it is not set, then display
spaces for class scheduling stuff.


                               [End of TCO 7.1140]
                               TCO-number:  7.1143



Written-by:  EVANS                            Creation-date:  19-Nov-87 13:07:51
Edited-by:   EVANS                            Edit-date:      19-Nov-87 13:28:44


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execd1




Problem:    EMCSSW is set =1 in EXECDE.MAC, but is =0 in EXEC.EXE.

Diagnosis:    EXECD1.MAC sets it back to zero.

Solution:    Change it to 1 in EXECD1.MAC. NOTE: The comment referring to
this switch (written in 1981) states that if EMACS is KEPT, CONTINUE it
RESTARTs, "which is slow".

Also, change EXECDE.MAC so EMCSSW is =0, and let EXECD1 reset it.


                               [End of TCO 7.1143]
                               TCO-number:  7.1152



Written-by:  RASPUZZI                         Creation-date:   1-Dec-87 15:00:39


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECPR	EXECDE




Problem:  
When SYSTAT was changed to handle wildcarded strings differently
it wasted a whole 512 words to keep the strings in (that's one
less page for PCL and MIC fans).

Diagnosis:  
Wasted memory, yuck.

Solution:  
Change WLDPAG to be synonymous with BUF0. BUF0 is a utility page
that the EXEC uses for IPCF messages and directory sorting so it
is copacetic to use this in the SYSTAT command.


                               [End of TCO 7.1152]
                               TCO-number:  7.1153



Written-by:  RASPUZZI                         Creation-date:   1-Dec-87 15:05:02
Edited-by:   RASPUZZI                         Edit-date:      11-Dec-87 08:47:57


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC1




Problem:    
When doing a local SEND or _^ESEND and an arbitrary field is parsed,
the EXEC says "?User has detached jobs only, send mail instead".

Diagnosis:    
An arbitrary field would not be parsed over a valid user name. When
a field is parsed, USRNO contains a zero and this matches the user
number of all the not logged in jobs for RMSFAL that are detached.

Solution:    
If SEND or _^ESEND parses an arbitrary string and the send is local,
the have the EXEC say "?Invalid username".


                               [End of TCO 7.1153]
                               TCO-number:  7.1160



Written-by:  RASPUZZI                         Creation-date:  10-Dec-87 14:55:36


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC1




Problem:  
^ESEND /NODE:FOO:: does not give appropriate error message.

Diagnosis:  
The command is parsing the ::'s as part of the .CMFLD and
using that as the username which is incorrect.

Solution:  
First, change break mask so that .CMFLD can be used for real
usernames. Then check to see if .CMFLD parsed anything for real.
If not, give ?Invalid user error.


                               [End of TCO 7.1160]
                               TCO-number:  7.1161



Written-by:  RASPUZZI                         Creation-date:  10-Dec-87 15:13:42


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC0




Problem:  
SYSTAT NOD THEP:: does not parse correctly. The EXEC says "?Too
many arguments". Also, there is an extraneous INFO% call in
cluster SYSTAT.

Diagnosis:  
If .CMFLD parsed a null field, have the EXEC handle it. Also
remove extra INFO% call.

Solution:  
If the EXEC parses a null .CMFLD, display "?Invalid keyword, username
or directory".


                               [End of TCO 7.1161]
                               TCO-number:  7.1163



Written-by:  RASPUZZI                         Creation-date:  15-Dec-87 14:35:25


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECQU




Problem:  
PRI /RE<esc> fills in MOTE-PRINTER while PRI /F<esc> simply
beeps the user as if /F was ambiguous.

Diagnosis:  
Some "hair" in the DOSWX macro causes all the job switches to
be built in the file switch table (but invisibly) and all file
switches are invisible in the job switch table. Partial recognition
in the COMND% JSYS ignores invisible keywords providing they are
not first in the keyword table.

Solution:  
Remove said hair in EXECQU. Redo the macro that builds the job switch
table and the file switch table so that there are no invisble entries.
This will cause /F<esc> to produce ORMS from the monitor which is the
correct behavior because FORMS is in the first FDB that COMND% uses.
All other programs work this why, now the EXEC does too. This will
also clean up some sloppiness when using question mark as in /FI?.


                               [End of TCO 7.1163]
                               TCO-number:  7.1166



Written-by:  RASPUZZI                         Creation-date:  18-Dec-87 10:22:56
Edited-by:   GSCOTT                           Edit-date:       6-May-88 09:33:22


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC1




Problem:    

When typing SYS NOD ? or _^ESEND /NODE:? the EXEC does not give the user an
indication that * is legal input. * refers to all nodes in the cluster.

Diagnosis:    

The FDB that is passed to COMND% to parse .CMTOK (the *) does not include a
help text string.

Solution:    

Add help text string and it will say '* for all nodes'.


                               [End of TCO 7.1166]
                               TCO-number:  7.1170



Written-by:  MCCOLLUM                         Creation-date:   5-Jan-88 13:20:39


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	DSKDIR




Problem:  
If the structure a user is connected goes offline and the user subsequently
types a directory command with no arguments, the EXEC responds with an
error message that contains superfluous information such as the PC of
the failing JSYS.

Diagnosis:  
As above.

Solution:  
The GTFDB JSYS in the DSKDIR routine fails in the above situation. Since this
JSYS was never expected to fail in any case, the EXEC assumed an internal
error and printed the PC. Since an offline structure can now cause the
GTFDB call to fail, it will be changed to check for the STRX10 error message
and simply display the JSYS error text when it occurs.


                               [End of TCO 7.1170]
                               TCO-number:  7.1178



Written-by:  EVANS                            Creation-date:  14-Jan-88 15:06:00
Edited-by:   EVANS                            Edit-date:      14-Jan-88 15:07:12


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC1




Problem:    Implement the DELETE Subcommands feature to the 7.0 EXEC.

Diagnosis:  

Solution:    In EXEC1.MAC, add the new subcommands BEFORE, SINCE, LARGER,
and SMALLER to the subcommand table. Add a routine for each of these
which sets a bit in AC0 indicating that the subcommand has been
noticed. Finally, add code in the main loop at DELET1: to check each
of the bits, and if found use GTFDB% to determine if the date or size
input by the user qualifies the current file for deletion. If the 
current file does not qualify, step the JFN and get the next file.
If the file does qualify, DELF% it and then step to the next file.


                               [End of TCO 7.1178]
                               TCO-number:  7.1182



Written-by:  EVANS                            Creation-date:  15-Jan-88 12:51:54
Edited-by:   EVANS                            Edit-date:      15-Jan-88 12:54:18


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC1




Problem:    When using the KEEP subcommand to the DELETE command, if the
user gives a negative number of generations to keep, the command is
executed, but a number of commas equal to the negative number input,
are spewed out on the screen.

Diagnosis:    Code checks for "0" input and gives an error message if it
finds a zero. There was apparently no forethought given to the possibility
that someone, for whatever reasons, would input a negative number.

Solution:    Change the sense of the test to check for "less than or equal
to zero", and change the error message to tell the user that negative
numbers are a no-no, just like zero is.


                               [End of TCO 7.1182]
                               TCO-number:  7.1184



Written-by:  EVANS                            Creation-date:  15-Jan-88 15:03:43
Edited-by:   EVANS                            Edit-date:      15-Jan-88 15:11:14


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC3




Problem:    When a negative number is input to the FIND subcommand to
the DIRECTORY command, the "Storage is full, directory will be printed
in two or more sections" is displayed.

Diagnosis:    There is no check made on the number input, due probably to
a lack of forethought that someone would, for whatever reasons, ask
to FIND a negative number of generations.

Solution:    Add a check to be sure the number is not negative, and if it is,
issue an error message.


                               [End of TCO 7.1184]
                               TCO-number:  7.1187



Written-by:  RASPUZZI                         Creation-date:  19-Jan-88 14:29:04


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC1




Problem:  
The _^ESEND command does not quite build a good enough header
for TTMSG%.

Diagnosis:  
Code exists to make sure that English is properly used. There is
a slight over sight in this code when a user is sending to a
specific terminal. Basically, the header looks like [From USER
on node FOO line X line Y ...].

Solution:  
Make code check to see if "to" has been inserted already. If not,
then make the header look like [From USER on node FOO line X to line
Y ....].


                               [End of TCO 7.1187]
                               TCO-number:  7.1188



Written-by:  EVANS                            Creation-date:  19-Jan-88 15:05:01
Edited-by:   EVANS                            Edit-date:      19-Jan-88 15:05:51


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECSU




Problem:    Grump 139. If ambiguous input is given to the /REMOTE-PRINTER:
switch, the user gets the message "Printer not in table requires
a DESTINATION-NODE".

Diagnosis:    If the name input is not found in the table, it is
assumed to be an arbitrary field. As it is acceptable to enter an
arbitrary field (provided a DESTINATION-NODE: is given, eventually)
we assume everything is fine until <CR>, when we discover that no 
DESTINATION-NODE has been input, thus, the error message.

Solution:    Since question-mark-help will give the user a list of
possible printer names, and if the user types an ambiguous string
and hits <ESC>, the EXEC will beep at them; and since we have to allow
an arbitrary field for the printer name, change the message to say:
"Printer name ambiguous, or not in table and requires a 
DESTINATION-NODE"


                               [End of TCO 7.1188]
                               TCO-number:  7.1189



Written-by:  EVANS                            Creation-date:  19-Jan-88 15:12:20


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  Yes


Program:  EXEC
  Routines-affected:   	EXECP	EXECCS	execin	EXEC4




Problem:  This TCO covers all of the items in the "EXEC Cleanup"
"feature" for release 7.

Diagnosis:  A list of these items may be found in the EXEC Cleanup
Functional Spec. (R70SPC:EXEC-CLEANUP-FUNCTIONAL-SPEC.MEM)
Solution:  The resolution of each item is also in the functional spec.

                               [End of TCO 7.1189]
                               TCO-number:  7.1199



Written-by:  EVANS                            Creation-date:  26-Jan-88 10:57:59


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execin




Problem:  The INFORMATION (ABOUT) JOB command will buy the user a
pushdown overflow error with a non-DECnet ARPAnet monitor.

Diagnosis:  Routine TRYARP: sees if we have ARPA turned on. We CALL
TRYARP:. The only way out of TRYARP is JRST.
Solution:  Don't CALL a routine from which the only way to exit is JRST.
(doctor, doctor, it hurts when I do this)

                               [End of TCO 7.1199]
                               TCO-number:  7.1211



Written-by:  EVANS                            Creation-date:   4-Feb-88 11:07:14


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	execce


Related-QAR:  	    52



Problem:  Command editor doesn't handle VT300's very well.
Diagnosis:  New terminal type not added to EXECCE.MAC.
Solution:  Add VT300 (acting like a VT200) to the table and code in EXECCE.MAC,
thus making the unsupported command editor support the VT300.

                               [End of TCO 7.1211]
                               TCO-number:  7.1232



Written-by:  RASPUZZI                         Creation-date:  18-Feb-88 15:51:04


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECSE	EXECQU




Problem:  
Many IPCF woes in the EXEC. Especially when NEBULA tries to talk
to the EXEC or when you run a private GALAXY.

Diagnosis:  
Truly incredible code.

Solution:  
Fix many broken things in EXECQU. Also, when setting a PRIVATE
world, look for private NEBULA. Also in EXECQU, allow IPCF messages
from NEBULA to come through as if they were from QUASAR itself.


                               [End of TCO 7.1232]
                               TCO-number:  7.1233



Written-by:  RASPUZZI                         Creation-date:  18-Feb-88 17:40:29
Edited-by:   RASPUZZI                         Edit-date:      19-Feb-88 10:20:25


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECCE


Related-QAR:  	    96



Problem:    
Command editor it done broke.

Diagnosis:    
When edit 4097 was made to support VT 300s for the command editor,
the REDIT program ate the _^M's that are sprinkled throughout EXECCE
to back the cursor to the beginning of a line.

Solution:    
Re-insert those buggers so that we can use the command editor again.


                               [End of TCO 7.1233]
                               TCO-number:  7.1242



Written-by:  RASPUZZI                         Creation-date:  25-Feb-88 17:40:04
Edited-by:   RASPUZZI                         Edit-date:      25-Feb-88 17:42:25


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECQU


Related-QAR:  	   106



Problem:    
INFO OUTPUT command hangs right after INFO DECNET command.

Diagnosis:    
Place where INFO DECNET uses as scratch work area is also same
place that IPCF uses for scratch work area (BUF0 - and lots of other
things use this too).

Solution:    
Zero out the .MSFLG word before setting MS.ACK when sending an
IPCF message to QUASAR.


                               [End of TCO 7.1242]
                               TCO-number:  7.1255



Written-by:  GSCOTT                           Creation-date:   7-Mar-88 09:07:58


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	ALL




Problem:  

Copyright outdated for EXEC.

Diagnosis:  

I guess I volunteer.


Solution:  

Put standard corporate copyright into all the usual places.


                               [End of TCO 7.1255]
                               TCO-number:  7.1265



Written-by:  EVANS                            Creation-date:  31-Mar-88 16:46:58


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECSU	EXECQU	EXECSE


Related-QAR:  	    58



Problem:  The /DESTINATION-NODE: switch will not accept a LAT Server
name which contains a hyphen.
Diagnosis:  The parsing for this field was done with the UUO-macro
FNODEX, which parses correct node name syntax. Since node names
do not contain hyphens or any other special characters, the parse
failed. This is only indicative of a larger problem. It seems that
LAT-related names can include the special characters "$", "_", "-"
and "." but none of the parsing for remote printers took this into account.

Solution:  1. Change the WORDX UUO-macro to check for the ASCIZ string
"LAT" before loading up the breakmask to parse the word. If "LAT" is found,
have the routine $WORD: use the new mask "LATMSK" which contains the
appropriate characters.
          2. Add a new entry point to the GETSXB: routine in EXECSU.MAC.
This routine makes ASCIZ into SIXBIT, but does not allow any special
characters. Have the new entry point set a flag so it can be tested
and then skip over the code which disallows the special characters.
          3. Make the /DESTINATION-NODE: switch use the new WORDX feature
to get the LAT Server name, and then call GETSXF: to change to SIXBIT.
(GETSXF: is the new entry point to GETSXB:)
           4. Change the SET REMOTE-PRINTING PRINTER parsing to accept
all 4 special characters in the VMS Queue/LAT Port/LAT Service field.
           5. Make the SET REMOTE-PRINTING PRINTER parsing use the
new-and-improved WORDX UUO-macro for the Node/LAT Server field.


                               [End of TCO 7.1265]
                               TCO-number:  7.1269



Written-by:  RASPUZZI                         Creation-date:   7-Apr-88 15:18:47


Edit-checked:         No     Document:          Yes    TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXEC1




Problem:  
In the _^ESEND code the EXEC misleads users into believing that
they can do a send to all nodes for a specific username. This is
in fact, wrong.

Diagnosis:  
The routine that is obtaining the node to send the message to is
calling VALNDN. VALNDN is using the FDB for command that parses
a token ('*'). This is incorrect.

Solution:  
Make a new entry point to VALNDN (called VALNDE) that does not
expect the '*' to be in the COMND FDB no matter what. Have
the EXEC use this entry point when fishing for the node name
the user is logged into.


                               [End of TCO 7.1269]
                               TCO-number:  7.1271



Written-by:  RASPUZZI                         Creation-date:  12-Apr-88 09:41:22


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECSU




Problem:  
Illegal instruction traps when running the EXEC.

Diagnosis:  
TCO 7.1265 accidently inserted a "B" in the middle of the routine
GETSIX. This assembled into code and is naturally, not a legal
instruction.

Solution:  
Remove said B.


                               [End of TCO 7.1271]
                               TCO-number:  7.1284



Written-by:  RASPUZZI                         Creation-date:   5-May-88 15:49:24


Edit-checked:         No     Document:          No     TCO-tested:  No 
Maintenance-release:  No     Hardware-related:  No 


Program:  EXEC
  Routines-affected:   	EXECSU




Problem:  
EXEC displays "Not logged off" after some error cases (especially
when dismounting a bogus structure).

Diagnosis:  
Would you believe that it is an AC 0 bug? The SETO Q2 at GETSIX is
causing the problem because it is lighting all flags in AC 0 including
the LOGOFF flag (the I am logging out flag). Since the LOGOFF flag is
set, the error routine is erronesouly assuming the user is logging
out and blindly displaying this message.

Solution:  
Add a comma so that the instruction becomes SETO Q2,


                               [End of TCO 7.1284]