| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 423.1 | | HYLNDR::BROWN | | Wed Feb 26 1997 15:23 | 15 |
|
Let's see what we have:
1. The OpenVMS Operating System group is making its docs available
on the web
2. This is via direct HTML, not HTBOOK as far as I can tell -- the
header of these files say the source is SDML not bookreader
files.
Therefore, this strategy must apply to any Digital product and any
customer who wants to electronically alter and transmit via HTBOOK and
the public web the contents of ConOLD...
Yup, makes perfect sense to me....
|
| 423.2 | | HYLNDR::BROWN | | Wed Feb 26 1997 15:38 | 21 |
|
Also, the group doing this requested a copy of the tools I used to
create the HTML books on our internal web site. It wouldn't surprise
me to see the HTML pages copied off the site and exported to customers.
In fact I believe this is already happening as we get 2,000-5,000 hits
a day on our site for all over the world and only about 1/2 declare
themselves as robots... yet many are systematically walking the full book
structures in a manner that means the pulled information isn't being read
(timestamps seconds apart, and this goes on for hours).
The funny part is that in order to serve the docs via HTBOOK you
require a copy of the documenation set which at present is only
available, as a more or less complete and up to date set, on ConOLD...
if the value of ConOLD is diluted because it is freely distributed
then we can no longer afford, as a corporation, to produce this title and
then the ability to serve the latest docs easily via HTBOOK goes away
because the convenient source goes away.
Let anarchy reign!
|
| 423.3 | | HYDRA::SCHAFER | Mark Schafer, SPE MRO | Fri Feb 28 1997 14:27 | 6 |
| sure, however, I wouldn't want to be the person from DIGITAL that told
someone they could legally do anything! You're setting yourself up for
trouble if you don't refer them to an official source, like the VMS
product manager.
Mark
|
| 423.4 | | HYLNDR::BROWN | | Mon Mar 03 1997 16:45 | 21 |
|
Duh.
1. Except VMS product management wouldn't have a clue since it isn't
their product being referred to.
2. Moreover VMS isn't the only platform within Digital which has on-line books.
But you knew that.
3. Forwarding it on to VMS product management will likely result in the same
responses as in the past, that is a personal reply/mail message to *me*
about the problem. It ain't my problem. I do database maintenance
and tool technical support.
Of course this has been forwarded on to the proper folks at MCS who do
*own* the specific products in question and who have pursued this in
the past. I'd be rather shocked if my mail was the first anyone in MCS
first heard of this.
Anarchy reigns.
|
| 423.5 | A "How to" has hit the streets... | FOUNDR::FOX | David B. Fox -- DTN 285-2091 | Wed Mar 19 1997 19:05 | 65 |
| Mind you, I don't want to add fuel to the fire, but... this just
crossed my terminal from the VMS-WEB list and I thought some of you
might be interested...
David
From: US5RMC::"VMS-WEB-daemon@Kjsl.COM" "MAIL-11 Daemon" 19-MAR-1997 15:54:32.25
To: VMS-WEB-daemon@Kjsl.COM
CC:
Subj: Serving the new version of the doc CDs with WEBBOOK
Here's a step by step list of how I got WEBBOOK to serve the new (March 97)
version of the VMS documentation CDROMs:
1. The Infoserver is running v3.3. I create service names that are independent
of the volume labels so that I don't have to change anything for a new
quarterly update.
CREATE SERVICE VAXDOC1 FOR DK8:
CREATE SERVICE VAXDOC2 FOR DK9:
CREATE SERVICE VAXDOC3 FOR DK10:
CREATE SERVICE VAXDOC4 FOR DK11:
2. Insert the three layered products CDs in DK8:, DK9:, and DK10:. Put the VMS
documentation CD in DK11:.
3. InfoServer Monitor v2.1 is used to keep the volumes mounted at all times.
See the Installation and User's Guide in the [INFOMON.LINE_DOCS] or
[INFOMON.POST_DOCS] directory on the Infoserver software disk.
$LADCP := $ESS$LADCP
$LADCP BIND IS_V33
$@SYS$UPDATE:VMSINSTAL INFOMON021 DAD$IS_V33:[INFOMON.KIT]
4. Bind the CDs. (I have this in SYSTARTUP_VMS.COM)
$LADCP := $ESS$LADCP
$LADCP BIND VAXDOC1/SYSTEM
$LADCP BIND VAXDOC2/SYSTEM
$LADCP BIND VAXDOC3/SYSTEM
$LADCP BIND VAXDOC4/SYSTEM
5. Start INFOMON. (I have this in SYSTARTUP_VMS.COM)
$SYS$MANAGER:INFOSERVER_MONITOR_STARTUP
6. Restore the bookreader saveset:
$CREATE/DIRECTORY WWW_ROOT:[VAXDOC]
$BACKUP DAD$VAXDOC1:[SETUP]VAXDOCMAR97.SAV/SAVE WWW_ROOT:[VAXDOC]
7. Define some logicals to point to the bookshelf files:
$DEFINE/SYSTEM/EXEC VMS$BOOK DAD$VAXDOC4:[DECW$BOOK]
$DEFINE/SYSTEM/EXEC LPD$BOOK WWW_ROOT:[VAXDOC]LIBRARY.BKS
8. Build WEBBOOK by using WWW_ROOT:[SCRIPT_CODE]BUILD_WEBBOOK.COM
9. Make a page with the following links:
<LI><A HREF="/htbin/webbook/vms$book/">VMS Operating System Documentation</A>
<LI><A HREF="/htbin/webbook/lpd$book/">VMS Layered Products Documentation</A>
10. Click away!
Don Arrowsmith TM21 | Voice 609-538-6730
Naval Air Warfare Center |
Box 7176 | Fax 609-538-6800
Trenton NJ 08628 USA | arrow@napc-1.navy.mil
|
| 423.6 | Doesn't anybody *READ* the agreements?! | HYLNDR::BROWN | | Wed Mar 19 1997 22:21 | 23 |
|
Those instructions are of themselves harmless. Many customer sites
have internal web servers for which applying said instructions are
perfectly valid (no difference between that and using node::
redirection). The only problem is when they cross over and make the
information publically available on the web is it considered wrong.
The MCS folks have been reasonably good at pursuing such matters.
And then we have users who make publically available on the web
Digital stuff that starts off at the top of the document...
"Any party granted access to the following copyrighted information
(protected under Federal Copyright Laws) , pursuant to a duly executed
Digital Service Agreement may, under the terms of such agreement copy
all or selected portions of this information for internal use and
distribution only. No other copying or distribution for any other
purpose is authorized."
I guess they believe the public web is "internal use"? This is
probably the most blatent (and stupid!) type of flagrant violation
I can think of.
|