Conference vaxuum::document_ft

    
    1. ok
    2. Mike Greene is out of town, and he left me proxy access to KIWI,
       so I'll put things there and test.
    3. This is in the standard template for installation kits; nothing
       special to us.
    4. See page 15, instructions for running the test file following
       partial installation. (just before Step 8.)
    
    Thanks for helping out! 
    
    patti
    
    

    RE: item 3, the point I was making was that the documentation shows
    occurring, but it didn't occur obn my VAXstation.  Possibly it needs
    further text explaining which systems it will occur on, or that
    it may optionally occur on some systems (some appropriate wording).
    
    jack

    In the instructions for running the IVP opn page 15, shouldn't the
    third running of DOCUMENT have a /NOTAG qualifier on it?
    
    jack

    I'm back and KIWI now has the distribution kit...
    
    Let me know if there are any problems...
    
    Michael

    Have just installed the DOCUMENT kit and wrote my first "document"
    (real first time user !!). At the beginning at processing, before the
    tag translation phase, I received the following error message :- 
    
    %DOC-W-OPEN_DESIGN, error opening DOC$LOCAL_FORMATS:DOC$DESIGNS.DAT
    			data file.
    -RMS-E-FNF,  file not found
                               
    After these error messages the job continued, and printed out my
    document.
    
    Is this a "valid" error message or have I forgotten something ??
    
    	Thanks
    		........... Monty
                                                       

    
    You didn't read all the way through the Installation Guide. There
    are instructions at the back giving information on setting things
    up for Digital-specific doctypes. Note that the message
    DOC-W-OPEN_DESIGN is just that. It indicates that there is a
    directory set up for local doctypes, but there isn't a required
    data file there.
    
    patti anklam
    

    The note on page 3 of the installation guide says that installation
    of VAX DOCUMENT on a MicroVAX with an RD52 is not supported. This
    is not clear. Lolita is a multi-user MicroVAX with 3 disks:
    
    DUA2: bl 6 Document  DUA2 is an RD52. The other two are RD53s. Isn't
    DUA1: User disk      60000 blocks (size of RD52) enough room for this 
    DUA0: MicroVMS       release? It should be according to the table
                         on page 4.
    
    Is this talking about systems with only one disk? Most Micros have
    more than one RD.
    
    Neil
    

    re 3.5
    
    Read page 4-1 of VAX DOCUMENT Version T1.0 Release Notes for Base
    Level 6 Users.  Just in case you don't have it do the following
    to "create" DOC$DESIGNS.DAT
    
    Rename (or copy) CUP$DESIGNS.DAT to DOC$DESIGNS.DAT 

    Page 5 of the install guide says the option to display or print
    the release notes is only valid for VMS 4.4. or greater. And that
    if you don't include the OPTIONS N parameter, VMSINSTAL does not
    prompt you to display or print the release notes.
    
    That doesn't seem to be true though. We're running 4.2 and I just
    printed out and saw the release notes go by, as shown on page 8.
    
    Neil

    Our installation went nice and smoothly (thank you for a clean
    installation process) but we have a question about setting up the
    LN03 (we've borrowed one for a short while to test DOC's LN03 specific
    features). What is the /PRIME switch mentioned in setting up the
    que - our VMS guru doesn't recognise it - and all we can get out
    of the printer is erratic (and I *mean* erratic) text.
    
    Grateful for any clues....
    
    Gavin

{RE .9} - Since versions of VMSINSTAL before VMS V4.4 don't implement the
 OPTIONS N parameter, I put in code to mimic that behavior on those versions
  of VMS.  I think this was mentioned in the installation guide, but I suggested
   that it be presented a different, clearer way.  My suggestions weren't in
    time for this release of the installation guide, though . . .
     <_Jym_>

    
    re: .10
    
    The qualifer /PERM was magically transformed to /PRIME somewhere
    between the -06 version of the installation guide and the T1.0 version.
    But I don't think that that has any effect on the text. Can you
    be more specific as to what you mean by 'erratic'? Do you have the
    LN03X-CR RAM cartridges?
    
    patti
    

    Reply to my own reply .7 - 
    
    There's plenty of room on a separate RD52, in a MicroVAX with more
    than one disk. The note on page 3 should be re-worded to reflect that. 
    
    If it's not obvious to everyone that the note refers to systems with 
    only one disk.
    
    We've done the installation with plenty of room to spare.
    
    Neil
    

