HDTenEightyP/NetNews huggingface dataset:
Newsgroups: bit.listserv.notis-l
Date:         Tue, 28 Jul 1992 11:10:52 CDT
Comments:     Resent-From: HSAMUELS@UA1VM
Comments:     Originally-From: Barbara <BAUGHMAN@UTDALLAS.BITNET>
From:         HSAMUELS@UA1VM.BITNET
Subject:      Re: PPQ5555:no fix for recall fine problem
              27 Jul 1992 11:31:26 PDT from <LSYS1@UVVM.UVIC.CA>

I am in complete agreement with the following message.  I think it would be
most appropriate for NOTIS to make an official statement to the entire
NOTIS user community describing how they intend to respond to the various
circulation problems which have been introduced in LMS 5.0.2.

Harry Samuels
Programmer/Analyst (TECH 1)
University of Alabama
Bitnet: HSAMUELS@UA1VM
Internet: HSAMUELS@UA1VM.UA.EDU
Voice: (205) 348-2877
Fax: (205) 348-9170
----------------------------Original message----------------------------
I would like someone from NSI to respond officially to the note from
Kathleen Matthews.  The 5.0.2 circulation module is full of things that
don't work any more.  I has been my impression also that NSI does not
intend to provide any support for the circulation module (or very
little support) because of the 5.2 rewrite.  I, too, am incredulous at
this stand.  Does NSI truly expect its customers to go from a working
circulation module to a non-working circulation module and stay there
for years until they can release a 'rewrite'?  And what new problems
will the rewrite introduce?

To make things worse, the things that are wrong with the circulation
module all seem to be high-profile mistakes that make our own customers
scream.  The due dates are sometimes wrong, the fines are not calculated
properly, overdue notices and bills are not sent out as advertised.  We
are pulling our hair out.  If NSI can't get us a working version of the
circulation module with 5.1 (or 5.1.1), then I don't want anything to
do with 5.2.

The cause of our problems is not the programming or system design staff.
It doesn't bother me at all that they make some mistakes.  Thats life in
computerland.  The problem is a policy that states that once a release is
out the door, there will be no fixes to that release unless NSI thinks it's
serious enough.  This is especially true of modules that are targetted for
a rewrite.  With this philosophy, NSI customers will NEVER have a release
that really works like it's supposed to.  It's always going to be in the next
release or the next rewrite.  In a way, I see their logic in holding to this
philosophy.  It isn't an arbitrary decision and was made with the sincere
belief that this policy would best serve their customers.  I just don't
agree with it.

So how about it NSI?  What's the official word on fixes for the circulation
module?

Barbara Baughman
TECH1
University of Texas at Dallas
(214) 690-2157
BAUGHMAN@UTDALLAS.BITNET
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.notis-l
Date:         Mon, 27 Jul 1992 15:00:29 EDT
From:         Irene Pelak <pelak@PILOT.NJIN.NET>
Subject:      Archives in Sender Order

I just searched the archives trying to find some recent articles I remeber
seeing about renewing overdue items and the resultant problem with notices
being generated for items not yet due. (I could use the problem tracking
number for that one.)  I noticed that the articles satisfying my search were
presented in alphic order by sender.  I think I used to get them in ord
reverse order by date (latest first).  I like the date order better.  Can I
qualify my search to get the hits by date?
IRENE PELAK  TECH1  BERGEN COMMUNITY COLLEGE  201-447-9236
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.notis-l
Date:         Mon, 27 Jul 1992 08:30:00 CDT
From:         "Gene Getchell 319/335-6300,6354" <ADPEMGTS@UIAMVS.BITNET>
Subject:      Re: diacritics and volume holdings

In response to the message copied below:
NOTIS translates bibliographic, authorities and MARC Holdings records by
tables which correctly handle most diacritics and special characters.  Other
record types, including copy holdings, volume holdings and order records
neither protect you from entering such characters nor translate them for
for display.  Thus diacritics and special characters which you enter in
Volume Holdings records will not be translated at data entry, will be stored
as the wrong character codes in the records, will display as garbage and will
be mis-translated to display wrongly after the records have been converted to
MARC Holdings.  Sorry 'bout that.
                             Gene Getchell
                             NOTIS Tech I
                             University of Iowa

