Conference vaxuum::document_ft

    Steve,
    
    You probably have a valid point for the product. For folks
    using bl07 though, why don't others have trouble using /PRINT= or /BATCH=
    when, for instance, many people use global symbols (process or
    system-wide) like:
    
    	PR*INT :== PRINT/NOTIFY 
    	SUM*BIT :== SUBMIT/NOPRINT/KEEP/NOTIFY?
    
    How do you assign your symbol name? Using a /QUE= qualifier? I use 
    a specific symbol name instead of the PRINT command for a specific 
    printer, such as:
    
    	LN03 :== PRINT/NOFEED/PASSALL/QUE=LN03_PRINT/NOTIFY
    

Redefining the PRINT symbol wouldn't work, because it's not being done in a
 subprocess.  DOCUMENT chains to the PRINT command.
  <_Jym_>

    What about the following workaround (for DOCUMENT, not for the user):
    
    CALL LIB$DO_COMMAND ('$ PRINT_COMMAND_WITH_FANCY_STUFF rest of your
    				command')
    
    PRINT_COMMAND_WITH_FANCY_STUFF is most unlikely to collide with
    any user defined DCL symbol; and as DCL parses only the first four
    characters not bothering about the rest you get back your original
    DCL PRINT command.  :-)
    
    Hans

    Why doesn't DOCUMENT use the $SNDJBC system service to queue print
    jobs?
    
    Peter

{RE .3} - A reasonable approach for the short term.  PRINT_DOC$, perhaps?

{RE .4} - Chaining to the PRINT and SUBMIT commands bought a lot.  It meant that
 all the features of your system's PRINT and SUBMIT commands are available even
  if they weren't available on the system DOCUMENT was developed on (we're still
   running VMS V4.2).  Our documentation simply says that the keywords are the
    same as the qualifiers to the PRINT and SUBMIT commands, which is preferable
     to having a list of printing/submitting keywords that aren't exactly like
      the ones available to PRINT and SUBMIT (which can be confusing).

It is possible to write code that figures out VMS version and only implements
 what's available on that version of VMS, using $SNDJBC, but I had something
  better in mind.

There are a lot of products with a PRINT feature, and they usually implement
 a subset of the PRINT qualifiers/keywords.  So here we have a lot of people
  reinventing the wheel:  parsing these keywords and calling $SNDJBC.  We seem
   to be screaming for an RTL-like interface to $SNDJBC, which parses the qual-
    ifiers/keywords that PRINT uses and calls $SNDJBC.

But there wasn't time to do that for field test, so instead of reinventing the
 wheel, I used SUBMIT.EXE's wheels.
  <_Jym_>
         

re: .3

How is that supposed to solve the problem?  Many times I have seen symbols
defined as:

$ PRI*NT :== PRINT/NOTIFY/etc

Having DOCUMENT chain to $ PRINT_COMMAND_WITH_FANCY_STUFF is still going
to get that symbol.

Personally I love the ability to get qualifiers added to the print and
submit features by simply defining a symbol.  Until user settable command
defaults come into being, symbol definition is the easiest thing to do.

-tl

>    How is that supposed to solve the problem?  Many times I have seen symbols
> defined as:
>
> $ PRI*NT :== PRINT/NOTIFY/etc
>
> Having DOCUMENT chain to $ PRINT_COMMAND_WITH_FANCY_STUFF is still going
> to get that symbol.

    This is *not* true. Your symbol definition replaces any of the strings
    PRI, PRIN, and PRINT with PTINT/NOTIFY/etc but *nothing else* as
    a symbol definition $ PRI*NT* is not (yet ?) available. So any verb
    with at least one character following the string PRINT will not
    be recognized as a valid symbol, but will be passed to the CLI which
    is the guy that does the truncation, i.e. that looks at the first
    four characters only and forgets about the rest.
    
    Anyway, it's a good idea to document the verb used (e.g. the one
    suggested in .5) so it still is user-redefinable (maybe with some
    hints in the documentation to avoid conflicting qualifiers).
    
    Hans
    
       

Oops, my error.  I stand corrected.  I forgot that DCL only uses the
asterisk as an indication of possible abbreviations.

-tl