home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / internal / 1281 < prev    next >
Encoding:
Internet Message Format  |  1992-09-04  |  2.3 KB

  1. Xref: sparky vmsnet.internals:1281 comp.os.vms:14617
  2. Newsgroups: vmsnet.internals,comp.os.vms
  3. Path: sparky!uunet!destroyer!fmsrl7!lynx!cancer.unm.edu!BOARDMAN
  4. From: boardman@cancer.unm.edu (Bob Boardman)
  5. Subject: How to move Queue files vms 5.5?
  6. Message-ID: <bwmn7jq@lynx.unm.edu>
  7. Date: Fri, 04 Sep 92 17:27:00 GMT
  8. Organization: UNM Cancer Center
  9. Reply-To: boardman@cancer.unm.edu
  10. Lines: 34
  11.  
  12.  
  13.   Last night we moved our system and users from our old RA81's to our
  14.   new RF73's, on our Vax 4000-200 under VMS v5.5.  Everything went pretty
  15.   smoothly, except for the *#$%^$ new queue system.  For some reason, the
  16.   queue system still insists on using the RA81 for two of the three queue
  17.   files.  The logical QMAN$MASTER is defined as SYS$COMMON, and indeed it
  18.   is using the QMAN$MASTER.DAT file on the new RF73 system disk, but it is
  19.   still insists on accessing the RA81 for the other two files:
  20.  
  21.      [SYSCOMMON.SYSEXE]SYS$QUEUE_MANAGER.QMAN$QUEUES;1
  22.      [SYSCOMMON.SYSEXE]SYS$QUEUE_MANAGER.QMAN$JOURNAL;1
  23.  
  24.   No one at this site has documentation on the new 5.5 queue manager (we're
  25.   an ESL site and the ESL people are unavailable at the moment, and probably
  26.   couldn't help anyways).  I haven't been able to find any other logicals
  27.   that the queue manager might be using to point to these files, so I suspect
  28.   that the location of these files must have been written into the QMAN$MASTER
  29.   file.  We probably shot ourselves in the foot during the 5.5 upgrade by
  30.   specifying the location of the new queue files as "dub0:" rather than
  31.   $disk1:.  Digging through the on-line docs, I think we could maybe do it
  32.   by stopping the queue manager, then using START/QUEUE/MANAGER/NEW_FILE=$DISK1
  33.   to create new queue files, stopping the queue manager again, copying the old
  34.   dub0: files to $disk1, and the restarting the queues, but since we are a
  35.   critical production machine and really need the queues to be working, I'm
  36.   nervous about trying this without knowing for sure that this will work.
  37.   Has anyone else run into this problem?  If so, how do you fix it?
  38.  
  39.   -Bob
  40.  
  41.  
  42. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  43. |      Bob Boardman, University of New Mexico, Albuquerque, New Mexico        |
  44. |         internet:boardman@cancer.unm.edu    bitnet:BOARDMAN@UNMB            |
  45. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  46.