Conference vaxuum::document_ft

I personally never use batch.  If I'm interested in what's happening,
I run DOCUMENT interactively (I really use my own custom COM file posted
elsewhere in this conference).  If I'm sure that my document builds,
I then run document using the DCL command:

$ Spawm/Nowait/output=nl:/notify {command string}

and just let it cook.  Then, while I'm waiting, I go heckle people 
in notes :-)...

BobW

On our system, we have DOCUMENT/BATCH defined as a local command, 
BATDOC. As a rule, we use BATDOC instead of DOCUMENT, because we 
have a large number of system users.

What type of course are you developing: CAI, hardcopy, video ?

    From a system manager's point of view, /BATCH ought to be the default
    on any but single user systems. But seriously, I think /BATCH should
    be recommended for any full processsing. The only exception is if
    you only want to check for coding errors: i.e. DOCUMENT/NOTEX.

    --Andrew

    Most of the users on our systems use /batch regularly. This is
    particularly true when the systems are heavily loaded. Personally, I
    would not like /batch to be the default; I'll let the others speak for
    themselves. I like watching what's happening. I also get a chance to
    keep my reflexes sharp by typing <ctrl/y> once in a while. Sometimes
    I'll keep a subprocess around, using it exclusively for Document
    processing. This save on process creation time and expense. I agree
    that large jobs ought to be done in batch; that's not enough to warrant
    changing the defaults, though. 
    
    The new /list qualifier is just dandy. I wind up using it with each
    document, mostly as a debugging tool. It's also handy to have the
    command line available for future reference. Still, I don't think that
    it should be the default. I know of no other language that does that.
    Document has done such a good job at deleting extra files that it would
    be shame for it to start creating more. 
    

 
  We insist that out users use BATCH for their DOCUMENT processing.

  We have a large number of writers on the system.  If we let them all
  run DOCUMENT interactivly, interactive response for editting etc. would
  suffer considerably.

  We too have defined a symbol BATDOC to be DOCUMENT/BATCH=<longlistofswitches>

  DOCUMENT seems to be very CPU intensive.  One day I ran image accounting
  on the system and found 40% of our prime time CPU time on our 785 went to
  one image, DOCUMENT.  Of course that was BL06 DOCUMENT, I'm sure BL08
  DOCUMENT is far more efficient :-)

    ..Paul

    I very seldom use Document in batch.  Only when I've got some trivial
    change that I know won't adversely affect an already successful
    document.  On the 8600 we normally use they DO NOT INSIST that users
    use BATCH.  I"ve been on systems where everyone was FORCED into batch.
    It usually has minimal success, major screaming, and users wasting
    valuable time trying to get around the imposed limits! 
        
    I only use /LIST once in a while.  

    I LIKE /NOLIST /NOBATCH  as defaults.
    
    Dave

    I think most of the user's on our VAXcluster do their DOCUMENT
    processing interactively, as opposed to BATCH.  I too, do most of
    my processing interactively, unless its a large document or bookbuild,
    then I send it to batch just so as not to tie up my terminal.  I
    know I can spawn document interactively, but to me, that doesn't
    seem very fair to the other interactive users.
    
    I guess I'd vote for staying with the current defaults.
    
    -tl

    To use /BATCH or /NOBATCH depends mostly on the size of the memo, file, or
    book.  If I process a memo, I'll do it interactively. A book or
    element file, I'll use /BATCH.
    
    There are users who just use DOCUMENT for MEMOs and OVERHEADs who
    don't want to know about qualifiers (what is a command?), but for
    Diane's course, I suspect they have prereq's of knowing DCL and
    probably are writers producing large books.
    
    To have /LIST as a default with /NOBATCH makes some sense.  To have
    /LIST and /BATCH seems redundant (.LOG and .LIS file), especially as 
    defaults. 

    As Andrew (.3) pointed out, the way the system manager has set up the
    working set values and such for interactive users and batch queues may 
    determine whether one should use interactive or batch. Some system 
    managers may *require* batch use on their systems.    

    For the writers in our group I strongly urge using /BATCH, whenever the
    output is expected to run to 5 or more pages.  One of our clusters even
    has batch queues set up expressly for processing software manuals using
    DOCUMENT. 
    
    I do, however, agree with those folks who argue that the default
    should continue to be interactive mode.

    I think that we should remember that DOCUMENT is used by a number of
    different types of users, those producing large books, and those
    producing small documents. Whether the processing should be done in
    batch, depends upon a serveral of critera: Does the user wish to wait?
    Does the users system have the necessary interactive resources? Is the
    user using LSE ? I know that locally we do not impose anything on
    users, yes, we have a large time sharing cluster, not just for
    DOCUMENT, and we don't notice DOCUMENT running!
    
    As for /LIST being the default, normally for programming language
    compilers, /LIST is defaulted for BATCH and /NOLIST for INTERACTIVE.

    Peter

    I agree that the defaults should remain /NOBATCH and /NOLIST.
    As mentioned in 444.10, I think /LIST should be the default for 
    batch processing.

    If it's a timesharing system, /BATCH is absolutely the ***ONLY***
    way to go.  Run MONITOR PROCESS/TOPCPU sometime and watch a 
    non-batch DOCUMENT job grab 75% to 97% of the CPU, with other
    users waiting several seconds for their edit keystrokes to echo.

    I think everyone is in agreement that batch is the only way to go
    in certain cases, but its certainly not DOCUMENT's place to make
    the judgement of when to use batch and when not to use batch.  Simply
    for consistency sake, I'd say you have to leave the defaults as
    they are.  No other product that I'm aware of defaults its processing
    to be done in batch.  I see it as sufficient that DOCUMENT allows
    a /BATCH qualifier at all!
    
    -tl

    Re .13:
    
    Agreed.

    RE .12
    
    The reason a process will use 75% to 90%+ of cpu is NOT because
    it is DOCUMENT, but because the processor has nothing else to do!
    VMS gives all processes of the same priority the same quantum of
    time to execute, if after that time, about 10 microseconds, another
    process requires the CPU then it is given it. Saying that DOCUMENT
    uses to much of a machine is not valid, as VMS looks after processes
    fairly. All it means is that users of the same priority as the DOCUMENT
    process must share the machine time, as most interactive processes
    are usually in LEF, waiting for some input/output I don't think
    it is a fair conclusion! It is up to the system manager to decide
    on what and how software runs on his system.
    
    Peter

    We try to run mostly in batch mode. Whenever a number of people
    (and we have a lot of DOCUMENT users) run their files interactively,
    along with the BLISS and PASCAL compilers, we end up with virtually
    *no* response time.  Life seems to be easier on our system when
    we run batch.  
    
    joan g.

    If the default remains /NOLIST, the use of the /LIST qualifier should 
    be recommended for new users.
    
    Sure the default for /BATCH is /NOBATCH. But what *really* is the
    cost of creating a .LIS file? The answer is probably in disk blocks,
    not in CPU seconds.     
    
    Certainly, at this late stage of pre-V1.0 DOCUMENT, don't make a
    change unless absolutely necessary. 
    
    The system manager who runs the system Joan reports in .16 should
    perhaps warn his/her users that it is possible to lower the base
    priority and possibly working set values if people don't cooperate
    with running long CPU-intensive jobs in batch mode.
    
    Mike

    Re: .15
    
    The CPU DID have other things to do: my attempt to do editing, for
    example.  My attempt to use MAIL, for example.  The response time
    I got could be measured with a sundial.  When two or three interactive 
    DOCUMENT jobs run on our system, the system DIES.  DOCUMENT is a CPU
    hog.  I know the theory of timesharing.  I know it "shouldn't" happen
    that way.  But it does.
    
    I'm not sure who we're planning to sell DOCUMENT to, but I'm pretty
    sure not all of them are going to be running on 5-machine clusters
    of VAX 8700s.  I greatly fear that we are going to have a lot of
    annoyed customers when their systems slow to a crawl and our salesmen
    try to pacify them by saying, "just buy another CPU."  That is not
    going to go over well at all.  

    I don't know that "compiling" three or four large documents at once
    destroys throughput much more than compiling three or four large
    PASCAL (or other high-level language) programs at once.  Those things 
    have the same kind of work to do, and it really chews up the CPU.
    That, in general, is the nature of life in the world of timesharing.
    
    In all fairness, PASCAL, C, etc., have been products for a lot longer
    than the tag translator and DEC TeX, and so have been much more
    finely tuned (through time).  There is undoubtedly a lot of room for 
    improvement in our components.  We will analyze performance, identify 
    areas of concern, and make those improvements -- but not in the next 
    two weeks.
    
    (Yes -- we have only two weeks left to make planned adjustments
    to VAX DOCUMENT V1.0.)
    
    Mark

    Remember BL4? Talk about slow...
    
    I am especially impressed with the performance improvements made
    in the tag translator in succeeding baselevels. It looks like DECTEX
    (is that what you're calling our version?) is now ripe for improvement.

    Marty

    We'll be running some performance analysis tools in the next week
    or two to attempt to understand what the parameters are for tuning
    your PROCESS and your SYSTEM to the running of DOCUMENT.  Notice
    that I did not say "tuning DOCUMENT" to run on your process/system.
    
    We don't have time to do any more tuning of DOCUMENT before v1.0,
    but we can at least find out enough about it to tell you what your
    process and system parameters need to be to guarantee good performance.
    
    If you read the ADA installation guide you will find the kind of
    information that we hope to provide.