HDTenEightyP/NetNews huggingface dataset:
From: MARLENE@UCC.UWINDSOR.CA (Marlene Kemski, Univ. of Windsor)
Newsgroups: bit.listserv.notis-l
Subject: Re: LB610 Questions
Date: 13 Oct 92 19:46:48 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Comments: To: NOTIS discussion group list <NOTIS-L@VM.TCS.Tulane.EDU>
              13 Oct 1992 14:35:19 EDT from
              <pelak%PILOT.NJIN.NET@VM.TCS.Tulane.EDU>

Irene:

If you are running LB610 Option 6 for Bill and Fines, I believe no
updates are created.  Bill and Fine (JD) requests are placed in the
Journal when they occur.  Bill & Fine notices are issued once.

You may want to review  NOTIS'  Circulation Action and Journal Records
Processing documentation.  I'm not sure where it is suppose to be filed,
but I filed my copy after the indexes of the Internal Reference Manual.




************************************************************************
* Marlene Kemski                      *                                *
* Systems Analyst                     *   Releases:                    *
* Computing Services                  *              NOTIS LMS 5.0.2,  *
* University of Windsor               *              GTO       3.0,    *
*                                     *              CICS      1.7,    *
* Voice:  (519) 253-4232 x.2737       *              MVS/SP            *
* Fax  :  (519) 973-7083              *                                *
************************************************************************
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.notis-l
Date:         Wed, 7 Oct 1992 15:52:22 EDT
From:         "(NOTIS Systems mail I.D.)" <notis%twain.notis.com@UICVM.UIC.EDU>
Subject:      OCLC AND PASSPORT
Comments: To: notis-L%tcsvm.BITNET@uicvm.uic.edu

 wE HAVE TESTED THE 2.001 RELEASE OF OCLC PASSPORT SOFTWARE.  wE ARE
GLAD TO REPORT THAT ALL WE NEEDED TO DO WAS RECONFIGURE THE OCLC SOFT
WARE TO SET "NO TRANSLATION" FOR THE PRINTER DRIVER FOR EXPORT WITHIN
THE OPTIONS MENU. WITH THE "NO TRANSLATION" OPTION RECORDS EXPORT TO
NOTIS WTHOUT PROBLEMS

cUSTOMER SUPPORT SERVICES
708-866-1100
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Purdue University Libraries
Newsgroups: bit.listserv.notis-l
Date:         Mon, 12 Oct 1992 16:08:08 EST
From:         Alan Alexander-Manifold <ALANAM@PURCCVM.BITNET>
Subject:      RE: Location based catalogs

I heard somebody at the OPAC SIG say that, because of the response time
problem, location-based catalogs may next year be the issue to take the
place of the guide screen issue of this year and last.  I have a small
problem with this statement.  The guide screen thing was thrust upon us
with no warning, and with no apparent consultation about the final result.
We are upset and disgusted with the guide screens in 5.0.x, but the reason
we are angry is the lack of consultation and warning.

With location-based catalogs, the product looks exactly the way we wanted
it to look, so we will have no reason to be upset on that score.  As for
the response time, NOTIS has been warning everybody in capital letters
since long before they actually coded the thing that they suspected that
response time would be poor at best.  We asked for the feature, and we
got it.  We asked for warning about resource issues and response time
problems, and we got it.  That doesn't remove the response time problem,
but it's hard to fault NOTIS on this one.  Just pay close attention to
any warnings they're putting out now about future products, and be
prepared to believe them.
                                                         \
       --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)           \
From: batista@A1.RELAY.UPENN.EDU (Emily Batista)
Newsgroups: bit.listserv.notis-l
Subject: RIDV flag
Date: 16 Oct 92 16:55:01 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Return-Path: <batista@a1.relay.upenn.edu>
Msg-Class: ALL-IN-1 V2.3 BL8-4 Rev. AAC 20-Dec-1988
Comments: To: notis-l@tcsvm.bitnet

We also use date stamps on slips in the book, rather than printed due date
receipts.  We only have one printer for slips but several charge terminals,
and we don't have pockets in our books.   Our collection development staff
like to scan the books for the pattern of due dates when evaluating
materials for weeding or moving to storage, so we don't anticipate changing
our method.

I would also like to see a warning and an option to accept the normal due
date or the shorter due date.  We would like to use the RIDV flag for many
categories of users, especially courtesy borrowers, but would like to lend
books for normal periods for continuing borrowers.

