LISTSERV mailing list manager LISTSERV 16.0

Help for NLS-REPORTS Archives


NLS-REPORTS Archives

NLS-REPORTS Archives


NLS-REPORTS@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

NLS-REPORTS Home

NLS-REPORTS Home

NLS-REPORTS  April 1998,

NLS-REPORTS April 1998,

Subject:

Automation Report No. 98-02

From:

National Library Service for the Blind and Physically Handicapped <[log in to unmask]>

Reply-To:

NLS Documents for Network Libraries <[log in to unmask]>

Date:

Fri, 24 Apr 1998 15:11:25 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

 (346 lines)

Automation Report No. 98-02

Date: April 24, 1998

Subject: READS II

Data Management, the contractor for the Reader Enrollment
and Delivery System (READS), has delivered a beta-test
version of the new READS system, which we call READS II, to
the regional libraries in Frankfort, Kentucky, Atlanta,
Georgia, and Wayne, Michigan. This report is intended as a
planning tool for READS libraries and as general information
for other libraries that may be interested in the status of
READS development.

READS II has much that is different from READS and much that
is the same. A major difference can be seen in the user
interface, a graphical user interface (GUI) that
significantly changes the way the user navigates among and
through the various functions of READS. The user does not
directly see the changes to the underlying software platform
in which READS II is written, but will see the effects of
that change in a more reliable database, faster mail-card
runs, capabilities for larger databases and the like. What
has not changed is the basic set of functions carried out by
READS. READS II can do what READS now does and not much
more, in terms of user functions. It was decided at the
outset that, except in minor cases, the functionality was to
remain unchanged in order to limit the complexity of
development and to ensure a timely delivery of the new
system. That strategy appears to be working.

Some enhancements to the existing functionality have been
made in the course of the development of READS II, either
because they were requested, easy to do, and not
revolutionary, or because they came as part of the new
software platform. The mail-card function has perhaps the
greatest improvements. Aside from running much faster, it
allows the user to process all mail-cards and then back
specific cards (circulations) out of the process before or
after printing. If a print run of the mail-cards is stopped
for any reason, it can be started again at any card selected
by the user. And most significantly, a library can opt for
automatic checkout in which books are checked out in the
mail-card process rather than by "wanding" them out when the
mail-cards are inserted in the books. (Of course the
freedom from wanding out the books is not free. Specific
copies must be selected from the shelves and matched to the
mail-cards. That may or may not be a good tradeoff, but the
library now has the choice.) Reports run faster, can be
produced and reviewed online, and can be selectively printed
by page, etc. Users can tile windows to view multiple
screens, such as a book and a patron, together, and can cut
and paste across the tiled windows. E-mail is accessible
from within READS II so that a CMLS or BPHICS report can be
run and mailed without exiting the system. Users can now
display lists such as the "has-now" and "has-had" lists in
order by any field, including book number, date, and
circulation type.

The ability to accept book information from NLS for input to
READS II is under development. Its availability for this
first release is still in question. We are trying to have
it included in the June release, but we will go without it
in June if necessary and release it as soon thereafter as
possible.

The enhancements from the new software that improve
efficiency rather than function are more noticeable in what
does not happen than what does. There are far fewer long
running programs. The user should not see the database
failures and the need to regenerate indexes that are seen
today. And there is no inherent limitation on database
size. We think that means that larger libraries will be
able to use READS, though the idea will have to be
thoroughly tested before a commitment can be made. We will
be happy to work with any library to set up a thorough test
of READS II on a large user population.

_Installation Schedule_

The three libraries mentioned have begun the beta-test of
READS II. READS II system installations are scheduled to
begin in June. Please understand that this is the first
time we have released a total rewrite of READS. As with any
system, the challenges of system development could easily
cause the dates to change. With this release, we have only
minimal experience in determining how long installation and
configuration will take, on average, and no experience with
the more complicated network problems that may arise during
installation. Our scheduling is based solely on rough
estimates. Nevertheless, we will share with you our
thoughts on the schedule, and we trust that you will
understand any future adjustments.

We expect, in mid-June, to install READS II in three
libraries, over and above the three that are participating
in the beta-test. On July 1, we will add another six, then
six mid-July, and ten to fifteen per month after that. With
approximately ninety libraries on READS, we might be able to
finish by the end of 1998. That assumes that there are no
significant problems in any installations, and that all
libraries will be ready to convert to READS according to
this schedule. Both assumptions are highly unlikely, but
they give us a starting point for discussion.