The IVP failed when I did the full installation with LINE and LSE only. The
error was in TEX processing; it told me to see the .LIS file. I could not
find the .LIS file in DOC$ROOT:[TEMPLATES]. Only the .GNC file was there.

I then ran the IVP standalone, as described on p16 of the installation 
guide. Everything ran fine.

Marty

    Sorry, Marty.
    
    THe DOCUMENT commands in the IVP must be done in the working directory
    of VMSINSTAL, so the output of DOCUMENT ends up there.  All the
    output files get COPYed to DOC$ROOT:[TEMPLATES], but (alas) only
    if the DOCUMENT commands succeed.
    
    I'll fix it, so that the COPY is done for success or failure.
    

Suggestion for LSE support: The release notes should direct you to install 
the latest version of LSE from TLE::SYS$KITS: before installing DOCUMENT.

-Marty

    The installation procedure appears to use NMAIL to send a message
    to the development group about who is doing the installation. The
    installation procedure should warn the installer that NMAIL must
    be installed on the system in order for the installation to succeed.
    At least this should be mentioned in the release notes.
    
    Off to find the NMAIL kit...
    
    
    Marty

    Jeepers!  The installation kit checks that NMAIL is there before
    it uses it, and uses regular MAIL if it can't find NMAIL.
    It looks for NM_MAILSHR.EXE in [SYSLIB].  I thought that was
    all it needed to do.  Maybe there is some way for it to be
    there, but not operational?
    
    bill
    

Check f$file_attributes("SYS$SHARE:NM_MAILSHR.EXE","known") to make sure it's
 installed.  It won't work if it's not installed.
  <_Jym_>

    Looks like they sent a youth to do an adult's work.
    
               the youth

Just to close the loop...

Yes, on the system in question the NMAIL files were on disk, but the
shared image was not installed.

-Marty

    Wonder what the odds are for that?

    Any mail response at all in a kit is for internal use on the ENET
    anyway, so it makes no difference what technique is used.
    
    jack

    Yes, the KITINSTAL.COM for internal use (over the net) is not the
    same as the KITINSTAL.COM that goes out with the product.

> re: 3.25

> Whew, that's a relief, now I need not take Rolaids!
    
    Dreamer.

    I had to install DOC T1.0 three times--1 full install for LINE output,
    and 1 each for the LN01 and LN03.  I hope this is fixed (a dumb
    question, I know--but I just gotta kvetch to someone..).
    
    /MeV/

    
    Yes, this was a big problem. We documented it everywhere we could
    think of, but the message was still not clear. Really sorry about
    this; we felt it was more important to get the software out for
    testing and use than to spend another week or so fixing the problems
    with VMSINSTAL...
    
    pa

    The IVP should define DOC$ROOT (by running the DOC$STARTUP.COM).
    When you install T1 but keep BL6, the IVP always fails because
    DOC$ROOT is defined for BL6.
    
    Marty

    Hmmmmmmmmmmmmm.
    
    The installation procedure DOES run DOC$STARTUP.COM before it
    executes the IVP.  The problem, I suspect is that if you have
    BL6 installed the DOC$ROOT for BL6 is in some logical name table
    that is encountered BEFORE the logical name table that holds
    the most recently installed  DOC$ROOT definition.  So, running
    the DOC$STARTUP.COM file doesn't do any good...  It redefines
    the logical that is "behind" your Bl6 logical.
    
    Maybe I can fix that.  Since today is code freeze and it is
    already past 5 PM, I ain't promisin' though.
                                             

Bill, as usual you are right on track. The problem turns out to be that our 
system manager had defined BL6 DOC$ROOT *without* the /EXEC qualifier, while
for BL7 it is defined *with* this qualifier. 

So one definition was in supervisor mode, and the other was in executive
mode. I guess this isn't different tables, but the effect is the same.

