Conference vaxuum::document_ft

    
    whoops. I had a whole big NOTE there in .1 (or thought I did). I
    will try again:
    
    
A new version of the converter is available on:

  VAXUUM::KITS_:[DOCUMENT]DOC$CONVERT_06_FILES.EXE

It implements the following:

1.	Converts the warning tags as follows:

          <USER_WARN> ---->    <USER_W_MESSAGE>
	  <WARN>      ---->    <USER_W_MESSAGE>
	  <WARNING>   ---->    <USER_W_MESSAGE>


 2.	Deletes utility template tags:

		<SUBCOMMAND_EXAMPLES>
		<ENDSUBCOMMAND_EXAMPLES>

		<QUALIFIER_EXAMPLES>
		<ENDQUALIFIER_EXAMPLES>

		<UTILITY_EXAMPLES>
		<ENDUTILITY_EXAMPLES>


3.	Implements the conversion of <DEF_ITEMS>

4.	Converts   <smalltext>  to <text_size>(small)
		   <endmsalltext> to <endtext_Size>			

5.	Converts multiple references by leaving the citation
	  word (e.g. figures, examples, etc) and converting
          all references to \VALUE form.

6.	Initializes the prefix to blank for the case 
          in which a profile does not contain an <LPN> tag.


7.  Fixes conversion of FEATURES tag.

    <FEATURES> --->  <PREFACE_SECTION>(New and Changed Features)

8.	Removes units for ICON_FILE and FIGURE_FILE and converts value
     	   to picas if necessary.

9.	Handles the closing paren correctly for deflist
           to table conversion for valid breaks and nested
           figures.

10.	Corrects problem that figure captions with imbedded
	   parens are truncated.

    I converted a definitions file that contained the tags <CHECK_FOR_INCLUSION>
    and <__END_OF_FILE>.  I expected that the <__END_OF_FILE> tag would be
    converted to <ENDCHECK_FOR_INCLUSION>, but it wasn't...

    Incidentally, keywords aren't being used much, it seems.  I KNOW there is
    more than one note in this file that deals with conversion, but you
    wouldn't know it by typing DIR/KEY=CONVERSION!  Let's take advantage of
    the keywords, shall we? 
								-- Nina

    Here are a few more bugs:
    
    - Nested parens get truncated in <EXAMPLECAP> tags.
    
    - When deflists are converted to tables, I get a
    <TABLE_ATTRIBUTES>(\nofloat) tag rather than a <TABLE_ATTRIBUTES>(keep)
    tag.
    
    - Another deflist problem:  <DEFLIST>(18\multipage) gets converted
    to a <TABLE_ATTRIBUTES>(\nofloat\multipage) tag.
    
    - Same goes for figures:  <FIGURE>(<symbol>\####\nofloat) gets
    converted to <FIGURE_ATTRIBUTES>(\nofloat)
    
    
    Please excuse if these bugs are already fixed.  I'm not sure whether
    we're running the most recent version of the converter.
    
    
    	-hkc
    
    

    
    re: .4 
    
    <__end_of_file> is merely a label, and as such may be used for things
    other than the target of <check_for_inclusion>. <check_for_inclusion>
    is implemented such that <__end_of_file> is a valid target, as well
    as <endcheck_for_inclusion>.
    
    patti
    

    Three additional cheers for the converter program.  I think it is
    great!  But, (you knew this was coming, right?) here are two bugs I
    cleaned up after that haven't been mentioned:
    
    1)  <nlist>(6) got converted to <list>(numbered)(6) Should
        have converted to <list>(numbered\6)   
    
    2)  <y>(blah>sub-blah) did NOT convert.  Should have 
        converted to <y>(blah<xs>sub-blah)               
    

Here's another bug I ran into......
    
    
This SDML code:
    
	<table>(<common_ufs_rt_proc_func>)
	<tablecap>(Common <UFS_ABBREV> Run-Time Processing Functions)
	<tablespace>(18\OLD TABLE NUMBER:  13-1)
	<endtable>

Got converted to this:
    
	<TABLE>(Common <REFERENCE>(UFS_ABBREV) Run-Time Processing
	Functions\common_ufs_rt_proc_func)
	<TABLE_SPACE>(18\OLD TABLE NUMBER:  13-1)

    
    Notice the lack of an <ENDTABLE> tag.  All my other tables converted
    properly.   I don't know what's special about this one.  Perhaps
    this bug is fixed in the new version of the converter....
    
    
	-hkc

    The absence of an <endtable> tag probably means that this was
    in a context where the converter got confused.
    
    Could you send me a bigger piece of the file?  I'll take a
    look at it and see if I can figure out where the <endtable>
    tag went.
    

