sss ssss      rrrrrrrrrrr
                      ssss    ss       rrrr   rrrr
                     sssss     s       rrrr    rrrr
                     ssssss            rrrr    rrrr
                      ssssssss         rrrr   rrrr
                          ssssss       rrrrrrrrr
                    s      ssssss      rrrr  rrrr
                    ss      sssss      rrrr   rrrr
                    sss    sssss       rrrr    rrrr
                    s  sssssss        rrrrr     rrrrr
         +=======    Quality Techniques Newsletter    =======+
         +=======             August 2002             =======+

Subscribers worldwide to support the Software Research, Inc. (SR),
TestWorks, QualityLabs, and eValid user communities and other
interested parties to provide information of general use to the
worldwide internet and software quality and testing community.

Permission to copy and/or re-distribute is granted, and secondary
circulation is encouraged by recipients of QTN provided that the
entire document/file is kept intact and this complete copyright
notice appears with it in all copies.  Information on how to
subscribe or unsubscribe is at the end of this issue.  (c) Copyright
2002 by Software Research, Inc.


                       Contents of This Issue

   o  QW2002 -- Conference Reminder

   o  Making Software Testing More Effective (Part 2 of 2), by Boris

   o  Attaining Excellence

   o  eValid Yahoo Discussion Group Formed

   o  ISSTA Technical Program

   o  International Workshop on Certification and Security in E-

   o  Quality Is......

   o  ICSE 2002 Conference Description

   o  Edsger W. Dijkstra: 1930-2002

   o  QTN Article Submittal, Subscription Information


                      Fifteenth International
          Software and Internet Quality Week Conference,
            3-6 September 2002, San Francisco, CA  USA



Discover why leading companies like as CNET, Cisco Systems, Fidelity
Investments, Hewlett Packard, IBM, Intel, Jet Propulsion Labs,
Microsoft, Motorola, and Public Works & Gov't Services (Canada) are
coming to Quality Week!

QW2002 is the meeting place where you get a balanced picture of
applied test and quality control technologies, of current
academic/industrial research and development, and of real-world
experience.  QW2002's speakers are top industry and academic
leaders, ready to share the latest thinking and strategies that will
help your business succeed and grow.

Hear exciting keynote addresses from:

  > Fred Baker, Cisco Systems
  > Don O'Neill, Center for National Software Studies
  > Eric Simmons, Intel Corporation
  > Professor Dick Hamlet, Portland State University
  > Robert Binder, Mobile Systems Verification
  > Gregory Pope, University of California/LLNL

*** QW2002 OFFERS...

The QW2002 program consists of four days of Training Seminars,
Mini-Tutorials & Quick-Starts, Panels, Technical Papers and
Workshops that focus on software and internet test technologies as
practiced around the world.

  * 14 full and half-day in-depth training seminars.
  * 92 Presentations, in a three-day, six-track Conference.
  * Practical Keynotes with real-world experience from leading
    industry practitioners.
  * The latest research results from academia.
  * Exchange of critical information among technologists, managers,
    and consultants.
  * Lessons learned & success stories.
  * State-of-the-art information on software quality and web
  * Vendor technical presentations and demonstrations.
  * Latest tools and trends.
  * Three-day Vendor Show/Exhibition.

You're invited to participate in the premier Software and Internet
Quality Conference -- Quality Week 2002, San Francisco, 3-6
September 2002.


Pre-Register before the start of the conference and receive the
early-bird rates through August 30:



If you have a group of people who will register together we have
some really sweet deals for you!  Call Rita Bral at +1 (415)
861-2800 for details on how to save a bundle!


Explore San Francisco during the Labor Day week-end before, or stay
after Quality Week and enjoy the special QW2002 Conference rate of
$149 single/double (valid from August 30 through September 8):


| Quality Week 2002               | Phone:        [+1] (415) 861-2800 |
| SR Institute                    | Toll Free (USA):   1-800-942-SOFT |
| 1663 Mission Street, Suite 400  | FAX:          [+1] (415) 861-9801 |
| San Francisco, CA  94103        | Email:       |
| USA                             | Web: |


        Making Software Testing More Effective (Part 2 of 2)
                            Boris Beizer

      Note:  This article is taken from a collection of Dr.
      Boris Beizer's essays "Software Quality Reflections" and
      is reprinted with permission of the author.  We plan to
      include additional items from this collection in future
      months.  You can contact Dr.  Beizer at

