home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 19721 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  1.7 KB
  1. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!spool.mu.edu!hri.com!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!seunet!elmrd6.ineab.ikea.se!anos
  2. From: anos@elmrd6.ineab.ikea.se
  3. Newsgroups: comp.os.vms
  4. Subject: Using DECNET ALIAS to masquerade
  5. Message-ID: <1992Dec22.164852.39@elmrd6.ineab.ikea.se>
  6. Date: 22 Dec 92 14:48:52 GMT
  7. Organization: IKEA Northern Europe AB
  8. Lines: 25
  9.  
  10.  
  11.  I need some info (that I cant find in the Fine Manuals). I have two Vaxes
  12.  at a client site, called X and Y. They as clustered in a DSSI system.
  13.  Now, system X are running a data transfer software that sends/recieve data
  14.  to and from a MVS/3090 system via Decnet (and a middle Vax). System X is
  15.  known and approved at the IBM site. The problem is that this application
  16.  takes a *lot* of CPU away from interactive users of X. Y is also quite
  17.  loaded so we cant just simply move them there. I was thinking of using the
  18.  Decnet alias facility to let the whole cluster be seen as X from the
  19.  outside world and thus let Y send data to (and recieve) the IBM system
  20.  without chaning routing tables etc at the remote site.
  21.  
  22.  Is this possible ? If so, is there any other things to watch out for.
  23.  
  24.  Any help is welcome
  25.  
  26.  Anders 
  27.  
  28. +------------------------+--------------------------------------------------+
  29. | And my name is ...     | Anders Ostling                    |
  30. | employed by ...        | IKEA Northern Europe AB (INEAB)                  |
  31. | located in ...         | Helsingborg, Sweden                              |
  32. | Return mail address to | anos@ineab.ikea.se                    |
  33. | Phone                  | +46 42 15 29 06                                  |
  34. +------------------------+--------------------------------------------------+
  35.