Emily Batista, University of Pennsylvania
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.notis-l
Date:         Mon, 12 Oct 1992 13:32:52 CDT
From:         GINA@RICEVM1.RICE.EDU
Subject:      Re: CHAT-L: Operating Systems
              12 Oct 92 10:58:43 CDT from <FLOWERS@ricevm1.rice.edu>

:-)  :-)  :-)  (you should send one to kerry, too.)
From: KSIMMONS@UKANVM.BITNET (kendall)
Newsgroups: bit.listserv.notis-l
Subject: Re: Grateful Steers
Date: 14 Oct 92 18:07:40 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

ANYONE who drinks Steel City Beer would not have the faintest idea of what
a good beer tastes like.  Just wait till Christmas.

Kendall
From: GSTRAWN@NUACVM.BITNET (Gary L. Strawn)
Newsgroups: bit.listserv.notis-l
Subject: Fun indexing bug
Date: 16 Oct 92 21:19:23 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

Here's a quirky bug we just solved this afternoon.  It seems to have been
introduced with the "fix" to PPQ4211 (whatever that was); it was not present
in the original bibliograhpic indexing module.

In the "fixed" part of the code, a few statements after B140, R14 contains
the remaining length of the field being examined.  This length is used in an
EXecute instruction, which performs a TRT.  Now, consider what happens when
the length of the field happens to be an even multiple of 0x100 (e.g.: 0x100,
0x200).  The low 8 bits of R14 get ORed into the length byte of the TRT
instruction, which means that the length remains zero: this, in turn, means
that one (0+1) character actually gets looked at.  What happens if the
value in the TRT table for the character currently pointed to has a value
in the translation table of 0x00?  The TRT returns the value of "zero,"
which is interpreted to mean that we have reached the end of the field.

(This was discovered because we had a bibliographic record with a 245 field
whose length, after the BCTR, was exactly 0x100, AND the first character in
the 245 field was a diacritical mark, AND the filing indicator was set to
zero rather than one.  In effect, indexing of the 245 stopped before the
first character was reached; since there was no "title qualifier," no
index entries could be generated.)

Here's a simple fix.  Not terribly efficient, but the rewrite of this
portion of the program is so inefficient that I suppose we shouldn't
worry about a tad more inefficiency.  We start about 7 instructions
after B140 in LC360INC (which is included in LB310, LB311, and LC360).

          BCTR    R14,0         <--existing line
          CH      R14,=Y(250)   <--insert
          BNH     B142          <--insert
          LH      R14,=Y(250)   <--insert
    B142  EQU     *             <--insert
          EX      R14,B140TRT   <--existing line

The value "250" is arbitrary; it can actually be anywhere between 120 (the
maximum length of the longest segment in an index entry) and 255 (the longest
length that makes sense in the EX).

Gary L. Strawn
Authorities Librarian, etc., Northwestern University Libraries
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.notis-l
Date:         Mon, 12 Oct 1992 15:29:56 CDT
From:         Fred Gulden <LB.FHG@ISUMVS.BITNET>
Subject:      RE: Location based catalogs

Timothy Prettyman writes:

>Michael Stephens writes:
>>
>> If Tim's explaination of how location based catalogs work is correct, then
>> they will not be implemented in production here until the design is fixed.
>> I expect that the reason it is not much utilized at the University of
>> Michigan is its poor response time.
>
>Well, probably the main reason the feature hasn't been used much yet is that
>it hasn't been well publicized yet--not many patrons are aware of it, as
>evidenced by a small number of SET CAT commands recorded on the OPAC log.

Michael has a good point, though.  If response time turns out to be as bad as
evidence suggests, it may turn out to be a self-limiting feature.  If I try
a new feature and it takes several minutes to get a response, I tend to
not use such a feature again.  I suspect others may react in a similar
fashion.  We plan to test location based catalogs extensively before going
public.  If response time is abominable, we probably won't implement it.

************************************************************************
*  Fred Gulden                     *                                   *
*  Systems Specialist (LIB1)       *    BITNET:  LB$FHG@ISUMVS         *
*  34 Parks Library                *     PHONE: (515) 294-2445         *
*  Iowa State University           *       FAX: (515) 294-1885         *
*  Ames, IA  50011                 *                                   *
************************************************************************
From: BNICOL@LIB.AUBURN.EDU (Beth Nicol)
Newsgroups: bit.listserv.notis-l
Subject: CICS 2.1.2 and max searches, etc HELP!
Date: 15 Oct 92 17:26:23 GMT
Organization: Auburn University Libraries
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-pmrqc:      1
X-mailer:     Pegasus Mail v2.3 (R3).
Comments: To: notis-l@vm.tcs.tulane.edu

