Subject: RISKS DIGEST 16.69
REPLY-TO:
[email protected]
RISKS-LIST: RISKS-FORUM Digest Tuesday 3 January 1995 Volume 16 : Issue 69
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
***** HAPPY NEW YEAR! Note the collection of DATE stories! *****
***** See last item for further information, disclaimers, etc. *****
Contents:
Gov't Recommends Electronic Copyright Restrictions (Edupage)
One for the GIFfer (CompuServe-Unisys GIF Tax Protest) (Pat Clawson)
Mail repeatedly returned to sender (Curtis Keller)
Dates in a 4GL (name removed)
Dates and Times Not Matching in COBOL (Fred Ballard)
Testing and the Sources of Dates and Times (Fred Ballard)
Dates in "Ancient" Systems (Fred Ballard)
COBOL's Two-Character Year Field (Fred Ballard)
Last call for papers for COMPASS 95 (John Rushby)
Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
----------------------------------------------------------------------
Date: Tue, 3 Jan 95 14:12:52 PST
From: "Peter G. Neumann" <
[email protected]>
Subject: Gov't Recommends Electronic Copyright Restrictions (Edupage)
From Edupage, 27 Dec 1994:
GOV'T RECOMMENDS ELECTRONIC COPYRIGHT RESTRICTIONS
The draft report on copyright law issued last July is drawing fire from
some academics and librarians, who say it gives copyright holders too much
power and "ought to maintain the balance that is maintained in the print
world," according to a law professor who moderates an Internet forum on
copyright law. One particular sticking point is U.S. Patent & Trademark
Office Commissioner Lehman's opposition to allowing libraries to ship books
electronically to patrons, because an extra copy would show up in each
recipient's computer. "To me, the burden on those who would say that ought
to be a fair use is extraordinarily high. You would see massive dislocation
of the market for that work," says Lehman. The draft report was used to
represent the U.S. position in recent meetings of the World Intellectual
Property Organization, and Lehman says a basically unaltered final report
will be ready in the spring. (Wall Street Journal 12/27/94 B5)
[To subscribe to Edupage: send a message to:
[email protected] and in
the BODY of the message type: subscribe edupage YourName (assuming that
your name is YourName; if it isn't, substitute your own name) ... To
cancel subscription to Edupage: send a message to:
[email protected] and
in the BODY of the message type: unsubscribe edupage.]
------------------------------
Date: Tue, 3 Jan 95 13:27:49 PST
From: "Peter G. Neumann" <
[email protected]>
Subject: One for the GIFfer (CompuServe-Unisys GIF Tax Protest, Pat Clawson)
An Open Letter to Our Colleagues In the Online Communications Community:
The announcement by CompuServe and Unisys that users of the GIF image format
must register by January 10 [1995] and pay a royalty or face lawsuits for
their past usage, is the online communications community's equivalent of the
sneak attack at Pearl Harbor.
The announcement of the CompuServe-Unisys GIF Tax on December 29, during the
lull between Christmas and New Year's Day, was clearly timed to cause
maximum damage while an unsuspecting public celebrated the holidays.
We at TeleGrafix Communications have no quarrel with those who seek to
protect their intellectual property and profit from it. Indeed, we are in
business to do the same. We believe those who develop software are entitled
to reap financial rewards from their labors.
But in our opinion, the timing and circumstances of the CompuServe-Unisys
action indicates this is a shakedown of the online communications community
by two powerful corporations, rather than a reasonable effort to protect
intellectual property.
The GIF format has been in widespread public use since 1987. Its widespread
use and royalty-free licensing has been encouraged by CompuServe for years.
Neither CompuServe or Unisys have made any significant improvements to GIF
or its underlying LZW algorithm and compression process to justify charging
for what has been free.
Giving GIF users only 14 days to comply with sudden, unexpected demands to
pay the private CompuServe-Unisys GIF Tax or face prosecution for past usage
of what had been promoted for seven years as free, open standard software is
unconscionable. It is especially outrageous since CompuServe and Unisys
admit in writing that they decided to require licensing SIX MONTHS AGO in
June, and didn't announce it to the public until now.
According to the CompuServe-Unisys GIF licensing agreement, the settlement
of the patent dispute was executed on June 21, 1994. CompuServe agreed to
implement the agreement "as soon as reasonably practicable and in no case
later than six (6) months after the date this Agreement is executed..."
That six month period ended on December 21, 1994 -- but CompuServe did not
make the licensing terms public until December 28. Indeed, CompuServe
appears to have violated the terms of its own settlement agreement with
Unisys.
While many of the messages we have read online in reaction to the
CompuServe-Unisys GIF Tax decree express both dismay and disbelief,
virtually none have analyzed the actual provisions of the licensing
agreement. It is in this area that TeleGrafix Communications wishes to
contribute to the dialogue.
In our opinion, the CompuServe-Unisys licensing agreement is both illogical
and overly broad. Let's examine some of its key provisions. All quotes
cited are directly from the agreement.
1. CompuServe will license Developers who want to use GIF technology. The
term "developer" is defined as "the other undersigned party to the
agreement," and it seems to apply to ANYONE who contemplates distributing
any product that uses the GIF format.
2. Developers will be licensed to sell or distribute "Products" that "use
and exploit GIF...solely within the Field of Use." The term "Field of Use"
is defined as "primarily for accessing the CompuServe Information Service
and for manipulating and viewing data received through the CompuServe
Information Service." The licensing agreement further defines the term
"Products" as being "software that is developed or distributed...which is
designed for and used primarily for accessing the CompuServe Information
Service and for manipulating and viewing data received through the
CompuServe Information Service." IT APPEARS THAT THE ONLY LAWFUL USE OF GIF
WILL BE FOR COMPUSERVE-RELATED PRODUCTS. Using GIF images in any other
manner, such as on CD-ROMs or bulletin board systems, is prohibited. Most
of the thousands of products that have used GIF in some manner are
henceforth contraband.
3. Developers may no longer "use, copy, modify or distribute the GIF
specification, except as expressly permitted by CompuServe." This states
that the GIF specification can no longer be shared, published or uploaded in
any manner without the express consent of CompuServe.
4. Members of the public are prohibited from using any software product
containing GIF until they have become a REGISTERED user of the product. The
customer also must agree to use the product "primarily for accessing the
CompuServe Information Service and for manipulating and viewing data
received through the CompuServe Information Service." This virtually
eliminates the concept of freeware or shareware containing GIF capabilities,
since prospective customers can no longer try out these software products
without registering them first.
5. Software developers must pay $1.00 for a license to use GIF, PLUS a fee
equal to the GREATER of 1.5% of the selling price of the product, or $0.15
per "Disposition." Disposition is defined as "the sale, lease or license or
any other grant of rights to a Product or any new Product." All royalties
must be paid quarterly. Noncommercial and freeware usage of GIF technology
is NOT exempted from the royalty requirement. Because the royalty
provisions and definition of "Disposition" are so broad in scope, it appears
that a GIF Tax payment may be due to CompuServe-Unisys each time a GIF image
is transmitted via BBS or Internet. The operators of a BBS or World Wide
Web site with hundreds or thousands of GIF images online could easily be
bankrupted by these licensing requirements.
6. CompuServe must be notified of ANY new product using GIF when it is first
offered to customers.
7. Persons using GIF must keep records of its use, and CompuServe has the
right to audit those records every year upon seven days notice. Persons
using GIF must pay the cost of the audit if a royalty underpayment of 10%
or more is discovered, along with 12% interest on any underpaid royalties.
8. Even if the patent is later found by the courts or the U.S. Patent Office
to be invalid and unenforceable, or if the patent expires, any developer must
"return all copies of the GIF specification and any confidential information
of CompuServe then in its possession or control to CompuServe, (ii) stop
using the Licensed Technology, and (iii) stop distributing Products." This
states that EVEN IF THE PATENT IS OVERTURNED OR EXPIRES, YOU MUST STOP USING
OR DISTRIBUTING GIF.
9. Even though CompuServe has publicly disseminated the text of the
agreement it wants GIF users to sign, the terms of the agreement are to
remain confidential. This is illogical, to say the least, since they have
posted it for public download on their own system.
10. Developers have to indemnify and hold CompuServe harmless for any
damages if their CUSTOMERS somehow use GIF technology in a way not permitted
by the licensing agreement.
11. Unisys has the right to enforce the agreement, as well as CompuServe.
Further, Unisys has the right to pursue legal action or seek damages against
Developers even after the agreement has terminated.
TeleGrafix Communications Inc. will not sign such a licensing agreement. We
think most other software developers, BBS sysops and Web site operators also
will refuse to sign.
We encourage our colleagues in the online communications community to
evaluate the CompuServe-Unisys action, and to lodge appropriate protests
directly with those companies.
We believe that the CompuServe-Unisys GIF Tax drives a stake through the
heart of Internet development. It will cripple the World Wide Web, NCSA
Mosaic, and other Internet multimedia technologies that rely heavily on GIF
imaging.
Fortunately, we at TeleGrafix Communications do not depend on GIF imaging in
our new RIPscrip 2.0 online multimedia technologies. We chose to implement
the JPEG image format and only recently decided to add GIF support as a
convenience to our customers. Due to the restrictive conditions of the
CompuServe-Unisys GIF Tax and licensing agreement, we must now reevaluate
our plans for supporting GIF use in the upcoming release of RIPscrip 2.0.
While our company hopes to profit financially from our advanced RIPscrip 2.0
technology, we will not demand royalties from those who have used the
freeware versions of our earlier RIPscrip 1.54 products and/or technical
specifications. The RIPscrip 2.0 specification also will be made public for
third-party use after it is finalized.
We expect that the CompuServe-Unisys action will spell the death of GIF
as a commercially viable technology, shifting the attention of the online
communications community to JPEG imaging.
Sincerely,
Pat Clawson
President & Chief Executive Officer
TeleGrafix Communications Inc.
Huntington Beach, CA
Voice: (714) 379-2140
Fax: (714) 379-2132
BBS: (714) 379-2133
Internet:
[email protected]
------------------------------
Date: Mon, 2 Jan 1995 22:05:11 -0600
From: Curtis Keller <
[email protected]>
Subject: Mail repeatedly returned to sender
"You are invited to discover Wired magazine - free"
I received a pretty snazzy advertisement for Wired magazine 2 weeks
ago and I decided to order the "free sample copy". I have placed the
postage paid reply card in the mail 3 times, and 3 times a day or so
later the same reply card has returned. It turns out that the reply
card has my name and address on the flip side in the same position
as the address of Wired magazine on the "correct side." Additionally
the postal service 5+4 bar coding is on both sides of the card - once
for Wired magazine and once for "me". I'll toss it in the mail once again.
Curtis Keller 713-953-8309
[email protected] [email protected]
------------------------------
Date: Tue, 3 Jan 95 12:12:12 XST
From: [Name removed at submitter's request]
Subject: Dates in a 4GL
I am currently using a fourth-generation language called NOMAD2. NOMAD2
stores dates internally as the number of milliseconds since a date in the
1580s when the Gregorian calendar was first put into use. At least the
version of NOMAD2 that I use does (1).
For the most part, this seems to work out very well. Much of the fears
about what happens with computer-stored dates on January 1, 2000 are
groundless for NOMAD2. But perhaps not all of them. Using an appropriate
date data type may have led to a false sense of security.
Most years are entered in the application system I'm working with as two
digits. NOMAD2 allows this and effectively adds 1900 to years entered as
two-digit years. When the system date changes to 2000, I'm not sure whether
NOMAD2 will start adding 2000 to the years entered. (There may even be a
system variable for setting this.) Regardless, on 1-Jan-200, it will still
not be appropriate to add 2000 to years from the now previous century or
1900 to years from the now current century. Any arbitrary scheme to treat,
say, the entered years 30 through 99 as 1930 through 1999 and 00 through 29
as 2000 through 2029 would lead to problems (2) since the system I'm working
with could involve birthdates of 1929 and before.
Since the department I am working in has chosen to stay with the current
version of NOMAD2 (1), any new schemes for handling this problem may be lost
to my application. The whole topic of staying with a stable release of a
system and not getting improvements or fixes to existing errors versus going
to new releases that have improvements, may fix existing faults, but may
introduce new ones is a rich risk management topic.
NOTES:
1. A new application system in another operating environment is replacing
the one I am maintaining. As a consequence, no further upgrades are being
planned for NOMAD2 in our operating environment. The vendor of NOMAD2
continues to make upgrades. The vendor's most release dealt with a date
problem from one its clients. The client was storing uninitialized dates on
its DB2 database as something like January 1 of the year 0 which DB2's date
data type allows. NOMAD2 can map DB2 databases, but its date data type did
not allow dates before the introduction of the Gregorian calendar. (I
assume they haven't had any clients who wanted to store archaeological
data.) The client was stubborn and the new release of NOMAD2 contains a fix
for the problem. I'm not aware of the implementation details.
2. As Brian Hayes noted in "Waiting for 01-01-00" on p. 14 of
January-February 1995's _American Scientist_.
------------------------------
Date: 01 Jan 95 21:31:03 EST
From: Fred Ballard <
[email protected]>
Subject: Dates and Times Not Matching in COBOL
There is no way to obtain the system date and time in one statement in
COBOL. A program could get the date just before midnight and then get the
time relative to the day after the date it got. A timestamp of 31-Dec-1994
00:00:01 indicates just after midnight between 30-Dec-1994 and 31-Dec-1994,
but it could have been obtained from a COBOL program running around midnight
between 31-Dec-1994 and 1-Jan-1995.
The only way in a COBOL program to assure that the time obtained is for the
date obtained is to loop getting the date, then the time, and then the date
again until both dates match (as would usually be the case).
No one knows how often such a check is performed in existing COBOL code, but
I would guess it is very rare. No one knows how likely such an error would
occur or what consequences it might have. But it certainly is not
desirable. (It's a little like the Pentium FDIV bug.)
I haven't heard of any problems actually caused by this, but the potential
risk is there as it is in any language that makes accessing the date and
time simultaneously impossible. (I believe BASIC shares this problem with
COBOL.)
------------------------------
Date: 01 Jan 95 21:31:02 EST
From: Fred Ballard <
[email protected]>
Subject: Testing and the Sources of Dates and Times
Application software typically draws the current date and time directly from
the system. Not using data hiding, that is, drawing the current time from
another application module, may cause problems with testing and could lead
to faults due to the difficulty of testing if it is not possible to change
the system date and time during a test.
A realtime financial application may want to close the books for the now
previous day when the time goes past midnight. I've heard of such an
application and the developers did not use data hiding. As a result they
had to run their tests when the system (and actual) time changed to
midnight. Therefore, only one test could be run each night and in this case
they had to rearrange their normal 8-5 working hours to center around
midnight. Introduction of changes and fixes were more easily introduced
when the programs were modified to access the "current" date and time
through a common module that could shift the time during a test.
However, as with most things, the tradeoff of using data hiding instead of
directly accessing the system date and time opens up the potential risk of
accidentally using test times in a production environment. (This risk might
still be present if a test was allowed to alter the system date and time
thereby moving data hiding to another level.)
------------------------------
Date: 01 Jan 95 21:30:55 EST
From: Fred Ballard <
[email protected]>
Subject: Dates in "Ancient" Systems
In a few IBM 1401-based programs at the insurance company I was working at
in the late 1960s, the year was stored as a one-character field!
Fortunately the problem of going from 1969 to 1970 in these programs was
recognized in time, the programs were few in number and modest in size (our
1401s had a maximum main memory of 8K), and the programs were corrected in
time.
------------------------------
Date: 01 Jan 95 21:30:57 EST
From: Fred Ballard <
[email protected]>
Subject: COBOL's Two-Character Year Field
Stating the fact that COBOL has a default date format used in its
special-registers bypasses the fact that COBOL has no date data type for the
storing of fates (Freudian-slip, make that dates).
This has left the coders of the billions of lines of existing COBOL code
free to invent as many date formats as human creativity will allow. In my
reading, use, and maintaining of COBOL code in over twenty-six years of
information system programming, this is a surprisingly large number.
This is one of the reasons "dusty deck" COBOL systems are such a problem as
the year 2000 draws near. No assumptions can be made as to how dates are
stored in COBOL-based systems and files. Also, the manipulation of a given
format varies from one COBOL program to the next. There is no guarantee
that any installation-wide modules are used for date manipulation.
(Installation-wide is pretty much the best you can hope for; COBOL itself
has no date manipulating modules.)
Actually, there is no guarantee that date routines will even be concentrated
and re-used within a given COBOL program. Date processing is often
scattered throughout the program, with each date variable having not only
its own unique processing but different code for the same operations on a
given date at different points in a program.
Obviously, some of this date code may contain errors. In many cases the
errors are compensated for, consciously or unconsciously, by the program's
developers or maintainers. So correcting a date computation at one point
may lead to an error because the next use of the date has an existing
correction for the previous error.
[Thanks to Fred, who also pointed out an error on Page 88 of my RISKS
book, which should have read "COBOL uses a two-character YEAR field"
(instead of DATE). Sorry! PGN]
------------------------------
Date: Fri 30 Dec 94 12:08:49-PST
From: John Rushby <
[email protected]>
Subject: Last call for papers for COMPASS 95
Typeset copies of the CFP are available via anonymous ftp from ftp.csl.sri.com
in /pub/compass95-cfp.{txt|tex|dvi|ps} and /pub/compass95-cfp-a4.{dvi|ps}
or via WWW from
http://www.csl.sri.com/compass95.html .
CALL FOR PAPERS
COMPASS '95
10th Annual IEEE Conference June 26--30, 1995
on COMPuter ASSurance (COMPASS) Gaithersburg, MD USA
Sponsored by IEEE Aerospace and Electronic Systems Society
and IEEE National Capital Area Council
In cooperation with The British Computer Society
The purpose of this conference is to bring together researchers,
developers, integrators, and evaluators who work on problems related
to specifying, building, and certifying high-assurance,
high-consequence computer systems. What distinguishes COMPASS from
similar conferences is its emphasis on bridging the gap between
research and practice. For researchers this provides an opportunity
to present new results, theories, and techniques both to other
researchers, and to practitioners who can put them to use. They can
also learn from practitioners of issues and problems encountered in
building real systems. Practitioners have an opportunity to share
lessons learned, to hear of new research, and to influence future
research directions.
The conference will be held at the National Institute of Standards
and Technology in Gaithersburg, Maryland, which is a suburb of
Washington DC (4 miles from the Shady Grove Metro Station).
The proceedings will be published by the IEEE.
Papers should present advances in the theory, design, implementation,
evaluation, or application of high-assurance systems, or report on
experiments, evaluations, and open problems in the use of new
technologies for computer assurance. Special consideration will be
given to presentations (either single papers or paper pairs) by
practitioners and researchers who have worked on the same problem.
There will also be a tools fair and the conference will be preceded by
one or two days of tutorials. Papers, panel session proposals,
tutorial proposals, and tools fair proposals are solicited in
relevant areas including the following:
Software Reliability Software Safety Computer Security
Formal Methods Tools Human-Computer Interfaces
Real-Time Systems Networks Embedded Systems
V&V Practices Certification Standards
Measurement and Metrics Organization Theory Lifecycle Processes
Representative application areas of interest include but are not
limited to: communications, military systems, avionics, road and rail
transport, space systems, nuclear and conventional power generation,
plant and process control, and medical systems.
INSTRUCTIONS TO AUTHORS:
Send five copies of your paper, panel session proposal, tutorial
proposal, or tools fair proposal to John Rushby, Program Chair, at
the address given below. Abstracts, electronic submissions, late
submissions, overlength papers and papers that cannot be published in
the proceedings will not be considered. Papers submitted from
outside North America should be sent via overnight courier service or
express mail. Exceptionally, authors in countries where copying or
printing facilities are limited may submit a single copy in any form
available to them (including electronic mail).
Papers must be received by January 17, 1995 and must not exceed 7,500
words. Authors are responsible for obtaining prior to acceptance any
and all necessary permissions and clearances for publication and are
expected to present their paper in person if it is accepted.
Authors will be notified of acceptance by March 14, 1995.
Camera-ready copies are due not later than April 17, 1995.
Papers that describe use of technology presented at a previous
COMPASS conference are eligible for a special award. Papers of
exceptional quality and appropriate subject matter are eligible for
inclusion in a special issue of the Journal of High Integrity Systems
or the Journal of Computer Security.
Limited financial assistance will be available for student authors.
PROGRAM COMMITEE
Robin Bloomfield Adelard, UK
Connie Heitmeyer Naval Research Laboratory, USA
John Gannon University of Maryland, USA
Rich Gerber University of Maryland, USA
Jon Jacky Radiation Oncology, University of Washington, USA
Jeremy Jacob York University, UK
John Knight University of Virginia, USA
Carl Landwehr Naval Research Laboratory, USA
Keith Marzullo University of California, San Diego, USA
John McLean Naval Research Laboratory, USA
Jon Millen MITRE Corporation, USA
Steve Miller Collins Commercial Avionics, USA
Peter Neumann SRI International, USA
Hans Rischel Technical University Denmark
Jeannette Wing Carnegie-Mellon University, USA
FOR FURTHER INFORMATION CONCERNING THE SYMPOSIUM, CONTACT:
Bonnie Danner, General Chair John Rushby, Program Chair
Computer Science Laboratory
TRW Systems Division SRI International
One Federal Systems Park Drive 333 Ravenswood Avenue
Fairfax, VA 22033, USA Menlo Park, CA 94025
Tel: (703) 876-4383 Tel: (415) 859-5456
Fax: (703) 876-4304 Fax: (415) 859-2844
[email protected] [email protected]
Paul Anderson, Publicity Chair
Space & Naval Warfare Systems Command
SPAWAR 224-1B
Washington DC 20363
Tel: (703) 602-3179
FAX: (703) 602 4485
[email protected]
Additional and typeset copies of this call for papers are available via
anonymous ftp from ftp.csl.sri.com in /pub/compass95-cfp.{txt|tex|dvi|ps}
or via WWW from
http://www.csl.sri.com/compass95.html .
------------------------------
Date: 22 December 1994 (LAST-MODIFIED)
From:
[email protected]
Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.
The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks.
Undigestifiers are available throughout the Internet, but not from RISKS.
SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
your system, if possible and convenient for you. BITNET folks may use a
LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. U.S.
users on .mil or .gov domains should contact <
[email protected]>
(Dennis Rears <
[email protected]>). UK subscribers please contact
<
[email protected]>. Local redistribution services are
provided at many other sites as well. Check FIRST with your local system or
netnews wizards. If that does not work, THEN please send requests to
<
[email protected]> (which is not yet automated). SUBJECT: SUBSCRIBE
or UNSUBSCRIBE; text line (UN)SUBscribe RISKS [address to which RISKS is sent]
CONTRIBUTIONS: to
[email protected], with appropriate, substantive Subject:
line, otherwise they may be ignored. Must be relevant, sound, in good taste,
objective, cogent, coherent, concise, and nonrepetitious. Diversity is
welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
MESSAGES in responses to them. Contributions will not be ACKed; the load is
too great. **PLEASE** include your name & legitimate Internet FROM: address,
especially from .UUCP and .BITNET folks. Anonymized mail is not accepted.
ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
Relevant contributions may appear in the RISKS section of regular issues
of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
All other reuses of RISKS material should respect stated copyright notices,
and should cite the sources explicitly; as a courtesy, publications using
RISKS material should obtain permission from the contributors.
CURRENT ARCHIVES: "ftp unix.sri.com<CR>login anonymous<CR>YourName<CR>
cd risks<CR> or cwd risks<CR>, depending on your particular FTP.
Issue J of volume 16 is in that directory: "get risks-16.J<CR>". For issues
of earlier volumes, "get I/risks-I.J<CR>" (where I=1 to 15, J always TWO
digits) for Vol I Issue j. Vol I summaries in J=00, in both main directory
and I subdirectory; "bye<CR>" I and J are dummy variables here. REMEMBER,
Unix is case sensitive; file names are lower-case only. <CR>=CarriageReturn;
UNIX.SRI.COM = [128.18.30.66]; FTPs may differ; Unix prompts for username,
password;
[email protected] and WAIS are alternative repositories.
Risks can also be read on the web at URL
http://catless.ncl.ac.uk/Risks
Individual issues can be accessed using a URL of the form
http://catless.ncl.ac.uk/Risks/VL.IS.html
(Please report any format errors to
[email protected])
FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving
it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info
regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL
RISKS COMMUNICATIONS; as a last resort you may try phone PGN at
+1 (415) 859-2375 if you cannot E-mail
[email protected] .
------------------------------
End of RISKS-FORUM Digest 16.69
************************
