Conference vaxuum::document_ft

Well, I think I may have answered the questions for myself.  Please
verify and add any info you can for other hapless users.

For the first problem,  I think that DOCUMENT is trying make a page prefix
from "Glossary Of Atlas Terms" ?  If so, is this a bug?

For the second problem, I failed to mention that I processed atlas_PRO file
using /CONTENTS/INDEX.  I now find that if I just use either /CONTENTS or
/INDEX it processes ok; I just can't specify both.  I can't find any reference
to this bug in the release notes.

If you peruse those files I appended to .0, you'll see that although I called
out <includes_file>(zimbabwe_map...) and <includes_file>(khartoum_map...), 
I failed to actually <include> them into africa_atlas_ch.gnc as they should 
have been.  I thought this might be the problem with /INDEX, so I 
corrected it.  It had no effect; a .BRN file still was not created.




Rose

    
    Yes, the problem of trying to make a page prefix out of the
    glossary title is fixed.
    
    It doesn't matter whether you actually include a file you
    specify with <includes_file> or not.
    
    I don't see anything in your input that relates to /contents??
    
    

First, back to page prefix problem for a moment.  What was interesting 
to me was that the indexer blew up when I didn't even have index entries 
in that file:

Input
-----
<back_matter>
<glossary>(Glossary Of  Atlas Terms\gloss_atlas)
<gterm>(sample)
<gdef>(This is a sample file not used in atlas_pro.gnc)
<endglossary>
<endback_matter>

Command
-------

$ DOC GLOSSARY/INDEX GEN TERM

Error
-----

"IDX-W-TAGERR Error processing the PREFIX tag on line 1 of the INX file.
The argument list is too long, or is not terminated with )."


For my own information, what is the relationship between page prefixes 
and indexing in the above case, considering that I had no explicit index 
tags in the source file?  (I did get a second error that said no 
indexing info was found; but the above error was first.  Seems to me 
that should have been a "contents" error instead of an IDX error.)


Now, back to second problem.  I tried processing a profile with the 
following command:

$ DOC ATLAS_PRO/INDEX/CONTENTS GEN TERM

When it got to index generation, it failed to create a .BRN file.

%DOC-F-OPENIN, error opening ...ATLAS_PRO.BRN' for input
-XPO-E-NO_FILE, file does not exist

Processing with either /INDEX *or* /CONTENTS works; but you can't 
specify both on the same command line; at least not in this case, using 
the files I showed in .0.

The release notes, page C-3 at the top, indicate that you *can*
specify both.  This is the section on software bugs/restrictions.

It may be worth noting that I tested this specifying /INDEX by itself, 
then by specifying /CONTENTS/INDEX.  I kept all files generated in both
sessions.  During the second session, DOCUMENT apparently deleted the 
.BRN file created in the first session, and failed to create a new one in 
the second session.

Is this enough info, would some .LOG files help?



Rose

    
    The answer to the first question is easy. When you specify /INDEX,
    the INX file is created. It has all the index entries in linear
    order. Each entry is preceded by tags that indicate the chapter
    or prefix and the page number. These tags are written to the INX
    file regardless of whether there are entries for the page or not.
    
    The second, I am not sure of. This looks like a bug. What is your
    open file quota set to? (being able to process either contents or
    index but not both sounds like a quota problem...)
    
    patti
    

    Rose,
    
    This is quite similar to my indexing problem (note 64 or
    there-abouts). I have to run DOC$INDEXER file_INDEX design dest 
    in order to get the file.BRN created
    
    I tried upping the quota's to see what effect they had - and found
    no change. (So the quota's are now real high just to make sure...)
    
    The hassle I have is that I can't run DOC$INDEXER in batch. 

    Regards
    Kevin    
    
    

RE: .4 

My open file quota was set at 40; the sys mgr just upped it to 50.
No change in processing; it still doesn't work.

The only VMS error I'm getting is "-XPO-E-NO-FILE, file does not exist".

Attached is the .MAP file so you can see how many source files were 
included.  I don't know what the DOCUMENT multiplier is for specifying 
both index and contents.


What is DOC$INDEXER and where is it documented?

What other info can I give you, Patti, to help track this down?


Thanx

Rose


Map of files read during tag translation.
Produced by T1.0 on 21-APR-1987 at 12:43:35.74

System files:

DOC$BL07_ROOT:[TEX.FORMATS]TAG$GENERAL.STT;
  DOC$STANDARD_FORMATS:TAG$SDML_TAGS.STT
  DOC$STANDARD_FORMATS:TAG$FRONT_MATTER.STT
  DOC$STANDARD_FORMATS:TAG$BACK_MATTER.STT
  DOC$STANDARD_FORMATS:TAG$PART_PAGE_TAGS.STT
  DOC$STANDARD_FORMATS:TAG$G_OUTLINE_TAGS.STT

User files:

DISK$FIG_4:[JOHNSTON.CLASS.SLIDES]ATLAS_PRO.GNC;
  DISK$FIG_4:[JOHNSTON.CLASS.SLIDES]ATLAS_PRO_CONTENTS.DVI_DEV
  ATLAS_FRONTMATTER.GNC
  US_ATLAS_CH.GNC
  AUSSIE_ATLAS_CH.GNC
    [JOHNSTON.AUSSIE.CITIES]SYDNEY_SEC.GNC (SYDNEY_SEC)
  AFRICA_ATLAS_CH.GNC

Could the odd behavior that Jim Amend described in 64.11 be even 
remotely related to the problem I'm having specifying both 
/CONTENTS/INDEX?   

The file I was processing was in a directory that I navigated to via
"$ down class.slides" instead of "$ set def [johnston.class.slides]".

I just tried navigating then processing the file both ways, and am still 
unsuccessful; but I thought it was worth mentioning since Jim found this 
weird behavior in another indexing situation.



Rose

    
    we are still looking; Jim Amend just came up with a clue.
    
    DOC$INDEXER is described in the Release Notes...