> We are experiencing a problem with diacritics displaying properly in
> volume holdings records, even though they *DO* display correctly in the
> same bib. record.  Unfortunately, we are unable to tell whether this
> problem has always been the case.  We are just now in the midst of a
> serials RECON project and the number of slavic etc. serials we would
> previously have had in our OPAC is small.
>
> Can anyone help?  It sounds as though it's simply a matter of a "switch"
> being shut off (I hope!!).  We are at version 5.0.1 and are still in
> volume holdings records.  We use "Supersession" as the campus applications
> gateway and use a 7171 controller.
>
> I should add that the vhld diacritics display problem is only with the
> OPAC side, not staff side.  We're using IBM 3164/63 stations for
> diacritics display with the appropriate 860/861 cartridge for staff/OPAC
> side display.
>
> Thank you in advance.
>
> Sheila Pepper
> ----------------------
> Applied Systems & Instructional Services Librarian
> McMaster University Library
> (416) 525-9140 ext. 3883
> e-mail: pepper@mcmail.cis.mcmaster.ca
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.notis-l
Date:         Thu, 30 Jul 1992 14:53:03 PDT
From:         Marlene Elster <9118MRE@UCSBVM.BITNET>
Subject:      Fix for override due date -- PPQ6108

I have received a fix for the override due date problem.  NSI has asked us
to test the code changes

NSI has asked us to test their fix for the override due date problem.  So
far I only have it in test.  I have checked the action index records for
several different kinds of charges -- override, renew, normal -- and all
looks well.  We have yet to test notice creation.  As soon as we're
satisfied, I will let NSI and all of you know that everything is OK.

Marlene Elster, TECH1
University of California, Santa Barbara
(805) 893-3909
9118MRE@UCSBVM.BITNET
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.notis-l
Date:         Thu, 30 Jul 1992 08:06:55 CDT
From:         HSAMUELS@UA1VM.BITNET
Subject:      4xx Refs. Fixed (Coreection)

This message pertains to fixes to LPC140P that the University of Alabama
broadcast last week.  There were two typos in the statement that is two
lines above the label IXSUBGO.  The statement was given as:
         CLI   DSICSLC,2(R2)       IS THIS RIGHT SUBJECT SYSTEM?

It should be:
         CLC   DSIXSLC,2(R2)       IS THIS RIGHT SUBJECT SYSTEM?

Sorry for any inconvenience,
Harry Samuels
Programmer/Analyst (TECH 1)
University of Alabama
Bitnet: HSAMUELS@UA1VM
Internet: HSAMUELS@UA1VM.UA.EDU
Voice: (205) 348-2877
Fax: (205) 348-9170
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.notis-l
Date:         Wed, 22 Jul 1992 07:02:14 EDT
From:         "Wm. H. Shrout, III" <KLIWHS@UKCC.UKY.EDU>
Subject:      Donors on NOTIS-- Thanks!
Comments: To: autocat@uvmvm.BITNET, notis-l@tcsvm.BITNET

I'd like to take this opportunity to thank all the people who responded to
our query about handling donor/honoree information in our OPAC here at the
University of Kentucky.  Everyones' responses were very helpful!  It's always
encouraging to receive such a useful exchange of information using this
list-server technology!

I've compiled the responses into a file which I would be happy to mail to
any interested parties-- it's a bit lengthy to post directly.  Respond to
me (KLIWHS@UKCC.BITNET or KLIWHS@UKCC.UKY.EDU), and I'll mail out the file
right away!

Thanks again for all your help!

