Conference vaxuum::document_ft

< Note 445.0 by CRAYON::GENT "Party gone out of bounds -- B52's" >
  


> $ D /BATC=(NOPRINT,NOTIFY,LOG=[]BUG)/NOPRINT X SOFT.HAND LN03

	This in fact is NOT a bug -- when you supply parameters to the batch
command, these parameters are literally passed to the submit command.
Therefore, when you supplied a /LOG_FILE qualifier to the batch job document
merely passed this info along literally, when the job finally made it to
the batch que the file spec []BUG, was not specifying your original default
directory.  
	To get your log file in your default directory you should:

	A) specify DOCUMENT/BATCH=(KEEP) ...   the keep qualifier will keep
	the log file (Which DOCUMENT defaults to being <inputfilename>.LOG 
	in the default directory at the time of execution) as opposed to
	deleting it after the job is run.

		OR

	B) specify the complete path name to the LOG_FILE qualifier.


Chris

P.S.
	FYI - DOCUMENT is NOT a command procedure and therefore DOES NOT
use any DCL commands in it's innards.

P.S.S.
	In most cases error messages try to report the full path name of
the file in error.  If this is not done, there probably was an error in
parsing the supplied file spec to expand it to the full spec.  Or, there
may be a case that slipped through and doesn't expand the spec to full.
Which error message was it that wasn't giving you the full file spec?    

    Sorry, but yes it IS a bug! The /LOG=[] is unimportant. The error 
    occurs even without the /LOG_FILE argument:
    
    	$ DOC/BATCH=(NOPRINT,KEEP)
    
    I only used LOG so I could rename my log file. 
    
    In fact, SUBMIT is doing the right thing, because it knows how 
    to create the log file in the directory I specify. DOCUMENT on the 
    other hand is doing the WRONG thing because it cannot find the 
    source file, although it exists in the current (interactive) 
    default directory.

    --Andrew

    The error that is being generated is INVALID_INPUT:
    
$ D /BATCH=(NOPRINT,NOTIFY,KEEP)/NOPRINT X SOFT.HAND LN03
%DOC-I-IDENT, VAX DOCUMENT T1.0-008
%DOC-F-INVALID_INPUT, Can't use X as an input file.
-RMS-F-DEV, error in device name or inappropriate device type for operation

    Note that the file name is listed without device, directory, or 
    file type. (Sorry, the error message was accidently edited out of 
    the log file I included in the first note.)
    
    --Andrew

         I wasn't quite sure what you were talking about(garbage in/garbage out
         --- this works with people too!), but the error message which was
         edited out makes your origional note more understandable.  This does
         seem to be a bug I will look into it, I will try and have it fixed
         for V1.0. 

