home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / CPM / ZCPR33 / Z3-33 / Z33PNOTE.002 < prev    next >
Text File  |  2000-06-30  |  6KB  |  116 lines
  1.                           ZCPR33 PROGRAMMING NOTES
  2.                           ========================
  3.  
  4. Note Number:    002
  5. Author:        Jay Sage
  6. Date:        June 6, 1987
  7.  
  8.  
  9.  
  10.                      The Design of Shells Under ZCPR33
  11.  
  12.  
  13.      The ZCPR33 command processor follows a very clear and strict hierarchy
  14. for acquiring new commands.  It goes as shown below, with step 1 having the
  15. highest priority and step 5 the lowest.  The way this hierarchy functions is
  16. described in more detail in the ZCPR33 Users Guide.  We will focus here on
  17. the effect this hierarchy has on the design of shells.
  18.  
  19.     1.    Commands pending in the multiple command line buffer
  20.  
  21.     2.    Commands from a ZEX script
  22.  
  23.     3.    Commands from a SUBMIT script
  24.  
  25.     4.    A shell command
  26.  
  27.     5.    User input
  28.  
  29.      The significant change here from ZCPR30 is in the position of ZEX
  30. input.  In ZCPR30, ZEX simply took over the function of user input and thus
  31. appeared in the hierarchy in parallel with user input at the lowest priority
  32. level.  This would have led to very bizarre behavior under shells, and so
  33. special, and rather lengthy, code was included in every shell to see if ZEX
  34. was running and, if so, to feed its input to the multiple command line
  35. buffer.  This resulted in completely useless loads of the shell code for
  36. each line of the ZEX script.  For all practical purposes, ZEX scripts could
  37. not be run under shells.  Since the ZCPR33 command processor has been
  38. redesigned to place ZEX above shells in the hierarchy, this code should not
  39. be included in new shells and should be removed from existing shells.
  40.  
  41.      There was a second inefficiency in the way shells operated that I fixed
  42. shortly after ZCPR3 was introduced (my first programming contribution).  A
  43. little background is required to understand this situation.
  44.  
  45.      Shells have two distinct personalities or functions.  When a shell is
  46. invoked by a user command, its function is to install itself on the shell
  47. stack so that later, when there are no pending commands at levels 1, 2, and
  48. 3 in the hierarchy above, the command processor will invoke that shell
  49. automatically.  When that happens, the shell's second personality comes into
  50. play.  When invoked not by the user but by the command processor, the shell
  51. is to perform its real work (this depends on the kind of shell).
  52.  
  53.      The shells that Richard Conn first created for ZCPR30 worked strictly
  54. according to this model.  This resulted in very annoying behavior when the
  55. user entered the shell command alone on a command line.  The shell would be
  56. loaded from disk, would note that it had been invoked by the user, would
  57. install its command on the shell stack, and then would return to the command
  58. processor.  Next, the command processor, noting that no commands were
  59. pending in the command buffer, would turn to the shell stack and execute the
  60. command on the top of the stack (the shell we just installed).  It would
  61. load the shell from disk (again), and the shell code, noting that it had
  62. been invoked not by the user but by the command processor, would perform its
  63. shell function.
  64.  
  65.      This second loading of the shell from disk was a complete waste of time
  66. and disk activity, since the shell code was already in memory.  Many years
  67. ago I added code to the common shells to prevent this double loading.  When
  68. the shell was invoked by the user, the code I added would check to see if
  69. there were any commands pending in the multiple command line buffer.  If
  70. there were, after installing itself on the stack it would terminate
  71. execution as before.  However, if there were no commands pending, it would
  72. proceed to carry out its shell function immediately.  This cut the time to
  73. start up a shell in half.
  74.  
  75.      The logic behind this approach worked most of the time, but it had a
  76. flaw.  If a SUBMIT job were in progress at the time the shell was installed
  77. by the user, even using a single command on the command line, the shell
  78. should not have started to perform its shell function but should have
  79. returned to the command processor for the next SUBMIT command.  I did not
  80. include the SUBMIT capability in my implementation of ZCPR3, and so I never
  81. thought of this.
  82.  
  83.      With the new command acquisitiion hierarcy under ZCPR33, the shell
  84. should not proceed directly to its shell function when commands are pending
  85. from either the command line, a ZEX script, or a SUBMIT script.  Pseudo-code
  86. for a shell should look like this:
  87.  
  88.     entry:
  89.       Initialization functions
  90.       IF invoked by user (shell bit in command status flag not set)
  91.         push the shell command onto the shell stack
  92.         IF multiple command line not empty, return
  93.         IF ZEX running, return
  94.         IF SUBMIT running, return
  95.         ENDIF (invoked by user)
  96.       Perform real shell function
  97.       Return
  98.     end
  99.  
  100. The three tests that determine whether the code should terminate after the
  101. command is pushed onto the shell stack can be performed easily using calls
  102. to library routines.  The code will look like this.
  103.  
  104.     call    getcl2        ; Z3LIB routine returns with zero flag
  105.                 ; ..reset if there are more commands in
  106.                 ; ..the command line buffer
  107.     jr    nz,ccp        ; If pending commands in buffer, return
  108.     call    getzrun        ; Z3LIB routine resets zero flag if ZEX
  109.                 ; ..is running
  110.     jr    nz,ccp        ; If ZEX is running, return to CCP
  111.     call    getsrun        ; Z33LIB routine resets zero flag if SUBMIT
  112.                 ; ..is running
  113. ccp:    jp    nz,gotoccp    ; If SUBMIT is running, return to CCP
  114.                 ; Else fall through to shell function code
  115. shellfunction:
  116.