(P.S.--  We've decided to use the 590 field for our donor information!)

<<.>>--------------------------->>.<<---------------------------<<.>>
  :       Wm. Shrout, Technician, On-Line Cataloging Unit         :
  :           M.I.King Library - University of Kentucky           :
  :                      KLIWHS@UKCC.UKY.EDU                      :
<<.>>--------------------------->>.<<---------------------------<<.>>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Subject: (no subject given)
Newsgroups: bit.listserv.notis-l
Date:         Wed, 29 Jul 1992 16:46:57 PDT
From:         "Kathleen Matthews" <LSYS1@UVVM.UVIC.CA>

SET NOTIS-L REPRO

**********************************************************************
KATHLEEN WEBSTER MATTHEWS (LSYS1@UVVM.UVIC.CA)
Systems Librarian, McPherson Library
UNIVERSITY OF VICTORIA, VICTORIA, B.C., CANADA.
(604) 721-8219
**********************************************************************
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Southern Methodist University
Newsgroups: bit.listserv.notis-l
Date:         Tue, 28 Jul 1992 17:05:25 CST
From:         "Michael J. Stephens" <VB7R0007@SMUVM1.BITNET>
Subject:      Re: NOTIS AND Z39.50
              28 Jul 1992 11:13:22 CDT from <notis@TWAIN.NOTIS.COM>

On Tue, 28 Jul 1992 11:13:22 CDT Notis General ID said:
>THIS IS AN OFFICIAL NOTIS COMMUNICATIONS - DUE TO TECHNICAL PROBLEMS THIS NEVER
>REACHED NOTIS-L
>
>NOTIS Demonstrates Full Z39.50 Inter-operability!
>
>On June 4, 1992, NOTIS demonstrated full NISO Z39.50 inter-operability with the
>Coalition for Networked Information (CNI) test bed site at the University of
>California Department of Library Automation. As part of the test the NOTIS
>client exchanged standard Z39.50 protocol elements with the DLA server and
>performed several inter-system searches. Since that time NOTIS has expanded
>its test to include servers from OCLC, AT&T, UC Berkely, Penn State and MIT.
>
>NOTIS is the first library vender to provide Z39.50 inter-system searching as
>standard product offerings. Z39.50 support is included in the PACLink product,
>InfoBase-- a Z39.50 database server, and ProPAC a Z39.50 graphical client.
>
>The NOTIS PACLink product is installed at our four co-development SUNY
> Stonybrook.
>
>For more information on PACLink contact NOTIS Systems at 708-866-0150.
>
>Thank you in advance
>Cheryl Wallace
>Customer Support Services
>Support Center Administrator

Cheryl, was this demonstrated with the plain vanilla LMS or was PACLink
required.  Also, I have only received sketchy information about InfoBase.
When is more info going to be available?


Michael J. Stephens, Tech1
Sr. Systems Analyst II           *  Phone:    (214) 692-3453
Computer & Information Services  *  FAX:      (214) 692-3449
Southern Methodist University    *  Bitnet:   vb7r0007@smuvm1
Dallas, Tx. 75275-0262           *  Internet: vb7r0007@vm.cis.smu.edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL0]
Newsgroups: bit.listserv.notis-l
Date:         Tue, 28 Jul 1992 11:24:03 CDT
From:         Notis General ID <notis@TWAIN.NOTIS.COM>
Subject:      5.1 OPAC CHANGES (SCREEN)

THIS IS AN OFFICIAL NOTIS COMMUNICATION - DUE TO TECHNICAL PROBLEMS THIS NEVER
 REACHED NOTIS-L

You can now begin to prepare for Release 5.1. The footers in OPAC will be
standardized in this next release (see NOTISes January 1992 p.8-9), providing
 users with consistent commands and support of the NISO Common command language.
  To prepare for this standardization, you will need to evaluate the EXPLAIN,
 HELP, and OTHER informational screens to determine how the upcoming 5.1 changes
 will effect your site's screens.

All screens will be 15 lines long except where a longer command line is
 necessary.  For those screens, the length will be 13 lines long.  This will
 allow for two additional command input lines.

Which screens will change effect? All of the EXPLAIN and OTHER informational
 screens with the exception of the EXPLAIN KEYWORD and SET CATALOT PANEL (which
 is a
new 5.1 screen), will have 15 lines.  The EXPLAIN KEYWORD and SET CATALOG PANEL,
 as well as the REVIEW help screen will be 13 lines.

Release 5.1 conversion will delete any of the lines beyond than the 15th or
 13th.  Because of this, NOTIS recommends thay you begin reviewing the current
 screens that you are using in your production modules. Changes may need to be
 made in
anticipation of the 5.1 conversion.  This will alleviate losing information on
 the screens when they are shortened during conversion.

To maintain consistency throughout the database, the REVIEW PANEL wording will
 be deleted from the current review screen.  Patrons having difficulty with a
 search will use a HELP screen.  The wording on your 5.0 REVIEW PANEL screen can
 be moved to the REVIEW HELP screen.

By reviewing your EXPLAIN, OTHER informational, and HELP screens now you can
 determine if the current wording needs to be changed or if additional pages
 will be required.  Prepare not to alleviate any lost screen data in Release
 5.1.

NOTIS SYSTEMS, INC.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: NOTIS-L@TCSVM.BITNET
X-VMS-To: IN%"NOTIS-L@TCSVM.BITNET"
Newsgroups: bit.listserv.notis-l
Date:         Wed, 29 Jul 1992 10:39:00 EST
From:         "W.C. DIVENS" <N93774@PITTVMS.BITNET>
Subject:      Re: CHAT-L: NOT AN OFFICIAL NOTIS COMMUNICATION

Or 'Prepare to be prepared not to use the enhancements we prepared
        for you"?

RB
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Indiana University Music Library
X-Acknowledge-To: <PAPAKHI@IUBVM>
Newsgroups: bit.listserv.notis-l
Date:         Thu, 23 Jul 1992 12:54:02 EST
From:         "A. Ralph Papakhian" <PAPAKHI@IUBVM.BITNET>
Subject:      Re: Resolved: NOTIS via INTERNET