Marty

    We tried a full installation with LSE and line printer support.
     It failed during the IVP with an "invalid queue name" message.
    
    Apparently, we made an error when it asked for the default
    queue name.  I checked the DOC$DESTINATIONS.DAT file, and
    there is NO queue name there at all.  It reads:
    
    .../print=(queue:
    
    
                     (5 blank lines here)
    
    
                            ,nofeed) /special_characters=LPCHARS
    
    
    Should I redo the installation?  Can I do a partial installation
    to respecify the line printer queue correctly?  Or, is there
    any way I can just edit DOC$DESTINATIONS.DAT to correct the
    problem?

{RE .33} - I'd suggest re-installing.  If DOC$DESTINATIONS.DAT is *that*
 messed up, who knows what else could be wrong?
  <_Jym_>

    Given the pain of doing the full installation, I'd try to
    edit the file.  Read the notes at the front of the file,
    and just eliminate that space, adding the queue name that
    you want.   Try it.  If it works, you're home free.
    If it doesn't you can reinstall.
    
    bill
    

    We did try editing DOC$DESTINATIONS and it worked.
    We installed POSTSCRIPT support afterwards and that's working
    too, so I guess we're OK.
    
    Thanks for the advice.

    Hello,
    Please bear with me if this has been reported before; the NOTES
    response times are so appaling out here that scanning a notes file
    as lively as this is out of the question.
    
    The problem I stumbled into when I tried to run $ DOCUMENT was a
    shareable image ident mismatch to VAXCRTL. After ANALYZE/IMAGEing
    I found that the VAXCRTL from the V4.6 FT that I had lying around
    would fit ( I run V4.4), so I set a logical name to that and everything
    went fine.
    
    Known problem?
    
    Per
    
    ps. By the way: great stuff, all of it!
    

The following question was asked of me by a system manager:             
    
------------------------------------------------------------------------
    
Do you know what the peak block utilization is for DOCUMENT before
and after installation, and how many global pages and sections are
required to install it?  I couldn't find the information in the
installation guide.

------------------------------------------------------------------------

    I'm not sure about the block size, but DOCUMENT (the original field
    test) should require almost no extra global pages or global sections
    because no images are installed as known images. (The only global
    pages needed are those used for system logical names, which are
    minimal.)
    
    It would be interesting to know if the development team plans to
    require/suggest that any of the images be installed as known/shared
    images as part of the final SDC kit. Eh?
    
    --Andrew

    
    re: .37
    
    Yes, this is a known problem. Your solution is precisely how we
    have handled it locally.
    
    re: .38 and .39
    
    None of the images should be installed shareable. 

RE: .39

We are going to look into whether or not our images should be installed.

--Brian

    Hi;
    
    We just finished installing DOCUMENT for the first time.  It went
    pretty smoothly.  Two things did occur:
    
    1. The IVP failed with ...-SYSTEM-F-VASFULL, virtual address space
    is full...  I increased the virtual page count and rebooted.  Things
    were fine then.  I didn't see this parameter mentioned in the
    installation guide.
    
    2. Page 17 of the installation guide instructs me to define DOC$ROOT
    as ddcu:[DOCTOOLS.].  It should read ddcu:[DOC$TOOLS.].  Did I get
    the wrong version of the installation guide?
    
    All in all a nice installation and a nice product.
    

    There are lots of baselevels of DOCUMENT and copies of installation
    guides around.  So we'd need to know which of each you have in order
    to tell whether they are mismatched.  :-)
    
    I'd like to know EXACTLY which sysgen parameter or process quota
    that you increased.  THere is an absolutely bewildering array
    of parameters and quotas relating to this stuff, and trying to
    understand how to give somebody advice in the installation guide
    is not easy.  SO if you ran into a problem and got around it, I
    would like to know what you changed and what the old and new values
    were and what kind of cpu you have with how much memory, how big
    is the page file, waht version of VMS are you running, etc.
    Were other users on the machine at the time of the IVP, etc.
    
    Thanks in advance!    bill
    

    Re: 3.16 (LSE), 3.17 (NMAIL), and 3.28 (printers)
    
    We're going to be installing NMAIL, LSE, and DOCUMENT for a LAVC.
    From reading these notes, I guess that the order in which they are
    installed is important. Please tell me if I'm incorrect, but from
    my understanding, they must be installed in the following order:
    
    NMAIL
    LSE
    DOCUMENT
    
    In addition, DOCUMENT will have to be installed three times if we
    want to use our LN01, LN03, and LINE printers. 
    
    Is all this true??
    
    
     

