home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / bit / listserv / jnetl / 130 < prev    next >
Encoding:
Text File  |  1992-11-13  |  2.9 KB  |  51 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!stanford.edu!bcm!convex!darwin.sura.net!paladin.american.edu!auvm!PSULIAS.BITNET!JLW
  3. X-Organization: Penn State University / University Libraries
  4. X-Envelope-to: jnet-l@uga.BITNET
  5. X-VMS-To: JNET_L
  6. Message-ID: <01GR3SZKDDOC9LUY09@psulias.bitnet>
  7. Newsgroups: bit.listserv.jnet-l
  8. Date:         Fri, 13 Nov 1992 13:57:00 EST
  9. Sender:       BITNIC JNET-L List <JNET-L@UGA.BITNET>
  10. From:         "J.Lance Wilkinson, 814-865-1818" <JLW@PSULIAS.BITNET>
  11. Subject:      JNET API question...
  12. Comments: To: JNET-L@PSULIAS.BITNET
  13. Lines: 36
  14.  
  15. A few months ago, documentation regarding the JNET API v3.5 arrived; dated
  16. May 1991, I don't think it arived *that* long ago.  I remember when it did
  17. arrive I was intrigued but at the time didn't have anything to do with it.
  18.  
  19. Now I do, but I don't think there's a function that will do what I need.
  20.  
  21. We have a user environment here that isolates our users from DCL completely.
  22. We use VMS Mail, JNET, PMDF and so forth but our users are totally insulated
  23. from DCL.  All access to MAIL and to the RECEIVE and SEND commands are through
  24. this user interface of our own devising.  RECEIVEd files generally weren't a
  25. problem until fairly recently.  Now they're cropping up with regularity and
  26. our users are, apparently, ignoring the entreaties to use the LIAS SELECT
  27. command (we've editted JAN_SYS:LOGIN to display a different message, one that
  28. makes sense in the users' environment) and receive their files (to some extent,
  29. since they've got no way to *access* the files afterwards (no EDITORS are made
  30. available to them, except in VMS MAIL/SEND), I can almost agree with their lack
  31. of interest in RECEving them...;-)
  32.  
  33. Our environment uses the VMS MAIL API to report if the user has outstanding NEW
  34. MAIL messages.  I was hoping part of the JNET API would provide a count of
  35. files waiting to be RECEIVED (rather than coding the overhead to search for the
  36. files JAN_RECEIVE:xxx.RSC.*, where "xxx" is the user's identification).  So far
  37. I don't see any such count.  I'm betting there isn't any quick,non-file-
  38. counting way of doing this, but hope springs eternal.  Anybody have any
  39. suggestions?
  40.  
  41. +-"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+
  42. | J.Lance Wilkinson ("Lance")            BitNet:    JLW@PSULIAS.BITNET      |
  43. | Systems Design Specialist - Lead       InterNet:  JLW@PSULIAS.PSU.EDU     |
  44. | Library Computing Services         AT&T:(814) 865-1818 FAX:(814)863-3560  |
  45. | E8 Pattee Library                      "I'd rather be dancing..."         |
  46. | Penn State University         A host is a host from coast to coast,       |
  47. | University Park, PA 16802     And no one will talk to a host that's close |
  48. | <POSTMAST@PSULIAS.BITNET>     Unless the host that isn't close            |
  49. | <POSTMAST@PSUCES.BITNET>      Is busy, hung or dead.                      |
  50. +------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+
  51.