home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18080 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  2.3 KB
  1. Path: sparky!uunet!think.com!ames!agate!ucbvax!VMSFE.ULCC.AC.UK!CZIWKGA
  2. From: CZIWKGA@VMSFE.ULCC.AC.UK ("Kevin Ashley, Systems Development, ULCC")
  3. Newsgroups: comp.os.vms
  4. Subject: re: problem making an outbound x29 call
  5. Message-ID: <9211170904.AA04874@ucbvax.Berkeley.EDU>
  6. Date: 16 Nov 92 09:44:00 GMT
  7. Sender: usenet@ucbvax.BERKELEY.EDU
  8. Organization: The Internet
  9. Lines: 50
  10.  
  11. Anders (Rolff ?) wrote a few days ago in a message which had no mail
  12. address about a problem he was having with x29 calls.
  13.  
  14. He wrote:
  15.  
  16. >I think I have tracked down the problem to facility negotiation. If I make
  17. >an x29 call with $ set host/x <addr> I get the following accounting
  18. >info on the remote node:
  19. >
  20. >Calling facilities:
  21. > 42 07 07
  22. >
  23. >Accept facilities:
  24. > 42 07 07
  25. >
  26. >But, if I use psi$x29_outgoing_c the call fails with Virtual call cleared
  27. >and the accounting info on the remote node looks like this:
  28. >Calling facilities:
  29. > 42 07 07
  30. >
  31. >Accept facilities:
  32. >
  33. >
  34. >It doesn't seem like the remote node is accepting the facilities.
  35. >
  36.  
  37. No, anders, this just means that the remote node didn't accept the call.
  38. If there isn't a call accept, then there aren't any accept facilities for
  39. psi accounting to record. In any event, since the calling facilities you
  40. showed in both these calls are the same, this would not make sense. What
  41. would be more useful would be to show the other information that
  42. PSI accounting shows, ESPECIALLY anything that differs between the
  43. call that works and the call that fails. Most useful of all would be
  44. the second page of output from PSI accounting showing the clearing
  45. cause and diagnostic fields, and stuff like the protocol ID.
  46.  
  47. There are 1001 reasons why calls like this can fail, including security
  48. facilities on the remote node that are fussy about exactly how incoming
  49. calls are set up. At least you have managed to demonstrate that the
  50. calls are reaching the remote node, and not getting bounced somewhere
  51. else in the network, and this is helpful.
  52.  
  53. But, if you show us the rest of the PSI accounting info from the remote end,
  54. someone might be able to do more than hazard a guess as to why it failed.
  55.  
  56. ------------------------------------------------------------------------------
  57. Kevin Ashley                              K.Ashley@Ulcc.ac.uk
  58. Systems Development Group Manager         ...ukc!ncdlab!K.Ashley
  59. University of London Computer Centre. 
  60.  
  61.