_Hardware and Software Requirements_

In order for libraries to install READS II, they will need
to have hardware more powerful than that required for READS.
Some libraries are already running READS on hardware that
has the necessary power. Others will need to acquire it.
It is understood that not all libraries will be able to
complete the acquisition process by the end of 1998. We
expect to support READS for some reasonable period in
libraries that are not equipped to accept READS II. That
period is viewed not as a specific amount of time, but
rather as a decision point to be reached when only a few
libraries are still using READS. We will await that point
to determine the parameters of the decision.

As requested by the READS users group, READS II uses modern
software and runs on what today might be considered the
medium-to-high end of standard market PCs. READS II is
designed to operate under Windows 95, using Novell NetWare
as the network operating system. The READS PFAS database
system is replaced by Microsoft (MS) Access 97. READS II
will operate without a separate purchase of MS Access. It
is recommended that libraries purchase MS Access or Seagate
Crystal Reports for ad-hoc reports, replacing the dBase
reporting done today. READS II will use a graphical user
interface (GUI) instead of the tabular menus of READS. Be
assured that we will thoroughly test READS II to ensure that
it is accessible by blind staff.

It should be noted that the hardware requirement results
mostly from Windows 95. The following information is
intended for a technology specialist putting together the
specification for a hardware purchase. READS II and its
associated applications files occupy about 10 MB permanent
disk space on each workstation. In operation, READS II
requires a minimum of 50 MB free disk space for temporary
storage. It will run more efficiently at 100 MB. If a
library produced a lot of reports, saved multiple
generations of old mail-card files, or performed other such
space-consuming operations, the READS storage requirement
could go up to 200 MB or more. On the server, the database
varies by the size of the library, but it should be about
the same size as the current READS database, usually around
100 MB.

The minimum requirement represents a configuration capable
of running READS II. The minimum should be avoided because
the response time will be slow and the library will likely
have operational problems with READS and Windows 95
resulting from hardware running at maximum capacity. The
minimum level includes older hardware that may not be
available on the open market. We do not want to rule out
machines that may trickle down from other parts of a
library's organization.

The recommended configuration is one on which READS II
should run quite well, assuming minimal other coexisting
applications. That is not to say that READS II will be
problematic with other applications on the network. We just
cannot predict the combined requirements for READS and
applications that we know nothing about. The recommended
hardware is what we consider a "good" machine that would be
dedicated to READS, from what is available on the open
market today. The average market machine power (MHZ) and
size (MB/GB) increases at least every quarter. More power
and size in a machine never hurt. _We advise that you not
"buy down" from standard market levels in order to conform
to these recommendations._


----------------------------------------------------------
_Recommended _Server_ _Workstation_

Processor Pentium Pentium 166
                        266/300

RAM 64 MB 32 MB

Disk Storage 2 GB* 1 GB

Operating System NetWare 4.11 Windows 95
                        or Windows NT

Database n/a MS Access

        *The server hard drive should be either SCSI or
        IDE Ultra ATA.

----------------------------------------------------------
----------------------------------------------------------

_Minimum Server Workstation_

Processor Pentium 233 486/100

RAM 32 MB 16 MB

Disk Storage 1 GB* 1 GB

Operating System NetWare 3.12 Windows 95
                        or Windows NT

Database n/a MS Access

        *The server hard drive should be either SCSI or IDE
        Ultra ATA.

--------------------------------------------------------

The question of using Windows NT, rather than NetWare under
Windows 95, has been raised by several libraries. The
design and development of READS II were carried out under
NetWare and Windows 95, and that platform will be supported
by the READS hotline. The system has been demonstrated to
work under Windows NT. We will evaluate the extent to which
the hotline can support NT networking questions. The
hotline staff has expertise for troubleshooting NetWare
problems and will maintain that expertise. It may also gain
some level of expertise in NT, but we cannot maintain the
same level of expertise in both systems with the resources
available. At this point, any library choosing NT will need
sufficient in-house expertise to troubleshoot its own
networking problems.

_Network Library Hardware Selection Responsibilities_