We brought CICS 2.1.2 up in production this morning and the NOTIS
region is in deep trouble.  I have talked with Jerry Specht and he
suspects that our monitoring program that cancels excessively long
tasks may be the culprit.  But that program was out doing its dirty
work when we were up under 1.7.  Ok, so I can sort of buy that the
task gets cancelled and the thread counter in LKB200p doesn't get
updated properly - so we slow down, and slow down.

My real question is:  Why are these transactions suddenly running up
such long CPU times?  Surely, not everyone on campus decided to do a
mega-Keyword search on the day that we cut over to 2.1.2.

Any ideas? Suggestions? Solutions?




Beth Nicol                        ************************************
Automation Manager                * When in danger, or in doubt,     *
Auburn University Libraries       * Run in circles, scream & shout!  *
BITNET:  bnicol@auducvax          *          -R.Heinlein             *
INTERNET: bnicol@lib.auburn.edu   ************************************
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.notis-l
Date:         Fri, 16 Oct 1992 11:04:52 EST
From:         Debbie Morrow <morrowd@GVSU.EDU>
Subject:      Re: NOTIS Customer Directory
Comments: To: notis-l@tcsvm.bitnet

   I, too, just saw Ramona's query about the directory, and called NSI --
   those of us who neglected to pick ours up at NUGM will get them next week
   or so:  they are due to be mailed out Monday 10/19.  I didn't ask about
   possible discrepancies.

   Debbie Morrow
   Grand Valley State Univ.
From: baughman@UTDALLAS.EDU (Barbara)
Newsgroups: bit.listserv.notis-l
Subject: Recall fines problem
Date: 15 Oct 92 20:52:11 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Comments: To: notis-l@VM.TCS.Tulane.EDU

I have found the fix (not the workaround) for the problem of recall fines
not being assessed when the item is returned past the recall due date but
before the normal due date.  There are two ways to workaround this problem.
One is to not charge normal overdue fines.  The other is to set the
minimum normal overdue fine to any number except 0.  Note that the non-zero
minimum overdue fine must be set for the NORMAL overdue.  Setting any other
minimums to non-zero values will not fix the problem.

Read on if you are interested in the technical end of this.

The program erroneously assumed that if the overdue flag is set, then the
item must have been discharged past the normal due date.  It calculates the
fine as (#of days overdue) times (daily fine).  If the item is not yet overdue
on the normal due date, then this fine is negative.  The program then
calculates the recall fine and adds up all the fines (normal overdue and
recall).  It checks to see if the total fine is not positive.  If it isn't,
then it branches and processes the discharge as if there were no overdue
fines at all.  Because the negative normal overdue fine usually causes the
total fine to be non-positive, no fine processing is done.

If the daily fine is zero, then the normal overdue fine will not be a negative
number, and the recall fine will come through just fine.  If the minimum normal
overdue fine is not zero, then the program checks to see if the calculated fine
is less than the minimum.  If it is less than the minimum, then it continues
processing as if the normal overdue fine were zero.  Since the calculated fine
was negative in this case, the calculated fine is automatically less than the
minimum.  Again, with the normal overdue fine equal to zero, the recall fine
is processed correctly.

NSI has suggested to me that this particular problem is fixed in 5.1.  I have
a program fix for those who don't like the workaround and can't wait.  The
normal caveats apply concerning support from NSI.  Those sites who have applied
the workaround shouldn't bother.

Barbara Baughman                *********************************
TECH1                           *                               *
University of Texas at Dallas   *   First right, then rewrite!  *
(214) 690-2157                  *                               *
BAUGHMAN@UTDALLAS.EDU           *********************************
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.notis-l
Date:         Mon, 12 Oct 1992 15:39:46 -0500
Comments:     Warning -- original Sender: tag was daviss@DAVIS.CUL.COLUMBIA.EDU
From:         Stephen Davis <daviss@CUNIXF.CC.COLUMBIA.EDU>
Subject:      info on ALA-tn3270 product
Comments: To: NOTIS Listserv <notis-l@tcsvm.bitnet>

Because I got so many questions at NUGM about our use of this product, I
thought I'd go ahead and post the info below to the list at large.  (If
Cornell-folk want to add anything, please feel free!)

