John,
 
To address your question of internal or external environment first,  I'm 
not completely sure I have it right.  For ZCPR30 the Environment is 
external in the file SYS.ENV until you load it.  It is then available to 
programs in memory at the patched (installed) address.	Programs can 
execute faster if it is internal by not having to do a disk access to get 
the environment data and TCAP information.  The later versions of ZCPR 
such 3.3 and 3.4 do not even require patching of the Environment address 
into the utilities.  Also, the package environment specs were required to 
be included in *.LIB files for assembly of ZCPR30 and if any of the values 
or options changed, ZCPR30 requires reassembly.  ZCPR33 and 34 have dynamic 
allocation and can adjust the space for the packages somewhat on usage 
requirments.  I'm not really up on all of the ins and outs of the later 
versions, but the system can be quickly reconfigured to suit the job at hand.  
For instance, I cannot run Z80DIS.COM, a great disassembler from GEnie, in 
the ZCPR30 environment due to insufficient memory.  So, I have to sysgen 
that disk with a smaller operating system which only uses ZCPR1.  With 
ZCPR33 or 34 I could simply reconfigure the system to make additional memory 
available and restore the normal system when the job finished.	But getting 
back to your immediate question, I usually set for internal operation and 
patch the address.  I'm really not sure that we can use external operation, 
but it may work.  I guess you could specify external on a simple program, 
assemble it and see if it works without installation.  This would be a good 
question for the round-table discussions on Wednesday nights.
 
Now, for the purpose of EDITND.COM.  You got me, unless it for temporary 
use for a single session where you did not want to change the disk file.  
Possibilities might be an old disk of submit files that are setup for a 
previous version of your system.  Instead of creating a permanent disk file,
you might just set up the memory environment as it used to be and then run 
the program.  I found it helpful early on to experiment with the system 
using named directories and passwords.	Once I decided how I liked for the 
system to be named, I used MKDIR.COM and set up the *.NDR files.  It's still
handy if you want to experiment with a new naming system to see what works.  Sure, you could do this with MKDIR.COM, but you would have to save and then
load the new *.NDR file after each revision before you could test it.  If I want to run a program for which I would like a different set of names, I just 
load a different *.NDR file.
 
Later, -- ken want to run a program for which I would like a different set of names, I just 
load a different *.NDR file.
 
