home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / bit / listserv / notisl / 4415 < prev    next >
Encoding:
Text File  |  1992-12-22  |  3.1 KB  |  58 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!europa.asd.contel.com!paladin.american.edu!auvm!PENNDRLS.UPENN.EDU!YETTER
  3. Return-Path: <YETTER@PENNDRLS.UPENN.EDU>
  4. Message-ID: <9212211916.AA10649@noc2.dccs.upenn.edu>
  5. Newsgroups: bit.listserv.notis-l
  6. Date:         Mon, 21 Dec 1992 14:00:28 EST
  7. Sender:       NOTIS discussion group list <NOTIS-L@TCSVM.BITNET>
  8. From:         Peggy Yetter <YETTER@PENNDRLS.UPENN.EDU>
  9. Subject: RE: Problems with MDAS 1.3
  10. Comments: To: notis-l%tcsvm.bitnet@NOC2.DCCS.UPENN.EDU
  11. Lines: 45
  12.  
  13. > Having installed MDAS 1.3 in our test region, I would like to point
  14. > out a couple of things which I see as problems, mostly due to changed
  15. > or removed functionality.
  16. >
  17. > 1. For a secured database (one which requires sign-on) it is no longer
  18. >    possible to define a subset of terminals which does not require
  19. >    sign-on.
  20. >
  21. >    Under MDAS 1.21, we require dial-in users of our Wilson databases
  22. >    to sign on, because our Wilson contract requires it, but we do not
  23. >     require sign-on on the in-building terminals, because Wilson does
  24. >    not require that. This is possible under 1.21, because sign-on is
  25. >    part of the terminal control in nsys. Now, sign-on has been moved
  26. >    out of terminal control and into Navigator control with 1.3, so
  27. >    if you define a database to require sign-on, it will do so with all
  28. >    terminals.
  29. >
  30. >    This creates a problem, of course, for community users, high school
  31. >    students, etc., who don't fall under our Wilson contract but were
  32. >    always able to use Wilson if they came into the building. Changed
  33. >    functionality is forcing us to be more restrictive than we have to be
  34. >    or find some unsatisfactory work-around.
  35. >
  36.                                . . . . . .
  37. > email: anne-highsmith@tamu.edu
  38.  
  39. We were able to have terminals that had patron signon security and other
  40. terminals that did not for the same database.  You create one navigator
  41. grouping for your databases and set "signon" to "y" and create
  42. another navigator grouping with the same databases but set "signon"
  43. to "n".  We have a number of configurations depending on the library
  44. so I've resorted to treating the parameter name like an UPSI switch.  The
  45. first letter has to be alpha but after that each place represents a
  46. database with "1" meaning security on and "0" meaning security off,
  47. e.g., M011001.  We have set the parameter display to "n" so that the
  48. public never sees this and the description name is the same for all
  49. profiles.  This naming configuration really helps when I then go to the
  50. terminal definition to insert this parameter name under "group".
  51. -------------------------------------------------------------------------
  52. | Peggy Yetter                       : Van Pelt Dietrich Library Center |
  53. | Systems Analyst                    : 3420 Walnut Street               |
  54. | University of Pennsylvania         : Philadelphia, PA  19104-6206     |
  55. | yetter@penndrls.upenn.edu          : (215)898-4824                    |
  56. |         MVS/ESA 4.2; CICS 2.1; NOTIS 5.0.2; MDAS 1.2; GTO 3.0         |
  57. -------------------------------------------------------------------------
  58.