The DOS tn3270 product that supports the ALA character set should be available
via anonymous ftp from

	ftp.cit.cornell.edu (128.253.232.116)

as 	pcip183.zip

in the 	/pub/pc/comm directory.

When ftp'ing the file, be sure to specify that this is a binary transfer
(issuing the command "tenex" or "bin" after logging in will be sufficient on
many systems)

Our original contact at Cornell was Richard Kennerly
(lvl@cornella.cit.cornell).  There may also be contact information in the
readme file that comes along with the program.

We tried to get written user documentation from Cornell, without any luck.
They said at the time that they were preparing some at Cornell's Mann Library,
but hadn't finished yet..

Although the program has worked fairly well for us, there are several things
to keep in mind:

1) it lacks printer support for ALA diacritics; this apparently wasn't a
priority for Cornell.   (Printers with IBM proprinter emulation manage ok with
the Cornell package, with the special ALA characters translated into various
graphic symbols, but *not* the actual ALA graphics.  Other emulations cause
the printer to go crazy when it encounters certain nonstandard characters...)

2) it lacks a scripting facility

3) it lacks on the fly user-definable key redefinition

4) we have been experiencing some intermittent & mysterious corruption of the
configuration file, requiring us to reinstall it regularly (namely, each time
the user selects NOTIS from our menu system).  We don't know why this is
happening, but suspect the Cornell package, having tried to eliminate other
possibilities.

5) we had difficulty restoring the video mode after use of the ALA mode.  We
found, by trial and error, that running the font executable without an
argument (ie "instfont.com" by itself on a command line) restores the original
DOS video mode (ie it's not slightly compressed at the bottom as in ALA mode).

Other than that, however, it has proved effective and is currently employed
for NOTIS cataloging and acquisitions on 75 plus workstations here at
Columbia.

==============================================================================
Stephen Davis				email:  daviss@cunixf.cc.columbia.edu
Ass't Director for Library Systems 	voice:  (212) 854-4744
219M Butler Library 	   		fax:    (212) 222-0331
Columbia University
New York, NY 10027
==============================================================================
From: sgrazzut@ACS.UCALGARY.CA
Newsgroups: bit.listserv.notis-l
Subject: Re: CHAT: 12 NUGM Sessions poem
Date: 14 Oct 92 22:17:48 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11s]
              "DROBERTS@NUACVM.BI

What?  Did I miss something?  I'm confused....
>
> So, do you want to sing it at the next staff meeting?
>
From: LSYS1@UVVM.UVIC.CA (Kathleen Matthews)
Newsgroups: bit.listserv.notis-l
Subject: Re: NOTIS 5.2 Oversight Committee
Date: 14 Oct 92 21:41:26 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU

Thank you Bruce for your explanation of the 5.2 Oversight Committee..it is
a curious name and I didn't realize it was the name of the circ sig rewrite
committee.   It is still unclear to me, even more so since the NUGM rewrite
session, whether NOTIS is planning to "enhance" the existing circ module or
"rewrite and enhance"  or "redesign".  Is this known at present or is this to
be discussed at the November 11th meeting ?  Thanks.
en Wed, 14 Oct 1992 16:42:39 EDT <HULSE@WRLCVM> said:
>Kathleen,
>
>The 5.2 Oversight Committee had its origins at last year's NUGM, when NOTIS
>announced that release 5.2 would deal with the circulation module and asked the
>Circulation SIG to select three members to work with NOTIS on this project.
>
>As we noted at the 5.2 session at NUGM, our work so far has been to take
>the Circulation SIG's original enhancement requests which were created in
>1991 and synthesize them with newer suggestions that have been put forward in
>the past year. These updated enhancement requests have been delivered to
>NOTIS and distributed over NOTIS-L over the course of the summer.
>
>NOTIS has asked us to meet with them November 11 to answer questions about the
>proposals and discuss priorities. As I noted at the Circulation SIG business
>meeting the vote taken by the SIG last year on it's top 10 priorities will be
>our primary guide in this task.
>
>The committee further wishes to oversee the design process insofar as possible
>to avoid the sort of loss of functionality you mentioned in you earlier post
>and identify any fundamental design flaws before they get too far. Needless to
>say the details of how this will happen are being worked out as we go along;
>this process is new to both NOTIS and the Circulation SIG.
>
>If you have any specific questions about the proposals feel free to e-mail me
>directly.
>
>Bruce Hulse
>Systems Librarian
>Washington Research Library Consortium
>hulse @ wrlcvm                    301-731-1000  ext. 404