2.3.  Failure to Automate Test Design and Debug Labor

Why haven't we been able to automate more of the test design work?
There are all of the barriers for test execution automation, plus:

1.  Insufficient training in test techniques obviates use of
sophisticated tools (even if they did exist).

2.  Automate what? if we don't know what works.

3.  Conflicts with software design automation needs.

4.  Hardware, operating systems, language processors, not designed
with testing needs in mind.

Let's learn from the one activity we know best and which is closest
to what we do -- software design.  Software design automation has
advanced (over the past three decades by:

1.  Higher order languages -- where is our common scripting

2.  Proprietary software packages -- where are the proprietary test

3.  Common subroutines, utilities, libraries -- where are they for

The big payoff in test design automation will not come from fancy
tools, but from the evolution of maintained libraries of test
"subroutines", test "macros", and test "functions".  That can't
happen without a substrate of test configuration control and
management and test design languages.  In other words, look at the
panoply of software development tools and recognize that our needs
in testing is no less complex.

2.4.  Why We Don't Know When to Stop

The danger today is as great for overtesting without purpose as it
was in the past for undertesting.  The marketplace will eventually
take care of the habitual undertesters.  Pointless overtesting can
wreck a budget and schedule as surely as bad software.  Why is it
that most of us jump from under-testing to gross overtesting?

1.  Over-reaction to a history of miserable software.

2.  Few objective standards for "adequate" testing.

3.  No quantitative definition of software quality.

4.  The "perfect" software myth.

5.  No universal use of cover monitoring and other metrics.

6.  A murky legal situation.

We don't know when to stop because we don't know how effective our
techniques are; because we're afraid to stop; because we don't have
standards that tell the tester when to stop and the buyer when to

3.  The Role of Standards

3.1.  Overview

The key log to the logjam lies in the development, adoption and
promotion of software quality, testing, and acceptance standards.

3.2.  Do Standards Dictate or Describe?

The role of standards is generally misunderstood.  The popular
notion is that an industry standard dictates what the industry
should do.  That's not the case.  Standards do not dictate, they
describe the industry's consensus as to what constitutes acceptable
practice: standards define a floor, not a ceiling.  In other words,
a standard is not something you have to "work up to" but rather,
something you don't want to "work down to".  Private and government
purchasing standards such as MIL-specs can dictate -- e.g.  "If you
don't meet the standard I won't buy"; but there is an implied
willingness to pay the (high) price for meeting such standards.  The
standards produced by IEEE, ISO, and CCITT are marvels of compromise
and persuasion.  In the communications field, we have CCITT
"recommendations", which are always unanimously approved.  That
means that representatives from the US and the Soviet Union, Israel
and Syria, Iran and Iraq, South Africa and Nigeria, Ireland and
England, North and South Korea, and even Lybia, have gotten together
and agreed on something.  Because standards must compromise, they
tend to drift to the lowest common denominator.  Only rarely can
they elevate the current practice.

3.3.  Who Does the Standard Protect?

Another popular misconception is that standards protect the
consumer: the popular notion of the standards developer as a back-
room Ralph Nader who protects the poor buyer from the nefarious
abuse of the vendor.  Standards don't do a very good job of
protecting the buyer. Every lemon I've ever been stuck with met all
the applicable standards. Standards do however, provide considerable
protection for the supplier. In our case, given test and quality
standards, the legal issue of whether or not a piece of software is
adequately tested is considerably simplified if there is a standard
against which to measure testing thoroughness.  A quantifiable
quality standard would destroy, once and for all, the perfect
software myth.  A formal standard for acceptance criteria would go a
long way towards not being forced into ludicrous overtesting by a
naive buyer with a better lawyer.

3.4.  Why is the Process so Slow.

Standards evolution is a slow process -- that's good, not bad.
There's nothing worse than a hastily conceived standard.  For
example, the width of our railroad tracks are based on the
separation of the wheels on Roman chariots of two thousand years
before.  The chariot wheel standard was slow in coming but it was
hastily adopted for railroads.  We're living now with antiquated and
hastily conceived standards such as 60 cycle electricity, 525 line
TV screens, and almost useless AM radio bandwidths.  With all those
bad examples around, it's no wonder that standards developers want
inertia in the system.  But there's a marvelous way to get a defacto
standard into being, without making a final commitment -- and I
don't mean getting IBM to adopt it.  The method is the draft
standard.  Draft standards can to some extent push the state of the
art, propose, and guide.  While they don't have the weight of a
formal standard, often they're the only thing we can use while the
deliberation is going on.  If you reject a proposed standard because
it's "only a draft" you may be opting to work without a standard for
several years or decades.

Standards are adopted slowly but they also evolve.  Standards start
out weak and get stronger with time.  It's obvious why.  The
consensual process is a weakening process.  Also, if an initial
standard is overly strong, it will be ignored.  Alternatively, a
prematurely strong standard may so distort the economics that the
product never comes to the market.  The example is that of orphan
drugs, which because of inappropriate testing standards, are not
available in the US.  The standard is strengthened when the
consensus' adoption is almost universal and when, in fact, most of
the industry is already working to a higher standard.

3.5.  Who Develops the Standards?

The popular notion is that of some gurus in the NBS who sit down and
dictate a standard, fully developed, when the time is ripe.
Actually, you develop the standards which NBS, ISO, or IEEE
eventually codify. The typical standards worker is an unpaid,
understaffed, and overworked volunteer.  The NBS worker is paid to
work on standards, but may have dozens of different standards to
honcho simultaneously so that her work on any one standard is also
part -- disabuse yourself of the notion that there's a vast, well
funded, standards development organization out there -- there isn't.
There's only a small army of dedicated and unpaid volunteers.  You
want standards? Help build them? You want to hurry the process? Make
the wheel squeak by engaging in a dialogue with the standards
groups.  You don't like the draft standards? Say so by participating
in the process.

3.6.  What Standards Do We Need2

Here's a check-list for missing standards or standards which need

1.  A stronger, more detailed unit testing standard.

2.  Comparable standard for integration testing.

3.  System testing standard and subsidiary standards for areas
within system testing such as security, recovery.

4.  Test configuration control and reporting.

5.  Quantifiable metrics for software quality.

6.  Acceptance criteria and process.

7.  Test documentation and audit.

8.  All kinds of standards for all kinds of cover.

Work continues to be done within the standards community on all of
the above.  But there are problems ranging from pure research to
politics that will take a big army of competent workers a long time
to resolve.

4.  Solutions and Challenges

4.1.  Overview

The solution is multi-dimensional: hardware, operating system,
language, language processor, statistics, tools, standards, and
training.  We divide these into what can be done by the system
supplier, within your own shop, and as a community.

4.2.  Help the Supplier.

No supplier of hardware or software can make significant capital
investments in products if there's no perception of a market.

1.  Establish a dialogue through vendor marketing contacts and user
groups.  Share.  Make your needs known in writing.

2.  Prepare draft functional specifications for hardware, operating
system, language, language processor, and tools features which
 test development and execution.  Don't grumble: publish your wish

3.  Be willing to pay a fair price for value.  Support your local
tool vendor.

4.  Indicate your willingness to pay for tool usage training.

5.  Indicate your willingness to buy services where appropriate.

4.3.  Internal Measures

1.  Wage the good fight for legitimacy.

2.  Get a budget for tools.

3.  Get a bigger budget for tools training.

4.  Implement a robust metrics program.

5.  Break down corporate barriers to sharing effectiveness

6.  Adopt the consensus terminology.

7.  Get a budget for internal standards development.

8.  Adopt the official standards (draft or final) as minimums.

9.  Get support for community activities.

10.  Educate the lawyers, marketeers, and PR types.

4.4.  Community Participation

1.  Join and foster test trade associations and special interest

2.  Understand the standardization process, support it, actively
contribute to it rather than being passive.

3.  Do PR work to disabuse users and especially the media of the
perfect software myth.

4.  Sacrifice short-term, local, interests to long-term, community


Excellence can be attained if you....

* Care more than others think is wise
* Risk more than others think is safe
* Dream more than others think is practical
* Expect more than others think is possible


                    New Yahoo! Group for eValid

To make it easier for all of the eValid users to communicate with
each other about eValid we have set up a new Yahoo! Group for

                     eValid Yahoo! Group Goals

The aim of this group is to have an UN-moderated open forum for
eValid users to discuss technical questions and issues.

We don't wish to have specific control of what is said; we mainly
want to have ALL eValid users have a place where they can come to
get current information, post problems, and study prior issues.

This is NOT an official eValid group.  However, from time to time we
here at eValid will respond to users questions and make other
postings.  When we do that we will be speaking officially for and
about eValid and we will identify ourselves appropriately.

Also, from time to time we will post individual responses to
problems and issues.  In doing this we will be very careful to
protect the identify of the originator of the issue.

We hope that this new open form of communication helps eValid users

              Finding The New Yahoo! Group for eValid

The simplest route to the new Yahoo! Group for eValid is the direct

Go to <> and click on Groups.  Then click on
"Computers & Internet", then "Software", then "Development", then
"Testing", and then click on "evalid".

You may find it quicker to go directly to <>
and then do a search for "eValid".

                Subscribing, Unsubscribing, Posting

Send email to to subscribe, to to unsubscribe.

Anyone can post messages to  You don't have
to be a member to read the postings and the archive material.

                      Software Research, Inc.
                         eValid Division,
                  1663 Mission Street, Suite  400
                   San Francisco, CA  94103  USA

                      Phone: +1 415.861.2800.
                       FAX: +1 415.861.9801.


                    ISSTA 2002 Technical Program

The just-concluced ISSTA 2002 workshop in Rome, Italy, presented a
number of very good papers.  The complete technical program and many
of the detailed slide presentations are available at:


While all of the ISSTA presentations are quite strong, QTN readers
who are interested in practical aspects of software quality should
see these papers in particular:

  * Ostrand and Weyuker, "The Distribution of Faults in a Large
    Industrial Softawre System"

  * Srivastava and Thiagarajan, "Effectively Prioritzing Tests in a
    Development Environment"

  * Moors, Veeraghavan, Tao, Zheng, and Badri, "Experiences in
    Automating Testing of SS7 Signalling Transfer Points"

  * Dick Hamlet, "Continuity in Software Systems"


  ICSE 2003: 25th International Conference on Software Engineering
    The Hilton Portland Hotel, Portland, Oregon, May 3-10, 2003


ICSE is the premier software engineering conference. It provides a
forum for researchers, practitioners, and educators to present and
discuss the most recent advances, trends, and concerns. Items of
special interest to software engineering practioners are marked (*).

Technical Papers: due Sept. 9, 2002. Technical papers should
describe innovative and significant work in the research or practice
of software engineering.  Papers will be evaluated by the Program
Committee on the basis of originality, importance of contribution,
soundness, evaluation, quality of presentation, and appropriate
comparison to related work.

Experience Reports: due Oct. 4, 2002.  Experience reports provide
in-depth description of experiences in building, using and evolving
software systems or processes.

Software Engineering Education & Training Papers: due Oct. 4, 2002.
This track provides an international forum for discussing topics
related to software engineering education and training.

Tutorial Proposals: due Oct. 4, 2002.  Tutorials are short courses
on software engineering practices, techniques, and theories.
Tutorials can cover a wide range of topics, from practical
techniques, guidelines, standards, and surveys, to theoretical


                           Quality Is...

            "Quality is never an accident; it is always
           the result of high intention, sincere effort,
           intelligent direction and skillful execution;
        it represents the wise choice of many alternatives."


                             CSES 2002
 International Workshop on Certification and Security in E-Services
                         Montreal, Canada


The program of the CSES-02 workshop features five sessions,
comprising overall four invited speakers (well known experts in
issues regarding e-services) plus five contributed full papers and
three contributed short papers, selected by the international
program committe on the basis of their scientific quality and
relevance for the workshop topics.

                   Aims and Scope of the Workshop

Certifying the execution of an e-service provided on the network as
the result of the interaction among independent organizations is a
critical area for the underlying IT-infrastructure.  In fact, given
the legal value that is often attached to data managed and exchanged
during the execution of such an inter-organizational e-service,
being able to document what was actually carried out is of the
utmost importance. This is made more complex in cases, like it often
happens in the public administration sector, where e-services are
based on legacy systems managed by autonomous and independent

Additionally, the whole area of security issues, from the more basic
ones (availability, authentication, integrity, confidentiality) to
the more complex ones (e.g., authorization, non-repudiation) is an
equally critical aspect to be able to trace down responsibilities
("who did what").  This capability is mandatory to increase the
presence and the use of e-service IT-infrastructures.

The two areas have moreover a common technological intersection,
since both are based on the reliable and efficient monitoring of
executed and running processes. Certification and security are as
well fundamental processes in organizational and economic terms.

The objective of the workshop is to discuss technical and
organizational aspects regarding these two areas and their
interrelations, presenting both real-life application experiences
and methodological proposals, from participants belonging to the
governmental, industrial and academic communities.


The workshop is within the "Security" Stream of the IFIP-WCC 2002,
the 17th World Computer Congress of the IFIP. This is a uniquely
rich event featuring 10 distinct Streams on key issues in
Information Technology.  The "Security" Stream features also one
tutorial "Introduction to Computer Security" and one more Workshop
"E-Government and Security", thus providing even more opportunities
for discussions about security issues in IT-infrastructures in our
increasingly digital world.


                  Edsger Wybe Dijkstra: 1930-2002

    A Personal Note:  My first meeting with Prof. Dijkstra was
    at THE in Eindhoven, Netherlands, in the early 1970's, not
    too long after his "GOTO Statement Considered Harmful"
    article was published and fomented the Structured
    Programming Revolution.  I was eager and enthusiastic and
    had wanted to sit at the feet of the master, and he gave of
    his time generously.  To this day I recall him speaking in
    English ever so carefully and precisely and pointing out why
    programming languages had difficulty dealing consistently
    with the semantics of variables.  I didn't then understand
    all the implications fully, and even now today I'm not
    completely sure of everything that he had in mind.

    That is the nature of a guru: his thinking is already beyond
    what you currently can appreciate.  But, like all that he
    did, his answers and observations were profound and entirely
    thought provoking.  In all the times I saw him since my
    impressions were colored by that very first meeting:
    calmness, reason, care, politeness, and clarity.  His
    elegant mind will surely be missed.  -Edward Miller

Professor Edsger Wybe Dijkstra, a noted pioneer of the science and
industry of computing, died after a long struggle with cancer on 6
August 2002 at his home in Nuenen, the Netherlands.

Dijkstra was born in 1930 in Rotterdam, The Netherlands, the son of
a chemist father and a mathematician mother.  He graduated from the
Gymnasium Erasmianum in Rotterdam and obtained degrees in
mathematics and theoretical physics from the University of Leyden
and a Ph.D. in computing science from the University of Amsterdam.
He worked as a programmer at the Mathematisch Centrum, Amsterdam,
1952-62; was professor of mathematics, Eindhoven University of
Technology, 1962-1984; and was a Burroughs Corporation research
fellow, 1973-1984. He held the Schlumberger Centennial Chair in
Computing Sciences at the University of Texas at Austin, 1984-1999,
and retired as Professor Emeritus in 1999.

Dijkstra is survived by his wife of over forty years, Maria (Ria) C.
Dijkstra Debets, by three children, Marcus J., Femke E., and
computer scientist Rutger M. Dijkstra, and by two grandchildren.

Dijkstra was the 1972 recipient of the ACM Turing Award, often
viewed as the Nobel Prize for computing.  He was a member of the
Netherlands Royal Academy of Arts and Sciences, a member of the
American Academy of Arts and Sciences, and a Distinguished Fellow of
the British Computer Society. He received the 1974 AFIPS Harry Goode
Award, the 1982 IEEE Computer Pioneer Award, and the 1989 ACM SIGCSE
Award for Outstanding Contributions to Computer Science Education.
Athens University of Economics awarded him an honorary doctorate in
2001.  In 2002, the C&C Foundation of Japan recognized Dijkstra "for
his pioneering contributions to the establishment of the scientific
basis for computer software through creative research in basic
software theory, algorithm theory, structured programming, and

Dijkstra is renowned for the insight that mathematical logic is and
must be the basis for sensible computer program construction and for
his contributions to mathematical methodology. He is responsible for
the idea of building operating systems as explicitly synchronized
sequential processes, for the formal development of computer
programs, and for the intellectual foundations for the disciplined
control of nondeterminacy. He is well known for his amazingly
efficient shortest path algorithm and for having designed and coded
the first Algol 60 compiler.  He was famously the leader in the
abolition of the GOTO statement from programming.

Dijkstra was a prodigious writer.  His entire collection of over
thirteen hundred written works was digitally scanned and is
accessible at

He also corresponded regularly with hundreds of friends and
colleagues over the years --not by email but by conventional post.
He strenuously preferred the fountain pen to the computer in
producing his scholarly output and letters.

Dijkstra was notorious for his wit, eloquence, and way with words,
such as in his remark "The question of whether computers can think
is like the question of whether submarines can swim"; his advice to
a promising researcher, who asked how to select a topic for
research: "Do only what only you can do"; and his remark in his
Turing Award lecture "In their capacity as a tool, computers will be
but a ripple on the surface of our culture. In their capacity as
intellectual challenge, they are without precedent in the cultural
history of mankind."

Dijkstra enriched the language of computing with many concepts and
phrases, such as structured programming, separation of concerns,
synchronization, deadly embrace, dining philosophers, weakest
precondition, guarded command, the excluded miracle, and the famous
"semaphores" for controlling computer processes. The Oxford English
Dictionary cites his use of the words "vector" and "stack" in a
computing context.

Dijkstra enjoyed playing Mozart for his friends on his Boesendorfer
piano. He and his wife had a fondness for exploring state and
national parks in their Volkswagen bus, dubbed the Touring Machine,
in which he wrote many technical papers.

Throughout his scientific career, Dijkstra formulated and pursued
the highest academic ideals of scientific rigor untainted by
commercial, managerial, or political considerations. Simplicity,
beauty, and eloquence were his hallmarks, and his uncompromising
insistence on elegance in programming and mathematics was an
inspiration to thousands. He judged his own work by the highest
standards and set a continuing challenge to his many friends to do
the same. For the rest, he willingly undertook the role of Socrates,
that of a gadfly to society, repeatedly goading his native and his
adoptive country by remarking on the mistakes inherent in
fashionable ideas and the dangers of time-serving compromises. Like
Socrates, his most significant legacy is to those who engaged with
him in small group discussions or scientific correspondence about
half-formulated ideas and emerging discoveries.  Particularly
privileged are those who attended his reading groups in Eindhoven
and Austin, known as the "Tuesday Afternoon Clubs".

At Dijkstra's passage, let us recall Phaedo's parting remark about
Socrates: "we may truly say that of all the men of his time whom we
have known, he was the wisest and justest and best."

    ------------>>> QTN ARTICLE SUBMITTAL POLICY <<<------------

QTN is E-mailed around the middle of each month to over 10,000
subscribers worldwide.  To have your event listed in an upcoming
issue E-mail a complete description and full details of your Call
for Papers or Call for Participation to .

QTN's submittal policy is:

o Submission deadlines indicated in "Calls for Papers" should
  provide at least a 1-month lead time from the QTN issue date.  For
  example, submission deadlines for "Calls for Papers" in the March
  issue of QTN On-Line should be for April and beyond.
o Length of submitted non-calendar items should not exceed 350 lines
  (about four pages).  Longer articles are OK but may be serialized.
o Length of submitted calendar items should not exceed 60 lines.
o Publication of submitted items is determined by Software Research,
  Inc., and may be edited for style and content as necessary.

DISCLAIMER:  Articles and items appearing in QTN represent the
opinions of their authors or submitters; QTN disclaims any
responsibility for their content.

STW/Regression, STW/Coverage, STW/Advisor, TCAT, and the SR logo are
trademarks or registered trademarks of Software Research, Inc. All
other systems are either trademarks or registered trademarks of
their respective companies.

        -------->>> QTN SUBSCRIPTION INFORMATION <<<--------

To SUBSCRIBE to QTN, to UNSUBSCRIBE a current subscription, to
CHANGE an address (an UNSUBSCRIBE and a SUBSCRIBE combined) please
use the convenient Subscribe/Unsubscribe facility at:


As a backup you may send Email direct to  as follows:

   TO SUBSCRIBE: Include this phrase in the body of your message:

   TO UNSUBSCRIBE: Include this phrase in the body of your message:

Please, when using either method to subscribe or unsubscribe, type
the  exactly and completely.  Requests to unsubscribe
that do not match an email address on the subscriber list are

	       Software Research, Inc.
	       1663 Mission Street, Suite 400
	       San Francisco, CA  94103  USA
	       Phone:     +1 (415) 861-2800
	       Toll Free: +1 (800) 942-SOFT (USA Only)
	       Fax:       +1 (415) 861-9801
	       Web:       <>