Conference vaxuum::online_bookbuilding

    You can either change the logical name definition of DECW$BOOK or 
    copy the *.DECW$BOOK file into your DECW$BOOK library. 
        
    1. $ DEFINE/PROCESS DECW$BOOK dev:[dir]
    
       Where the directory is where the book currently is. You can view
       files over the net by adding a node name. View the book and then 
       reset the logical name:
    
       $ DEASSIGN /PROCESS DECW$BOOK

    2. From the SYSTEM or other account w/ SYSPRV (the system manager
       may be needed to do this):
    
    	$ COPY dev:[dir]file.DECW$BOOK DECW$BOOK:/prot=W:R
    
    Note the requirement that the file must have included contents and 
    index and so forth as described in Coding Documentation Source Files 
    for the DECwindows Bookreader.

    Doing 
    
    $ DEFINE/PROCESS DECW$BOOK dev:[dir]
    
    doesn't seem to help. I still see the same library of books in the
    Bookreader window.

    Redefining the logical should work.  (although we might have done it
    system-wide, now that I think of it.)  We redefined the logical as a
    search list so the bookreader checked a local directory first, then the
    default.
    
    BTW, I've never been able to copy to DECW$BOOK:* -- I've always had to
    copy to SYS$COMMON:[DECW$BOOK]* if I recall correctly.  Something about
    rooted directories that I don't fully understand, even though it has been
    explained to me.
    
    One thing you might not have tried in .2 -- exit the Bookreader, then
    start it again.
    
    Andy

    I tried redefining the logical, and also stopping and restarting
    the Bookreader. Maybe my problem was that I processed only a single
    chapter. and it wasn't part of a book profile??

    Make sure you have the <contents_file> tag within front matter
    and the <index_file> tag. I usually have a front matter tag that
    includes the <contents_file> tag and add the <index_file> tag in
    the profile:
    
    	<profile>
        <element>(front-matter.SDML) <comment>(Include <contents_file>)
    	<element>(file.SDML)
    
    	<index_file>
    	<endprofile>
    
    Because the <contents_file> tag and <index_file> tags are required,
    people usually do a bookbuild, but use <comment> and <endcomment>
    in the profile for files they don't want to process.
    
    See Chapter 1 in the Coding Documentation Source Files for the
    DEcwindows Bookreader for additional information on required tags,
    including <title>, ...

Re: < Note 19.2 by AITG::WARNER >

>    Doing 
>    
>    $ DEFINE/PROCESS DECW$BOOK dev:[dir]
>    
>    doesn't seem to help. I still see the same library of books in the
>    Bookreader window.

Try: $ DEFINE/JOB DECW$BOOK dev:[dir]

Putting the logical name definition in the job table as opposed to the
process table has worked for me.

If that fails, try using a search list.  For example, if the system
logical name DECW$BOOK translates to XXXDISK:[FOO] and your book is
in YYYDISK:[SMITH.ONLINE], then use this command:

$ DEFINE DECW$BOOK XXXDISK:[FOO], YYYDISK:[SMITH.ONLINE]

Which version of DECwindows are you running?
If you are running BL11, the Bookreader will never find your book unless
it is added to the library.  If you have BL11, I can try to explain how
to add your book to the library.

If there is a file called library.decw$bookshelf in DECW$BOOK: you are
probably running bl11.

joe

    It was recently a BL11 problem but the initial problem remains
    unsolved, possibly being the logical names local to her LAVc.
        
    Andy (.3) is right about using SYS$COMMON:[DECW$BOOK] instead of
    DECW$BOOK: for a COPY into DECW$BOOK. You could also use 
    SYS$SYSDEVICE:[VMS$COMMON.DECW$BOOK].
    
    Chuck (.5) mentioned the /JOB table; that works OK for me as well, 
    although I've never had trouble with DEFINE /PROCESS on my standalone 
    system. 

    Any more info about Bl11 bookshelves?

I am disappointed that you can't distribute DECW$BOOK over multiple
directories. You can redefine DECW$BOOK to be a search list but you
can't do that with DECW$BOOKSHELF since it points to a file, not a
directory.

As a system manager, I either have to maintain DECW$BOOK myself (a
pain in the neck) or change the protections to allow system users to
create and delete files, edit bookshelf files, etc. (another mess,
just like DOC$TOOLS and DOC$HELP). I would prefer to have two
directories: one for SDC books (VMS, DECwindows, etc.) and one for
locally-developed books. 

As a writer, to examine my online book during development, I either
have to go through the bother of adding it to DECW$BOOK or give the
bookreader "tunnel vision" by redefining the logical names. For
example, here's a procedure for viewing a specific online book without
having to modify anything in the DECW$BOOK directory. 

$ ! Procedure:	TUNNEL_VISION.COM
$ ! Invoke:	SPAWN/NOWAIT/INPUT=NL: @TUNNEL_VISION
$ !
$ ! SET DISPLAY/CREATE/NODE=my_workstation ! for network use
$ DEFINE/USER DECW$BOOK dev:[my_directory]
$ DEFINE/USER DECW$BOOKSHELF dev:[my_directory]my_book.DECW$BOOKSHELF
$ RUN SYS$SYSTEM:DECW$BOOKREADER

It would be easy to make this procedure into a generalized utility.