**********************************************************************
KATHLEEN WEBSTER MATTHEWS (LSYS1@UVVM.UVIC.CA)
Systems Librarian, McPherson Library
UNIVERSITY OF VICTORIA, VICTORIA, B.C., CANADA.
(604) 721-8219
**********************************************************************
From: DIXON@MACC.WISC.EDU (Edie Dixon)
Newsgroups: bit.listserv.notis-l
Subject: propac proloan
Date: 16 Oct 92 18:13:00 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-VMS-To: IN%"notis-l@tcsvm.bitnet"

I sent  this earlier, but saw no response so thought should re-send just in case
...

This is a question about what machine will run ProPac and PacLoan.

Seems to me that it will take a 386 machine to run either ProPac or PacLoan.  If
we wanted to run both products on the same machine  we would need a 486
 machine.  Anyone else out there hear
anything different?  Have I got this right?  I'm trying to do some planning for
the future and what kind of machine and the money it will take to run these
products is really important.


Edie Dixon, LIB1
U of Wisconsin
bitnet: DIXON@wiscmacc
phone: 608-262-3525
From: VOOX1001@SMUVM1.BITNET (Ellen Frost (Library Search Committee))
Newsgroups: bit.listserv.notis-l
Subject: Position available
Date: 16 Oct 92 18:03:28 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU


             Perkins School of Theology
           Southern Methodist University

Position open for Library Director

Current opening for Director of theological teaching, research library/
rare book repository at SMU.  Salary competitve, comparable library
experience highly desirable, faculty status.  Resumes to James E.
Kirby, Dean, Perkins School of Theology, SMU, Dallas, TX 75275-0133 by
December 15, 1992.  SMU is an affirmative action/ equal opportunity/
Title IX employer.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Envelope-to: NOTIS-L@TCSVM.BITNET
X-VMS-To: IN%"NOTIS-L@TCSVM.BITNET"
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Newsgroups: bit.listserv.notis-l
Date:         Tue, 13 Oct 1992 08:22:49 -0500
From:         STEFFERJ@VUCTRVAX.BITNET
Subject:      Re: trailing blanks in opac 5.0.2

Thanks to Ron Johnston of McGill for his fix to the problem of
trailing blanks.  This is something we have been struggling with
for a while.  We have a variety of terminals in our libraries
with a variety of keyboards and mechanisms for "erasing end of
field."  Trying to explain this technique for getting rid of
characters at the end of your revised search has been difficult.
We have put Ron's fix into production (we're on 5.1) and are
very grateful to him for his fix.

By the way, several people at NUGM were talking about the problem
with an S in a call number search.  That is working okay at
Vanderbilt now, but I don't believe it is a NOTIS fix.  I think it's
a fix that someone else wrote (maybe it was Tim Prettyman at Michigan).
Tim, if it was you maybe you could post it again for the others who
are just now encountering the problem?  What would we do without
NOTIS-L?
_______________________________________________________________________________
/ Ramona Steffey Madewell              /               Bitnet:                /
/ Automation Project Librarian (LIB1)  /          STEFFERJ@VUCTRVAX           /
/ Vanderbilt University                /              Internet:               /
/ Library Systems                      /    stefferj@ctrvax.Vanderbilt.Edu    /
/ 419 21st Avenue South                /       Phone: (615) 322-7125          /
/ Nashville, TN  37240                 /         Fax: (615) 343-0394          /
-------------------------------------------------------------------------------
From: LENGYEL@YALEVM.BITNET (Suzanna Lengyel)
Newsgroups: bit.listserv.notis-l
Subject: Re: Missing Purchase Orders (LB060JC)
Date: 15 Oct 92 16:21:25 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
              15 Oct 1992 08:53:07 EDT from <344PWCF@CMUVM.CSV.CMICH.EDU>

This is a reply to Daniel Kirchner's question about missing purchase orders.
Is it possible that the order status (or is it called order activity status?)
on the OPR's is BN rather than AN?  We have found many times that the
non-delivery of a printed purchase order was due to having used the code 'B'
in that field.  I am certain that if the code is B, a purchase order will not
be printed.  Whether a record is written in Journal 3, I don't know, probably
not.

Suzanna Lengyel.  Yale University Library Systems Office. (203) 432-1844.