RE: .44

For the V1.0 kit (coming today or tomorrow), the only order of installation
that's important is that LSE V2.x should be installed before the DOCUMENT kits.
You no longer have to have NMAIL installed, and you no longer have to
install DOCUMENT multiple times for multiple destinations.

--Brian

    Does this mean you won't be sending mail around the net about who
    has what pieces?  
    
    D

We'll still be sending ourselves mail; if you don't have nmail installed we'll
send regular mail. It's important to us to know who's using the software.

--Brian

    In the installation notes it says "Do not run the IVP until after
    you have installed the DEC Internal kit". OK, so I installed DOC010
    and DOCLN03010 without IVP. Now I install DOCINT010 with IVP. I
    get the question:
    
    	Enter IVP argument destination?
    
    What should I enter? 
    
    Thanks,
    
    chris
    
    PS: excuse my ignorance, this is my first ever installation.

    During the installation of DOC010 you must have requested
    LN03 support (since you also installed DOCLN03010), so you
    could at least enter the destination that you supplied for
    the LN03 (the default was LN03_LASER_PRINTER).  If you 
    requested POSTSCRIPT or LINE PRINTER support you could
    enter either of those destinations.  After you say which
    destination, you will be asked whether you want DOCUMENT
    to automatically queue the output to the queue that 
    corresponds to that destination.  You can say "NO", in
    which case you just get the output file in DOC$STANDARD_FORMATS:.
    You can queue it yourself at a later time.
    
    bill
    

    I just installed DOCUMENT on the boot node for a LAVC. The
    installation seems to have gone well. I requested support for
    everything - LN03, POSTCRIPT, LINE PRINTER, and (since the
    installation procedure asked) LN01s. (I realize now that we
    probably don't need the LN01 support, but I'd prefer not to
    do the entire installation over again.) For the installation,
    I used the internal kits from CLOSET::KITS_:[DOCUMENT.V10].
    
    Well, everything seemed fine until I tried to process a test
    file. I entered the following command line:
    
    $ DOC  TEST.SDML  S.S  LN03
    
    In response, I received the following errors:
    
    % CLI-W-BUFOVF, command buffer overflow - shorten expression or
   		     command line
    
    % CLI-E-INVROUT, invalid routine specified in command tables - 
    		      check .CLD file
    
    I printed the .LN03 file produced by DOCUMENT and it looks fine. 
    However, these errors seem to indicate that something went wrong
    during the installation. What do you think?

    see 795.*     bill
    

         
         Ok, one more time.  The CLI$ error "command buffer overflow"
         appears when one of the destinations in the destination
         data file (DOC$STANDARD_FORMATS:DOC$DESTINATIONS.DAT)
         is longer than 256 characters.  
         
         This error seems to be occuring mostly when LN01 support is
         requested.  That is, the LN01_LASER_PRINTER destination
         command in the destination data file is often longer than 256
         characters. 
         
         Now, what needs to be done is the DESTINATION command needs
         to be shortened to less than 256 characters.  This can be
         accomplished by either shortening the DESTINATION command
         qualifiers to just abbriviations (just as you would on a VMS
         command line) which are still unique.  Or as many people have
         been doing, by changing the destiantion name from
         LN01_LASER_PRINTER to LN01 and this may then squeek under the
         limit. 
         
         When you look at a DESTINATION command in the destination
         data file, it does not include the PARAMETER commands
         which follow it, so don't include the PARAMETER command
         lengths in the 256 character limit.
         
         Be VERY careful when you edit the data file, do not add
         any extraneous characters, especially any characters (including
         spaces) at after continuation characters ("-").
         
         Chris
         
         P.S.   For further information concerning this problem see note
         467.*.
               
         P.S.S.  The message always appears since the entire destination
         file is parsed during each Document run.  The corrupted
         destination will not work, all others will.