[bit.listserv.notis-l] LTVCHR

VB7R0007@SMUVM1.BITNET (Michael J. Stephens) (02/01/90)

Has anyone had problems with the fact that the voucher file is limited to
only one institution group within a given CICS region?  According to doc-
umentation and practice it seems that the voucher file ddname, LTVCHR, is
hard-coded in the system.  This is at odds with the design of the rest of
the system.  Ddnames are coded in LC101TB1 and LC101TB2.  While a minor
annoyance for most, SMU included, this seems like a good area for change/
enhancement.

Michael J. Stephens
Sr. Systems Analyst
Computer & Information Services
Southern Methodist University
Dallas, Tx. 75275
(214) 692-3453
Bitnet: VB7R0007@SMUVM1

WRT@CORNELLC.BITNET (Bill Turner, Cornell University Library) (02/02/90)

Since the voucher file exists only for communication with a batch job,
I think it's fine that it have a fixed name and that all inst groups
share it. Otherwise running the batch job would be more of a pain.

We don't specify institution group for journals 3 and 6 either.

C81350JH@WUVMD.BITNET (Jeff Huestis) (02/02/90)

>Date:         Thu, 1 Feb 90 09:24:04 CST
>Sender:       NOTIS/DOBIS discussion group list <NOTIS-L@TCSVM>
>From:         "Michael J. Stephens" <VB7R0007@SMUVM1.BITNET>
>Subject:      LTVCHR
>
>Has anyone had problems with the fact that the voucher file is limited to
>only one institution group within a given CICS region?  According to doc-
>umentation and practice it seems that the voucher file ddname, LTVCHR, is
>hard-coded in the system.  This is at odds with the design of the rest of
>the system.  Ddnames are coded in LC101TB1 and LC101TB2.  While a minor
>annoyance for most, SMU included, this seems like a good area for change/
>enhancement.
>
There are a number of places where recent releases of NOTIS have departed
from the original design, particularly of the Institutional tables.  In some
cases, this has been necessary because of limits in the original design.
LC660TBL would be one example of this; LTVCHR is another.  Hopefully,
renumbering 4.7 to 5.0 reflects the intent to correct this problem, rather
than just being a marketing technique.

On the other hand, most of the departures seem to be in the nature of
short-cuts--hardcoding things that were supposed to be table-driven.  I'm
surprised that no one has ever complained about the treatment of patron
ID status codes in LC530 and LC532.  Maybe no one else cares.

Jeff Huestis
Washington University