>                                                            Perhaps
>   this bug is fixed in the new version of the converter....
    
    Might it be possible for the converter to identify itself with a
    version number? This could be printed in the comment inside the file: 
    
<COMMENT>(****Version 1****)    
<COMMENT>(DOC$CONVERT V1.0-17)

    re: 4.5
    
    You can tell which version of the converter you are running by
    looking at the .GNC_6LIS file.  The first line tells you the
    version number.  The current version number is 1.4
    

    Another cleanup item for converted files is hyphens. 
    The converter changes hyphens to en dashes.  For example, 
    the word on-line got converted to on--line.

    RE .9
    
    I'll send the file to you via mail.
    
    RE  Another bug
        
    We've installed the latest version of the converter now, so I don't
    think the following bug has been fixed yet (I'm converting a *lot* of
    files, in case you hadn't noticed  :-)).
    
    It's another case of truncating nested parentheses, I believe. This
    code: 

<defitem>(<keyword>(switch) statement
<stack><emphasis>(fprintf\bold) function)<defdef>Boldface type identifies
language keywords and the names of <OS> and <C> Run-Time Library
functions. 
    
    was converted to this:
        
<TABLE_ROW>(<keyword>(switch) statement
<LINE><emphasis>(fprintf\Boldface type identifies
language keywords and the names of <REFERENCE>(OS) and <REFERENCE>(C)
Run-Time Library functions.

)
     
    It doesn't compile because it's missing a parenthesis.....
    
    
    	-hkc    
    

    I don't know if this is a bug or a feature, but if you
    have index tags or comments in between <TABLE> and
    <TABLECAP> or <FIGURE> and <FIGURECAP>, the converter
    throws away the symbolic name and doesn't translate
    the caption. Thus
    
    	<TABLE>(<my_table>\\multipage)
    	<x>(An index hit)
    	<TABLECAP>(My table caption.)
    
    converts to
    
    	<TABLE>
    	<x>(An index hit)
    	<TABLECAP>(My table caption.)
    
    My apologies if this was bad BL06 coding style, but
    it didn't hurt anything at the time (and seemed sort
    of a logical way to get general table index hits to
    come out right).
    
    Could the converter be made to look for the <TABLECAP>
    tag instead of just expecting it to show up on the
    next line (don't know if this would cause grief in
    other situations)?
    
    Barbara

    I, too, ran into the Mystery of the Missing <ENDTABLE> Tags (reported
    in .8) when I converted a docplan.  I had an unnumbered list that
    had seven list elements, and each list element contained a <TWOCOLLIST>.
    All got converted to tables okay, but the last four or five tables did
    not get <ENDTABLE> tags.

    This didn't cause me great hardship, since the tag translator caught
    the missing <ENDTABLE> tags, and I just chalked it up to conversion
    weirdness.  However, I'll be happy to send you the BL06 version of
    the file if you're interested in tracking this problem down.

							-- Nina

    If the tables that were lacking the <ENDTABLE> were ones
    that did not enclose a COLLIST but rather enclosed a
    <TABLESPACE> tag, then that is a known bug which will be fixed
    soon.
    
    If that was not the case, please send me your files and I will
    check it out.  Thanks/Helen
    

    We've had the problem a lot, but all of our occurrences appear to
    be of the <TABLESPACE> variety.
    
    	-Helen

    re: 4.12
    
    It tried a test with on-line in it and the converter did not 
      convert to en-dash.  I don't think the converter is doing this.
      If you still feel it is a problem, please send me the sample
      file and I will check it out.
    
    re: 4.14
    
    I wish the converter were smarter about looking for tablecap but
      I don't want to rock the boat now.  It issues a message
      when it finds a <tablecap> that doesn't directly follow the
      <table> tag.  You will find that Version 1 of DOCUMENT is
      pretty strict about the order of the <TABLE>,<TABLE_SETUP>,
      <TABLE_ATTRIBUTES> tag.  I don't think it will allow an
      index hit following the <TABLE> tag.
    

A new version of the converter is available in

      {CLOSET|VAXUUM}KITS_:[DOCUMENT]DOC$CONVERT_06_FILES.EXE

It implements the following:

1.	A more robust "command line"

		o  Qualifiers can be given before or after
		   the fielname.

		o  Incorrect qualifiers are detected.

		o  Symbols file can be given without an extension.
		   The .GNC extension is assumed.


2.	A new qualifier, which lets you choose upper
	or lower case for tags.
	
	To get lower case tags, use the /LC qualifier.  For example

		$ DOC$CONVERT file-name/LC/SY=symbol_file_name

	To get upper case tags, omit the /LC qualifier

		n.b.  The /LC qualifier converts ALL tags to lower case.
		      If you don't specify that qualifier, the
		      converter uses upper case for tags it inserts
		      and leaves other tags in their original case.

3.	fixes a bug which occurred when more than 50 book
	references were used.  The limit was supposed to apply to
	the number of unique books not references to books.

4.	converts <ENDSUBTEXT> to <ENDSAMPLE_TEXT>

5.	fixes a case where the table caption (or any tag
	argument) is being improperly truncated.  This occurs
	only if there is a backslash within parens followed by
	a second pair of parens containing a backslash.

6.	fixes the missing <ENDTABLE> problem.  The converter
	was getting its signals crossed when there was a <TABLE>
	that did not have a <COLLIST> within.  In that case, it
	sometimes failed to provide the <ENDTABLE> tag.

7.	fixes the problem with <NLIST>(6).

1. Where is the documentation for the converter program?

2. Will the latest version of the converter be "automatically" installed on ALL
   FT nodes?

3. Will there be a retirement party for the converter after the last BL 6 .GNC
   is converted?

    Re: .20: question no. 1:
    
    I am putting together a document for my writer's group on using
    DOC$CONVERT. It is not finished, but you can have a rough draft,
    or (later) a more polished copy.  Reply by VAX mail.

    
    I will update the systems used by CUP writers in ZK (I-cluster,
    P-cluster, CLT, CLOSET.)
    

    I don't mean to be overly negative, but we've been trying out the
    new version of the converter this morning and have discovered (correct
    me if I'm wrong) that the new command isn't any less
    position-sensitive, the positioning that doesn't work now is just 
    different.
    
    For example, try this:
    
    	$ DOC$CONVERT myfile.gnc /SYMBOLS=mysymbols.gnc
    
    or this:
    
    	$ DOC$CONVERT myfile /SYMBOLS=mysymbols.gnc
    
    or any other variation on that theme.  Now, it appears that the
    /SYMBOLS=  qualifer must be at the *beginning* of the line, rather
    than the *end*.

    The error message that we get now is no more helpful than the old
    "logical name undefined" message.  The new error message is:
    
    	"ignored -- doesn't have GNC extension
    	  ...file not found"
    
    
    	-hkc
    

    Addendum --
    
    This does appear to work:
    
    	$ DOC$CONVERT myfile.gnc/SYMBOLS=mysymbols.gnc
    
    The difference is the space between the file name and the /SYMBOLS=
    qualifier. I guess this "gotcha" isn't that serious, but it did trip us
    up for a short time. 
    

    I think we've run into another converter bug.  This text:
    

<twocollist>(12)
<subhead1>(Developing <C> Programs)
<twocols>(Chapter 1\Provides an overview of the <C> programming language)
<twocols>(Chapter 2\Describes how to develop <C> programs)
<twocols>(Chapter 3\Explains how to edit, compile and run a <C> program)
<twocols>(Chapter 4\Explains how to use the <OS> Debugger)
    
    got converted to this:
    
<subhead1>(Developing <REFERENCE>(C) Programs)
<TABLE_ROW>(Chapter 1\Provides an overview of the <REFERENCE>(C) programming language)
<TABLE_ROW>(Chapter 2\Describes how to develop <REFERENCE>(C) programs)
<TABLE_ROW>(Chapter 3\Explains how to edit, compile and run a <REFERENCE>(C) program)
<TABLE_ROW>(Chapter 4\Explains how to use the <REFERENCE>(OS) Debugger)
    
    Notice the absence of a <TABLE> tag.
    
    	-hkc

    Two writers here have run approximately 3-5 files through the new
    version of the converter.  Two of those files have bombed with long
    trails of tag errors.  Moreover, the tags cited in the error messages
    are numerous and are different in his files and mine.  
    
    I'm sorry to say, we were quite discouraged when we saw these
    scary-looking error messages.  Since we've just spent two weeks
    working through the bugs in the previous version of the converter,
    we're going to put it back up.  We know there are bugs, but at least
    they're familiar bugs.  We never got such long lists of internal
    tag errors with the previous version.  And the files we've run through
    the new version are the same files that we converted with the previous
    version.  
    
    We can supply files that blow up the converter if you wish.  
    
    	-hkc

    <FIGURE> tags are disappearing from figures in the new version of
    the converter.

    re: .26
    
    	Do the files blow up the converter or DOCUMENT after conversion?
    
    	Please send me the files by mail and I'll look at them.
    

    The problem is with the UPPER CASE TAGS.  If you specify /LC,
    then the resulting files will probably be OK.
    
    I have located the bug and fixed it.  It accounts for the missing
    <FIGURE> tag when you are using upper case tags and probably for
    a lot of other hideous errors.  
    
    I guess I did rock the boat after all.  Sorry.
    

    ps:  4.29
    
    But I am still testing, so the corrected version is not ready yet.
    

    re: .28
    
    Sorry.  No, the converter has never blown up on us.  I meant to say that
    DOCUMENT blows up on the newly converted files and since it didn't
    when we converted these files with the previous version of the
    converter, I'm assuming it's a conversion problem of some kind.
    
    I'll send the converted version of the file.  Let me know if you
    want the pre-converted version also.  I'll check with the other
    writer for his "corrupted" file.

The current version of DOC$CONVERT seems unable to process
symbols ending in "_YR".  When I tried converting a short BL06
test file containing the symbols <FT_YR> and <RELEASE_YR>,
DOC$CONVERT did not convert them.  It did, however, convert such
symbols as <FT_MO> and <RELEASE_MO>. (By the way, the test
file runs fine under BL06.) 

When converting the file that contains the definitions of
all the above symbols, the converter deleted the two symbols
ending "_YR".  It had no problems with any other symbols.  What
gives?

The converter only changes symbols for which it finds a definition.

For example, the following source file:

	<DEFINE>(ft_yr\yearly update)

	See <ft_yr> for information.

	See <ab_yr> for more information.

is converted to:

	<COMMENT>(****Version 1****)
	<DEFINE_SYMBOL>(ft_yr\yearly update)

	See <REFERENCE>(ft_yr) for information.

	See <ab_yr> for more information.

A new version of the converter (V1.6) is available in
    
    CLOSET::KITS_:[DOCUMENT]DOC$CONVERT_06_FILES.EXE
  
This version corrects the problem in V1.5 which caused the converter
to swallow tags when upper case tags were requested (by default).  The
absence of these tags caused DOCUMENT to detect many errors and produce
many error messages.

    re: .32 and .33
    
    Marcus and I pursued this problem offline and got the following
    result.
    
    The symbols ending in _YR were not getting defined because
    their definitions were not "present".
    
    The definitions of these symbols were not present because they
    were numeric:
    
    		DEFINE(<ft_yr>\1982)
    
    and the converter deletes numeric definitions.  This action
    is correct probably about 95% of the time.  It removes the
    numeric chapter, section, table, etc  definitions which you
    don't want to have in your Version 1 files.
    
    However, you may lose some symbols you want.  If you know about
    such symbols, you can change their definitions to <DEFINE_SYMBOL>
    before conversion and then everything should work out ok.  The
    flip side of this anomaly is that the converter leaves the
    defintions for appendix  numbers in because they are not
    numeric (i.e. A.1.1).
    

    I don't know if anyone else has encountered this, but I think it might be
    a converter bug.  The following text appears in my profile:
    
#####################################
<ELEMENT>(pref)

	<TITLE>(Preface)

	<TEXT_TYPE>(Manual)

<ENDELEMENT>(PREF)

<ELEMENT>(PART1)

        <TITLE>(Text Editing with <EVE_ABBREV>)

<ENDELEMENT(PART1)
#######################################

    
    
    It got converted to this:
    
    
#######################################    
<ELEMENT>(2831PREF.gnc)

	<TITLE>(Preface)

	<TEXT_TYPE>(Manual)


<ELEMENT>(2831PART1.gnc)

        <TITLE>(Text Editing with <EVE_ABBREV>)

<ENDELEMENT(PART1)

########################################

    
    The <ENDELEMENT> tags were not deleted from the profile after the first
    element was processed.  I can't tell if it's due to the use of the
    <TEXT_TYPE> tag or the <EVE_ABBREV> symbol, or if it's something else
    altogether.  The other profile I converted had all its <ENDELEMENT>
    tags deleted automatically.
    
    
    	-hkc

    
    p.s. I was using version 1.4 of the converter.  Presumably, the
    same thing happens using later versions.

Can't answer your question, but it's worth noting here that DOC$CONVERT version
6 is now available.


Rose

    As mentioned in Note 4.26, we opted to switch back to 1.4 because 1.5
    had some serious problems.  We would move to 1.6 if we had time to test
    another version. 
    

RE: .36

Is that the entire text of the profile? I ask because the second
<ENDELEMENT> tag in your profile is missing a closing angle bracket,
which is probably why it wasn't deleted. Are there other <ENDELEMENT> tags
in the file which aren't being deleted?


--Brian

RE: .-1

    You have an excellent eye!  That is not the entire profile, but I did
    extract it directly from the editor, so the source profile apparently
    was missing a closing angle bracket.  (That says something for
    extracting sample text that produces an error, rather than trying to
    retype it....) 
    
    To answer your question, there were approximately 20 more <ENDELEMENT>
    tags in that file and none of them were deleted after that first error.
    And no error was reported during the conversion. So maybe there is a
    bug, even though my file was "buggie" too. 
    
    Thanks, Brian.
    
    	-hkc

    I got some problems while attempting to convert from BL6 to FT:
    
    1 - the DOC$CONVERT symbol isn't defined on my system. I've probably
    missed something at installation time, am I right in assuming that
    I just have to add the following line in SYLOGIN.COM ?:
    
    $ DOC$CONVERT :== RUN DOC$LOCAL_TOOLS:DOC$CONVERT_06_FILES
    
    2 - Assuming the above definition is correct (?) the conversion didn't
    run without problems: I needed some time to understand that the .LDF
    shouldn't be there. The next problem I got was the message:
    
    "Right paren not found"
    
    within <define> tags. I fixed it by manually substituting
    <define_symbol> to <define> in the files.
    
    3 - The conversion then ran ok, but the compilation 
    
    $ DOC/BATCH=(...) S.R ISA1PRO LN03 
    
    is having some problems (see the log in next reply).
    
    
    
    Just so that you know, I'm doing the following: since BL6 doesn't
    support automatic numbering, I defined all the chapter numbers as
    global tags (<xxxx_CHAP>) in GLOBALDEFS.GNC. In each chapter, I then: 
    
    o include GOLBALDEFS.GNC,
    o use the <CHAPTER>(<xxxx_CHAP>\Chapter Title) tag to define a chapter.
    
    The version of DOC$CONVERT_mumble.EXE I'm using is the most recent one
    (I hope !): 27-Mar-1987 13:05.
    
    Thanks for any infos, Marc.

    Below is the (expurged) log file resulting from the building of
    a converted book. I expurged from it some error messages:
    
    - .LDF and .GDF files not found
    - <define_symbol> invalid in GLOBALDEFS.GNC: these are the one defining
    the chapter and appendix numbers. To get rid of them, I can merely
    remove the define_symbol tags (and their arguments) from the files.
    I'd like to get infos on the others (and ways around ?).
    
    I left some 
    
       Tag can appear only within the context established by
        an element heading tag such as <CHAPTER>, <APPENDIX>, etc

    messages, because they are related to symbol definitions in
    GLOBALDEFS.GNC, but not CHAPTER or APPENDICES symbols, so they
    shouldn't be here, to my understanding.
    
    
    Thanks for any help.
    
$ verify_context = 1 ! SYS$SCRATCH:DOC$8FF5324A705655E0.TMP - Start
$ d = "document"
$ set = "set"
$ set noon
$ set default login$disk:[buresi.doc]
$ D /BATCH=(LOG:[]BOOK.LOG,NAME=BOOK,KEEP,NOPRINT,NOTIFY) ISA1PRO S.R LN03
%DOC-I-IDENT, VAX DOCUMENT T1.0-001
%DOC-W-OPEN_DESIGN, Error opening DOC$LOCAL_FORMATS:DOC$DESIGNS.DAT data file.
-RMS-E-FNF, file not found, where did you leave it?
[ T a g   T r a n s l a t i o n ]...
%TAG-I-TAG_IDENT, T1.0
%TAG-I-DEFSLOADD, End of Loading of Tag Definitions
%TAG-W-TAGNOTDEF, at text on line 4 in file
   DISK$USER:[BURESI.DOC]ISA1PRO.GNC;
   Tag <DOCUMENT_TITLE> is undefined
%TAG-W-TAGNOTDEF, at text on line 5 in file
   DISK$USER:[BURESI.DOC]ISA1PRO.GNC;
   Tag <WRITER> is undefined
    
%TAG-E-NOTINELEM, at tag <P> on line 64 in file
   GLOBALDEFS.GNC
   Tag can appear only within the context established by
    an element heading tag such as <CHAPTER>, <APPENDIX>, etc
%TAG-W-TAGNOTDEF, at text on line 67 in file
   GLOBALDEFS.GNC
   Tag <KIT_LOCATION_TEXT> is undefined
%TAG-W-TAGNOTDEF, at tag <DEFINE_SYMBOL> on line 69 in file[26~
   GLOBALDEFS.GNC
   Tag <INSTAL_CHAP> is undefined
%TAG-E-NOTINELEM, at tag <DEFINE_SYMBOL> on line 69 in file
   GLOBALDEFS.GNC
   Tag can appear only within the context established by
    an element heading tag such as <CHAPTER>, <APPENDIX>, etc
%TAG-E-NOTINELEM, at tag <P> on line 75 in file
   GLOBALDEFS.GNC
   Tag can appear only within the context established by
    an element heading tag such as <CHAPTER>, <APPENDIX>, etc
%TAG-W-TAGNOTDEF, at text on line 81 in file
   GLOBALDEFS.GNC
   Tag <COMP_AX> is undefined
%TAG-E-NOTINELEM, at tag <P> on line 83 in file
   GLOBALDEFS.GNC
   Tag can appear only within the context established by
    an element heading tag such as <CHAPTER>, <APPENDIX>, etc
%TAG-F-SYMISSING, at tag <FRONT_MATTER> on line 7 in file
   ISA1PREFACE.GNC
   Missing symbol argument
   Each book element must have a symbol argument
%TAG-I-UNDEFTAGS, There were 5 undefined tag invocations
%TAG-I-CPU_USAGE, Pass 1: 15.6  Pass 2: 0.0  Total: 15.6 seconds
%DOC-E-ERROR_TAG, Errors found by TAG Translator.
$ exit ($status + (0 * f$verify(verify_context))) ! SYS$SCRATCH:DOC$8FF5324A705655E0.TMP - End
  BURESI       job terminated at 13-APR-1987 17:58:20.05

  Accounting information:
  Buffered I/O count:          165      Peak working set size:  1712
  Direct I/O count:            175      Peak page file size:    5702
  Page faults:                1711      Mounted volumes:           0
  Charged CPU time:     0 00:00:21.99   Elapsed time:     0 00:00:32.76

re: .41

1)	DOC$CONVERT gets defined in DOC$ROOT:[LOCAL]DOC$LOCAL_SETUP.COM which
	was renamed from DOC$ROOT:[LOCAL]CUP$LOCAL_SETUP.COM as part of
	the installation steps performed by the installer, or should have been.

2)	You shouldn't need EITHER .LDF or .GDF if you have a profile.

3)	In the log you're missing DOC$DESIGNS.DAT from DOC$LOCAL_FORMATS,
	which again looks like an oversight by the installer.  The release
	notes indicate that the file DOC$LOCAL_FORMATS:CUP$DESIGNS.DAT should
	be renamed to DOC$LOCAL_FORMATS:DOC$DESIGNS.DAT.

	Also, T1.0 certainly DOES support automatic numbering.  My guess is
	fix the above things and get rid of your .GDF's and the associated
	defines and most of your conversion blues will disappear.  One problem
	from the log that you have to fix is that <FRONT_MATTER> now requires
	a symbolic name, as does <GLOSSARY> and <APPENDIX>.  Again, this is
	mentioned in the release notes, but I think is missing in the
	documentation or the conversion program.

    The conversion program works great...
                                         
    One note...  When an <ENDCODEXAMPLE> tag immediately preceded a 
    <DEFLIST> tag, the conversion program deleted the <ENDCODEXAMPLE> 
    tag and didn't replace it with <ENDCODE_EXAMPLE>.  The tag 
    translater didn't pick up on the error.  The text formatter reported
    an excess of lines that were too long.  I identified the problem
    by looking at the LIS file.
    
                                          donna