At this complete rewrite of the READS software, it is
worthwhile to note a significant change in the NLS approach
to hardware selection for READS. When READS was first
released, personal computer workstations were rare in
network libraries and in most office settings. The staff of
the libraries had little or no experience with them. The
automation support staff in the READS libraries, if there
was any, was usually experienced only in mainframe
computing, not at the PC level. As a result, NLS and its
READS hotline were the source of the most basic information
on hardware acquisition and setup for the READS libraries.
They were very restrictive in the allowable hardware.

Today, there is a completely different environment. What is
rare is the network librarian without PC workstation
experience. Many libraries have automation staff setting
local standards for hardware selection, network
architecture, etc. The experience level in network
libraries is now such that it is pushing READS to broaden
its operating platform in a number of areas. At the same
time, informal standards in the hardware market are
resulting in a much wider range of equipment that can
support READS functions. Where we can, we are responding
positively to that expansion. The Token Ring network
architecture and the Windows NT network operating system are
examples of that expansion.

While giving network libraries greater flexibility in both
hardware and software selection, NLS is also giving the
libraries more responsibility in the testing, integration,
and maintenance of the products they select. The READS
hotline can maintain a depth of experience in only so many
specific products. The contractor maintains one or more
installed versions of READS with a small variety of hardware
peripherals. We cannot purchase and install one of every
printer, tape drive and network architecture that the READS
libraries have installed. We do not want to limit libraries
to only those products we have. Libraries are encouraged to
exercise flexibility in hardware and software selection to
the extent that they are sure they can support it. The
READS hotline will do its best to troubleshoot the problems
encountered, but can only go so far.

For libraries that do not feel they have sufficient
expertise with hardware and software, NLS will make
recommendations. Generally, we will recommend what is
installed with the READS contractor. That way, the hotline
staff can walk the librarian through problems using exactly
the same setup.

_Printers_

Printers for the mail-cards are getting to be an area of
hardware selection with the greatest flexibility. READS II
will work with a greater variety of printers than READS.
That is because the OCR-A font requirement can be handled by
Windows rather than by the printer hardware. With READS
4.4, the selection was already expanded to sheet-fed laser
printers and READS was opened to the use of barcodes in
place of OCR-A.

At the same time that flexibility is expanding, the ability
to standardize on printer models is becoming limited. The
PC printer market is so competitive it seems that models are
being replaced every year. All the models recommended for
READS in the past are now obsolete -- no longer
manufactured. That includes the Hewlett Packard LaserJet
3si, which was opened up to READS only last year. The
positive side of this rapid change is that the technology is
getting better faster. The negative side is that we cannot
gain sufficient experience with current models to assure you
of a selection that will stand the test of time.

Of the obsolete printer models that are in network libraries
and also with the READS contractor, we can only advise on
what the manufacturers have told us are replacement models.
The Epson LQ-2550 has been replaced by the Epson LQ-2170;
however, the 2170 does not support OCR-A and cannot be used
until READS II is up and running. The Tally 360 has been
replaced by the Tally T2060, though the T2045 might be fast
and sturdy enough for most network libraries. The Tally
printers are expensive, but they do have OCR-A fonts. We
have no information on Facit and C-Itoh/C-Tech. We are told
that the Epson LQ 2550s are still generally available from a
lot of vendors. If your current printer is dying and you
need a replacement before you move to READS II, that might
be an option. Be aware, though, that repair parts will be
harder and harder to get.

Laser printers are now a real option. The Output Technology
Laser Matrix 2400 pin-fed laser is expensive but very much
appreciated by the libraries that use it. There are also
libraries using the Hewlett Packard LaserJet 3si with
sheet-fed cards. That is another printer that is no longer
manufactured but is still available on the market. It has a
reputation of being a real workhorse. There are many other
laser printers on the market that will satisfy the needs of
network libraries. With the rapidly changing printer
market, the best advice we can give is to contact the READS
hotline for the latest advice on printer selection.

If you have any questions, please contact me at (202)
707-9313 or by e-mail at [log in to unmask] For further
technical guidance on hardware and software, you may call
the READS hotline at 1-800-57R-EADS (1-800-577-3237) or
by e-mail at [log in to unmask]




For more information contact:
Robert McDermott
Automation Officer

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
January 1998
December 1997
November 1997
October 1997
September 1997
August 1997
July 1997
June 1997
May 1997
April 1997
March 1997
February 1997
January 1997

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager