Conference vaxuum::document_ft

    You can specify the queue name as a part of the /batch qualifier:
    
    /batch=(QUEUE=queue-name)
    
    The User's Guide provides more info about /batch, along with a
    reference to the DCL submit command and its qualifiers.

    Ah but, my mob (not being to enamoured of extra typing where it
    is not necessary) don't like typing /batch=(queue=xxx). They want
    the /batch to put it on the correct queue like wot it used to do!
    I'll look in the User Guide.
    
    Gavin

    >Ah but, my mob ... don't like typing /batch=(queue=xxx).
    
    Have somebody who likes typing define a symbol like
    
    		DOCBAT :== DOCUMENT/BATCH=(QUEUE=the_queue_you_like)
    
    and put it in some setup file, or in your login.com.
    
    VAX DOCUMENT used to be overrun with special logical names.  It
    made for a real system management nightmare.  We've gotten rid of
    most of them, but users who care can still define their own for
    the same purposes.
    
    Mark  

    When I'm working on a manual I define a one-line command
    file containing something like
    
    $ DOCUMENT/BATCH=(QUEUE=mumble,.....plusalltherestofthestuffyouneed-
    onadocumentcommandlineincludingthefilenameanddoctypeandoutputdevice
    
    Then I can just do "@FOO.COM" and save a bunch of typing, and it's
    always right (after the 5 or 6 tried it takes for me to get it right
    the first time in the .COM file....)
    

    There's a BATDOC command procedure in this notes file somewhere.
    You can add the /batch to that and have everyone use BATDOC, just
    like in the old days.
    
    Marty

    Mark, I understand your trepidation about logical names. But I think 
    the earlier problem was that the logical names were REQUIRED, not OPTIONAL.
    
    I think an optional logical name for the default DOCUMENT batch queue
    is a very good wishlist item. In fact, you might consider expanding
    the idea to all DOCUMENT processing qualifiers. For example:
    
    	DEFINE DOC$BATCH_DEFAULTS "QUEUE=SDML$BATCH,NOTIFY,NOPRINT"
        DEFINE DOC$PRINT_DEFAULTS "NOTIFY, DELETE"
    
    	etc...
    
    If defined, these logical names would specify the default arguments
    to each qualifier.

    --Andrew

    RE: .6 on "optional" logical names
    
    Logical names can always be added if you use them the right way.
    But I understand your point -- you suggest optional reserved words.
    That's nice and tidy, in a compact example, but it gets out of control
    when you transpose it to our field test site that has 21 LN03s
    spread around the building.  It's reasonable to assume that those
    users would not agree on precisely the same print defaults if they
    had the power to do things their way, and so you'd have to have
    21 logicals.
    
    Similarly, some clusters have many batch queues, with different
    priorities, etc.  This example becomes a lot more complicated when
    you postulate the existence of a unique logical string for each printer
    and each batch queue.  And that's without considering the other
    qualifiers.
    
    These things could be done.  But I suggest that they must be managed
    at the user or group level anyway, and it's better (easier?) to let them
    work out their approach, rather than force on them a scheme we might
    come up with.
    
    The best course will become clearer with experience, and VAX DOCUMENT
    is not yet shipping to the outside world.  (Soon!)  But I've been
    the system manager of an LPS40 during field test.  The LPS40 and
    LN03R print symbionts support the notion of generic queues for each
    type of data (PostScript, ANSI, ReGIS, Tektronix), with the datatype
    tied to the queue by a system logical.  There have been times that,
    for reasons I don't know, the queues have continued to run but the
    logicals have been wiped out.  As a result, users had jobs
    process "normally" through the printer, only to find that they got
    a listing of a PostScript program rather than the page image that
    program described -- even though they put their jobs into the right
    generic queue.
    
    Anyway, don't consider this matter closed.  As we turn the corner
    past "get out V1.0" and address areas of optimization, we will be
    looking at things like this.  This is certainly a legitimate wishlist
    item, as you have labelled it.
    
    Thanks,
    Mark