A solution might be to junk the idea of static library structure
(bookshelf) files altogether and use the VMS directory structure to
define the hierarchy of the library. The bookreader could have a
command "update library" that dynamically builds the tree that
represents the library by traversing the directories pointed to by
DECW$BOOK, extracting the title from each book that it finds, and
writing that information into a file (DECW$BOOKREADER.DAT?) that can
be customized by the user.

Here is how I have taken care of the problem described in .9.

1) Have the system manager edit DECW$BOOK:LIBRARY.DECW$BOOKSHELF to include 
   the line

       SHELF\PRIVATE_LIBRARY\Private library of books

   This is the ONLY step that requires privilege!

2) In your process or job logical name table (for instance, from your LOGIN.COM),
   define the logical DECW$BOOK to be a search list, looking first at
   a directory that you own, secondly at the system bookreader library.
   A command such as the one following will do:

        $ DEFINE/JOB DECW$BOOK my_disk:[mydir.PRIVATE_BOOKS], -
                               SYS$SYSROOT:[DECW$BOOK]

3) In your directory ([.PRIVATE_BOOKS], above), create a bookshelf file named
   PRIVATE_LIBRARY.DECW$BOOKSHELF. This is a text file that you can easily
   maintain to point to your development books, or to point to further layers of 
   bookshelves.


This method allows one interaction by the manager to give everyone the 
opportunity to maintain private libraries. People who choose not to will
simply get a file not found message from RMS if they click on the 
PRIVATE_LIBRARY entry in the main bookreader menu.

If you cannot get even this minimum amount of cooperation from your system
manager, then simply copy LIBRARY.DECW$BOOKSHELF to your directory,
point the logical DECW$BOOK as specified above, and edit your private copy of 
LIBRARY.DECW$BOOKSHELF to your heart's content. The disadvantage to this
method, and the reason that I recommend the method above, is that you must now 
maintain your copy in parallel with changes to the system's copy.

-Al

you could define DECW$BOOK to a searchlist, SYS$LOGIN,SYS$COMMON:[DECW$BOOK],
then put a LIBRARY.DECW$BOOKSHELF file in SYS$LOGIN with an entry for the
SDC or SYSTEM library:

    SHELF\SYS$COMMON:[DECW$BOOK]LIBRARY.DECW$BOOKSHELF\General library
    SHELF\PRIVATE_LIBRARY\Private library of books

This can be done by any user without priv's, but does require an extra step
to get to the system-wide library each time, but you don't have to track 
updates to the system-wide library.

There is also an undocumented feature of the Bookreader intended to make
life easier for writers.  You can define a foreign symbol for the bookreader:

    $ BOOKREADER :== "$SYS$SYSTEM:DECW$BOOKREADER"

then invoke it with the name of a bookshelf:

    $ BOOKREADER testbook

and it will treat this shelf as your top-level library.  Note that it will
still use the DECW$BOOK logical name to find the bookshelf and the book(s)
you select from it.  If you then invoke the Bookreader without a parameter,
it will use the default library.

joe

Re: 19.10

> 1) Have the system manager edit DECW$BOOK:LIBRARY.DECW$BOOKSHELF to include 
>    the line SHELF\PRIVATE_LIBRARY\Private library of books

	That makes the private directories visible to all users.
	Thanks anyway.

Re: 19.11

>    SHELF\SYS$COMMON:[DECW$BOOK]LIBRARY.DECW$BOOKSHELF\General library

	I didn't realize that the SHELF line could contain a full
        filespec. That makes things easy. Thanks much. 

					Barry

    Have these procedures (for viewing a private book) changed any for the
    V2 Bookreader?  I saw that Joe mentioned in the BOOKREADER conference
    something about not needing to redefine DECW$BOOK for V2...

							-- Nina

    To answer my own question in .13 (thanks to Joe Kraetsch for helping
    me out!):  To view a book privately, as it were, under VMS 5.3 and
    DECwindows V2, you need only define DECW$BOOKSHELF to point to your
    own bookshelf file.  Include the device and directory (unless your
    file is in the system DECW$BOOK area for some reason).  For example:

    $ define decw$bookshelf user$disk:[your_dir]your_file.DECW$BOOKSHELF
    $ run sys$system:decw$bookreader

    You don't have to redefine the DECW$BOOK logical under the V2 Bookreader.

    Now, if you're running the Bookreader from a remote node and displaying
    it on your workstation, you need to specify /USER or /SUPER with the
    SET DISPLAY/CREATE command on the remote node, like so:

    $ SET DISPLAY/CREATE/USER/NODE=workstation  !from the remote node

    or

    $ SET DISPLAY/CREATE/SUPER/NODE=workstation

    If you specify /USER, you'll have to reissue the SET DISPLAY command
    if you quit from the Bookreader and run it again.  Specifying /SUPER
    (supervisor mode) keeps the SET DISPLAY info around so you don't have
    to specify it every time you run the Bookreader (or another DECwindows
    application).

    You can also, it seems, define the DECW$DISPLAY logical, possibly in
    your login file, to point to your workstation:

    $ DEFINE DECW$DISPLAY NODE::0

    You need the ::0 for some reason or other.  Joe thinks there might be some
    reason why you shouldn't explicitly define DECW$DISPLAY, but he's not sure
    what it is (and *I* certainly don't know).  He defines it, anyway.  :-)

							-- Nina