On Thu, 23 Jul 1992 12:33:58 LCL Bob Jones said:
>Thanks for the responses!  I just received word from twain.notis.com
>that my re-sent message has been delivered.
>
>Apparently the twain.notis.com mail server is case sensitive, and the
>notis userid MUST be in lower case.  I use RiceMail and use the CMS
>NAMES file extensively.  I had to force the names file to leave the
>userid in lower case.  So, update your records and tuck this tidbit
>away: NOTIS, INC.  can be reached at
>
>notis@twain.notis.com     -or-   notis@TWAIN.NOTIS.COM
>The 'notis' userid must be in lower case.
>
>Some of you also suggested that if your NAMES file gives you problems,
>try addressing mail manually, varying the capitalization.
>Thanks again for the helpful responses.
>
>Bob Jones, UNF Library
>Jacksonville, Florida

This sounds like another little improvement from that operating
system of the future.

Most cordially,
A. Ralph Papakhian, Music Library (Co-Listowner for MLA-L@IUBVM)
Indiana University, Bloomington, IN 47405
(812) 855-2970  papakhi@iubvm.bitnet papakhi@iubvm.ucs.indiana.edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: notis-l@TCSVM.BITNET
Newsgroups: bit.listserv.notis-l
Date:         Fri, 24 Jul 1992 13:11:03 -0400
From:         Sheila Pepper <pepper@MCMAIL.CIS.MCMASTER.CA>
Subject:      diacritics and volume holdings

We are experiencing a problem with diacritics displaying properly in
volume holdings records, even though they *DO* display correctly in the
same bib. record.  Unfortunately, we are unable to tell whether this
problem has always been the case.  We are just now in the midst of a
serials RECON project and the number of slavic etc. serials we would
previously have had in our OPAC is small.

Can anyone help?  It sounds as though it's simply a matter of a "switch"
being shut off (I hope!!).  We are at version 5.0.1 and are still in
volume holdings records.  We use "Supersession" as the campus applications
gateway and use a 7171 controller.

I should add that the vhld diacritics display problem is only with the
OPAC side, not staff side.  We're using IBM 3164/63 stations for
diacritics display with the appropriate 860/861 cartridge for staff/OPAC
side display.

Thank you in advance.

Sheila Pepper
----------------------
Applied Systems & Instructional Services Librarian
McMaster University Library
(416) 525-9140 ext. 3883
e-mail: pepper@mcmail.cis.mcmaster.ca
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.notis-l
Date:         Tue, 21 Jul 1992 12:39:18 CDT
From:         SMUIR@UA1VM.BITNET
Subject:      Re: Enhancement Process - Clarification Requested
              21 Jul 1992 09:36:14 EST from <FWHITE@UCC.UWINDSOR.CA>

I am responding as chair of the LIB1 SIG.
The LIB1 SIG was responsible for any LIB1 requests and also GTO requests.

I solicited requests for GTO from the LIB1, Catalog\Authorities, and
Acquisitions SIGs.  Additionally I reviewed last year's ballot and included
any items not already on the ballot.

The LIB1 ballot mainly consists of requests relating to LSYS and LMST,
although other items crossing a number of areas are also included.  I
solicited suggestions from LIB1's as well as extracting LIB1 sponsored
enhancements from last year's ballot.

