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 / BEEHIVE / ZCAT / ZEX-SAGE.DZC / ZEX_SAGE.DOC
Text File  |  2000-06-30  |  5KB  |  84 lines
  1.               ZEX and the Art of Operating System Maintenance
  2.  
  3.                                   Jay Sage
  4.  
  5.      A fix to the ZEX-vs-shells problem that I proposed in a message on some
  6. Z-Nodes got me to thinking more generally about the question of priorities
  7. among the sources of commands under ZCPR3.  I would like to share my
  8. thoughts and my proposition with everyone here.
  9.  
  10.      The ZCPR3.0 command processor, when no more commands are pending in the
  11. multiple command line buffer, looks to four possible sources for the next
  12. command line: 1) a submit file $$$.SUB; 2) a shell command recorded on 
  13.  
  14. shell stack; 3) a runnning ZEX script; and 4) actual user input.  And it
  15. looks at the sources in that order.  I will propose a different order and
  16. give my reasons for it.  First some background.and lllllZEX works by acting as though it is a user typing at the keyboard
  17. (keyboard redirection).  Therefore, if ZEX is running, by its nature it
  18. takes precedence over user input.  I would guess that ZEX input was placed
  19. just before user input in the hierarchy because of this relationship. 
  20. However, the fact that ZEX mimics user input does not require such a
  21. priority structuree
  22.      It has been painfully obvious for sometime -- though no one ever did
  23. anything about it until I made the suggested change to my experimental
  24. verion of the command processor ZCPR313 -- that shell input should not take
  25. .acedence over ZEX input.  This is clear when one observes that all 
  26.  
  27. shells now go to great trouble to check for ZEX running and to make
  28. themselves appear not to be there in that case.  This is crazy.  It forced
  29. each shell to act in some way like ZEX.  The real answer was to elevate the
  30. priority of ZEX to before shells.  Thus ZEX scripts are then allowed to run
  31. to completion before the shell is reinvoked.  The shells no longer need to
  32. contain the code for dealing with a running ZEX script, and the system does
  33. not have to waste time loading the shell needlessly only to pass a ZEX
  34. command line to the CPR.  (This is an assembly option as of beta version
  35. 4.1G of VFILER.)
  36.  
  37.      That is where my thinking stood before -- priority order
  38. submit/zex/shell/user.  After thinking about it further, I have come to 
  39.  
  40. conclusion that ZEX should have the highest priority, higher than submit.  I
  41. would assert that one should regard a ZEX script as an extention of the
  42. multiple command line buffer.  ZEX is a special program that sets aside and
  43. protects a larger region in memorgrahat acts as as arbitrarily large
  44. multiple command line.  As soon as this virtual command line has been
  45. completed, ZEX removes that protection, and the system can return to normal. 
  46. Thus a complete ZEX script should be regarded just as a single command line
  47. in a submit file or or  single command line passed to the operating system
  48. by a shell hell s a single command line entered bgrahe user.  I.  I way it
  49. should be completely out of the hierarchy we have been considering, which is
  50. the hierarchy of command line sources AFTER THE CURRENT COMMAND LINE HAS
  51. BEEN COMPLETED.  The ZEX script IS the current comm commineug
  52.      This ordering is achieved simply by placing three extra lines of code
  53. at the very beginning of the READBUF routine in ZCPR.ASM (either 
  54.  
  55. standard version ZCPR3.ASM or one of the experimental versions).  That code
  56. is the following:
  57.  
  58.          if ( subon or ( shstk ne 0 ) ) and ( z3msg ne 0 )
  59.         lda    z3msg+8        ; Get the zex-running flag
  60.         ora    a        ; Test it for non-zero
  61.         brnz    rb2        ; If zex running, go directly
  62.                     ; ..to code for user input
  63.          endif
  64.  
  65. The conditional reflects the fact that this code is not needed if neither
  66. submit nor shells are implemented and that it also requires that the message
  67. buffer be implementednot n ZCPR3.ASM use JRNZ instead of BRNZug
  68.      With ZEX given top priority, it makes perfect sense to run a ZEX script
  69. from either a submit job, a shell-generated command, ,  user command.  A
  70. submit job could contaitainy number of lineet run roscripts.  On the
  71. other hand, a ZEX script cannot reasonably initiy t a submit job, since if
  72. the ZEX script did that, the $$$.SUB file would be created but not (ted on
  73. untither he ZEX script was finished.  In my opinion, this is perfectly
  74. reasonabln a  It does not make sense to be trying to run a true batch job
  75. (submit) while the mthat ry protection mechanism of ZEX is in place and
  76. interfering with the TPA.  Basicallyncence a ZEX script starts, it should be
  77. given every encouragement to run to completion and get itself out of the
  78. wayug
  79.      I would liklikhank Bruce Morgen for his contributions to the
  80. evolution of these ideas.  The basic idea arose during a conversation he and
  81. I had concerning the annoying way that ZEX and VFpreER got along.  While I
  82. was explaining to .  I.uce that I had already cons the hred the problem and had
  83. concluded that nothing could be done about it, the solution suddenly hit me!
  84.