Chris

    Thanks Chris. I apologize for the confusion.
    
    --Andrew

	
         I looked more closely at the problem, it is a deficiency in the
         system services VMS provides for software development under VMS.
         The changes to reconstruct the user command line for batch jobs
         is too involved to put into V1.0.  This is actually a problem with
         VMS, and if there is to be a fix it will not surface until V1.1.
         
         In the meantime...
         	Put all logical names in your LOGIN.COM file.  Your LOGIN.COM
         file is run before your batch job and will define any logicals
         before document tries to parse them.  
                                             
         
         
         
         fyi -
         	The reason the error message didn't contain an expanded
         file spec was because the logical you defined in your parent process
         does not exist in the batch process.  Thus the parse failed and
         the file name remained unchanged.
         
         Chris

    I'm not sure I'd call it a deficiency or problem in VMS but there is
    definitely a way to work around the problem.  Unless I've gotten thrown
    off the track by missing information, the basic problem is that a user
    does the following: 
    
    $ DEFINE foo disk$user01:[little]bar.sdml
    $ DOCUMENT/BATCH foo REPORT LN03
    
    And gets an error indicating that DOCUMENT can't find file "foo" for
    input in the batch job.  This occurs because the logical "foo" isn't
    defined in the context of the batch job.  The user really shouldn't
    have to worry/care about that and DOCUMENT can fix the problem
    (although I'm not necessarily arguing that it should.) The "fix" is to
    translate the logical "foo" in the interactive invocation of DOCUMENT
    and pass the translated logical to the batch invocation.  This would
    need to be done for all arguments to the command that specify a
    file spec.
    
    I suspect that the DCL SUBMIT does not need to do this for /LOG and the
    command procedure file name, since the arguments are translated at
    interactive time to pass along in the send job controller system
    service. 

    -tl

RE:< Note 445.7 by BUNSUP::LITTLE "Todd Little NJCD SWS 323-4475" >
    
>    I suspect that the DCL SUBMIT does not need to do this for /LOG and the
>    command procedure file name, since the arguments are translated at
>    interactive time to pass along in the send job controller system
>    service. 


         Say, for example, you have a com file(called TEST.COM) which
         contains only $ SHOW LOGICAL FOO, and FOO is not defined in
         your LOGIN.COM file. 

         Then you type at your interactive process.
         
         $ DEFINE FOO BAR
         $ SUBMIT/KEEP TEST.COM
         
         The result of that batch job will be that FOO will not be
         found in the logical name tables.  This is because the batch
         process is not the process where the logical FOO was defined.
         This is the same problem as DOCUMENT's problem.  From
         VMS's point of view this is a user error; although you
         and I think that this is a forgivable mistake -- VMS doesn't
         forgive.
         
         What VMS should do for ALL batch jobs is to capture the entire
         parent process's environment (symbols and logicals) instead
         of sleezing around it by just running the user's LOGIN.COM
         file.  This is why I say that this is a VMS problem, its
         not a bug, but a design deficiency in the implementation
         of batch.
         
         Chris
         

    Chris,
    
    Thanks for the explanation. I agree with you that if a user writes 
    a .COM file and submits it to the queue manager as a batch job, 
    they are responsible for ensuring that the batch process will provide 
    the necessary "environment". 
    
    However, in this case, the user isn't submitting the batch job, 
    DOCUMENT is.  I think it is not unreasonable for the user to 
    assume DOCUMENT will set up the environment as necessary (at least 
    to the extent of parsing the command parameters and default directory).

    In my case, it is the current default device and directory that are
    not being translated. However, the only indication that this is the
    problem is if you read the .LOG file carefully you find that DOCUMENT 
    is doing a $ SET DEFAULT GENT$$DISK:[GENT.TRIAL] where GENT$$DISK is 
    undefined. Of course the error message doesn't occur until several 
    lines later and does not specify the device name that is at fault.

    What system services are you using to identify the current default
    device and directory? You might consider using the RMS SYS$PARSE 
    routine to get a fully expanded/translated file spec. (Why *isn't*
    there a LIB$PARSE that works like F$PARSE?)
    
    --Andrew

Re: < Note 445.9 by CRAYON::GENT "Party gone out of bounds -- B52's" >

                             
         I normally don't like to discuss the innards of the software
         with the users, but since your so interested...
         
         Yes, document does parse the input files using sys$parse()
         that is why you don't get the error when you initially
         run document from the command line because the logical
         names do parse the specs to full length.
         
         To get the command line for batch file Document uses
         cli$get_value (a system utility) with the keyword "$LINE"
         which gives Document the user's command line. This works just
         fine, except in this case. 
         
         To solve this problem, Document will have to rebuild a
         command line with full file specs for all parameters and
         qualifiers.  Ultimately all the file specs are parsed into
         full file specs, so the information is available to Document,
         but a command line (currently) is never rebuilt from this
         information under normal circumstances this would be a
         useless and wasteful task.  But, in this new light I will
         probably add this change. But, this is a non-trivial change
         and the time for non-trivial changes for Document V1.0 has
         passed, so y'all just have to wait for V1.1 on this one. 
         
          
         Chris
         
         fyi - f$parse only does a subset of what sys$parse does,
         which is not enough for the guts of an application(which is
         probably why there is no lib$parse()). That's why we use
         sys$parse; sys$parse() does not only result in the expansion
         of file names but also fills FAB's, RAB's, NAM's and other
         senseless, but useful data structures for dealing with the
         wierd world of VMS.