E-mail ballots were sent out over the LIB1 listserv (closed membership to
LIB1's only) and snail-mail ballots were mailed to LIB1's who do not
use e-mail.  The LIB1 membership is comprised of anyone who has attended
a LIB1 meeting, is listed as the LIB1 in the NOTIS directory, and
has requested to be kept informed of mailing and activites.

Additionally, copies of the GTO ballot were sent to the chairs of the
Catalog/Authorities and Acquisitions SIGs.  Distribution of the GTO
ballot to their membership is at the chair's discretion.  Those individuals
who are interested in specific enhancements for GTO should share their
concerns with their LIB1.

The GTO ballot consisted of 12 enhancements and must be pared down to 5, the
LIB1 ballot must pare 15 enhancements to 10.  After this preliminary voting the
 finalists will be sent to NOTIS Systems, Inc. for the final ballot.  The
final ballot is distributed to the LIB1's.

Each site makes its own decisions on how to select the items which
will receive votes.  There really is not a way for NOTIS Systems, Inc.
to tell sites how to conduct their voting.  If you have specific concerns
I would encourage you to first discuss this with your department head,
and if you are a department head, then talk with your sites LIB1.  Nothing
in this comment should be construed as encouragment to fail to follow the
appropriate chain of communication at your site.

If anyone has further questions about the LIB1 or GTO ballot, please send them
directly to me, to avoid clutter on the list, and I will respond as quickly
as possible.

********************************
*  SCOTT P. MUIR               *
*  THE UNIVERSITY OF ALABAMA   *
*  SMUIR@UA1VM                 *
*  SMUIR@UA1VM.UA.EDU          *
*  (205) 348-2299              *
********************************
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.notis-l
Date:         Wed, 29 Jul 1992 11:04:25 CDT
From:         "Anne L. Highsmith (409-845-8111)" <K026AH@TAMVM1.BITNET>
Subject:      Re: 5.1 OPAC CHANGES (SCREEN)
              28 Jul 1992 11:24:03 CDT from <notis@TWAIN.NOTIS.COM>

Having read NOTIS' official communique about needed screen changes due
to screen length, I am confused and look to my colleagues for
clarification (how's that for assonance?). I just went into a few OPAC
and MDAS screens, using the LSYS and MSYS commands. The screen
templates offer ONLY 15 lines. How is it physically possible to
have any screens which are long enough to need changing, except in
those cases where the screen has to be cut to 13 lines?

Anne Highsmith
NOTIS Coordinator
Texas A&M U.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Purdue University Libraries
Newsgroups: bit.listserv.notis-l
Date:         Fri, 31 Jul 1992 11:09:33 EST
From:         Alan Alexander-Manifold <ALANAM@PURCCVM.BITNET>
Subject:      CHAT: Circulation breakdown (poem)

The recent problems with circulation inspired me to write this bit of doggerel.


Circulation Breakdown
Alan Alexander-Manifold,  7/31/92

My overdues are spewing out
   For books not even due,
And NOTIS says that they don't care;
   I think I'll have to sue.

Each recall either screws me up
   Or doesn't work at all,
I've called it in, but NOTIS folks
   Just won't return my call.

I know that if I hack the code,
   I risk losing support,
But every day my bills and fines
   Come up a big chunk short.

So now what am I going to do?
   My NOTIS CPU
Won't run GEAC or DRA;
   I can't wait for 5.2.

I'll take the one route that will make
   The future look less bleak:
I'm heading for the Outer Banks--
   I'll see you in a week!

                                                         \
       --Alan Alexander-Manifold               THe Online Resource
         Systems Implementation Manager        TTTTTTTTTTTTTTTTTTT
         Information Technology Department       T         //
         Purdue University Libraries             T  H H  OOO  RRR
         West Lafayette, Indiana   47907         T  HHH//O O  RRR
         (317) 494-2857    FAX: 494-9007         T  H/H  OOO  R R
         alanam@purccvm          (BITNET)           \\
         alanam@vm.cc.purdue.edu (Internet)           \
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.notis-l
Date:         Fri, 24 Jul 1992 15:08:49 CDT
From:         Barbara <BAUGHMAN@UTDALLAS.BITNET>
Subject:      Re: New Circ Notice Problem
              24 Jul 1992 15:48:32 EDT from <pelak@PILOT.NJIN.NET>

We have noticed this problem here, also.  It seems that the notices are
always scheduled based on the due date from the applicable circulation
policy and the program never bothers to look at the actual due date!

UTD has reported this happening when the due date is overridden.  I think
this is another variation on the same problem.  Please report it to NSI.
Last I heard from NSI it had a high priority for being fixed.

Barbara Baughman
TECH1
University of Texas at Dallas
(214) 690-2157
BAUGHMAN@UTDALLAS.BITNET
Newsgroups: bit.listserv.notis-l
From: jlc5f@poe.acc.Virginia.EDU (Jean L. Cooper)
Subject: work unit security
Organization: University of Virginia
Date: Mon, 27 Jul 1992 13:23:34 GMT

In the LSYS Enhancement Ballot that was distributed to LIB1s
last week, one of the proposed enhancements is:

LSYS Work Unit Security--"Currently, to give access to check in
(R statements) one must also give access to create vendor and order
scope.  This defeats the purpose of restricting access."

Maybe I'm on the wrong track here, but I think I've found a
way around this.  When giving access only to M,N,R statements,
I totally delete any Default OrdUnit Code.  For some reason,
this allows me to put "N" in the vendor and order scope fields.
It seems odd to me that the Default OrdUnit Code, the vendor,
order scope, and R statements are connected, but experimentation
is an incredible thing! <grin>

Jean L. Cooper
Assistant Systems Librarian
LIB2
University of Virginia
--
Jean L. Cooper    (BITNET: JLC5F@virginia.edu   CIS: 70253,1114)
"The true University of these days is a Collection of Books." 
                                           --Carlyle                        
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU