Conference iosg::all-in-1_v30

    Kevin,
    
    1). No - i'm sure there will be a few pedantic people who point to
        an odd DAF field or two for TeamLinks or A1MAIL but it's the same
        old mail code as in 1983 that predates even good old MRIF.
    
    2)  Can't you do it from the MAD option off MM? My memory must be
    failing but I thought that has been there since v2.3 - in fact unless
    i've completely lost it it may have even been me who introduced it.
    
    3) I guess so - I haven't it tried myself but the code implies its 
       going off to delete something out of MBMAN.
    
    4) no more than any other version of ALL-IN-1 (see many other notes
       on VMS v5.5) once the last Queue Manager patch is available
      officially we should be ok. Oh there is one bit in the release notes
      about using the APPLICATION function on v5.5 so I guess that makes
      it "known"
    
    5) too tough for me.
    
    6) haven't heard of any problems with Queue Management - if you have
       the right identifier you don't need the form library - I thought
       that was thw hole point of all these identifers so as to free up
       valuable space on the FRMLIB line.
    
    7) You mean someone did STOP PROC/ID on it? cue Terry or Bob 
    
    8) well i'll leave that to the experts ...
    
    Regards,
    
    Andrew.D.Wicks

    
    Hi Kevin,
    
    
    >>7. If the server::"73" is stopped for some reason, (possibly by a
    >>student, unknowingly???) is there any reason why the MGR account
    >>wouldn't be able to restart the server?  I got it started by shutting
    >>down and restarting ALL-IN-1 and then reentering the STA start server
    >>menu option?  It seemed sort of like a back-door approach.
    
    Under normal conditions the server should only be stopped via the UI
    (SM MFC MS STO). However, by doing a STOP PROC/ID there should not
    be any big impact, other than perhaps any current server requests not
    being completed before it stops.
    
    In both cases the server can be restarted simply via the same UI
    (SM MFC MS STA) - there's no need to shut down and restart ALL-IN-1.
    
	
    Kevin.
    ~~~~~~
    
    

    
    >    3. When deleting a user account, one of the questions asked is if you
    >    want to delete the MAIL DIRECTORY entry.  Does V3.0 delete the DDS
    >    entry?  If not, what is this referring to?
    
    	Yes, MAIL DIRECTORY is user-eze for DDS entry. I wanted to change
    	all the prompts to say DDS entry, but several people pointed out
    	that all the books and all the code refers to Mail Directory with
    	no mention of DDS.
    
    >	5) Deleting shared drawers
    
    	I'm sure this must be in the books.
    
    >   7. If the server::"73" is stopped for some reason, (possibly by a
    
    	If the server is really "dead", then I can see no value in shutting
    	down ALL-IN-1. I have seen problems in early baselevels where if
    	you started a new server before the old one was gone (the server
    	sometimes refused to exit) then even killing the old one didn't
    	revive the new one. But I think these problems were fixed in a
    	later baselevel. However, ALL-IN-1 shutdown and restart was tarted
    	up to cope in this situation so that if it occurred, everything
    	would be straightened out.
    
    	Also, sometimes if you start a server on the wrong node (eg start
    	FOO$SRV73 on node BAR, eg using a generic queue to start the
    	servers) the SM UI gets confusing and it is hard to figure out
    	what is actually going on. Again, shutdown/restart shouldn't get
    	confused by this.
    
    	So in short, if you are sure everything is pukka, and you are sure
    	you are not confused, then Shutdown/Restart has no value.
    
    >    8. Last one, any problems found with preparing and transferring
    >    accounts?
    
    	Several problems were found during fieldtest for V3.0<->V2.4
    	transfers and were fixed in both V3.0<->V2.4 and V3.0<->V3.0
    	transfers. The V3.0<->V3.0 code has not had the same amount of
    	exposure as V2.4<->V3.0 yet as most people don't have multiple
    	V3.0 systems, but the code is also slightly simpler than the V2.4
    	case.
    
    	I would be surprised if there were NO bugs in the V3.0<->V3.0
    	code, but it has been tested extensively.
    
    Regards,
    Paul

Q7:

If a server stops for any reason (deliberate, accidental or failure) then STA
should start it again no problem. Remember STA submits a batch job to start
the server and until the detatched process is started and through it's 
initialisation the server status will appear as Stopped. Also the status on
the ALL-IN-1 menu is not updated until you do something (hitting RETURN is 
enough). Basically give it a few minutes (on a busy system) to come up. When
it is up and ready the server process should be in HIB state (until someone
gives it work to do).

I have seen a few startup problems

- The startup queue is a generic queue. This will work OK if the startup
  happens to run on the correct node. If the startup runs on another node
  that is part of the ALL-IN-1 system (has all the logicals defined) and
  the DECnet object on that node (typically 73) is not in use then the 
  server will startup OK. You now have a server on NODEB using DECnet object
  73 and you are trying to talk to DECnet object 73 on NODEA. Never the twain
  shall meet.

  If you now try to start up the server again on the correct node it will
  fail because the server running on the wrong node will have the configuration
  file locked. You must find out which node the server actually started on
  and do a STOP/ID on it, but make sure you stop the right one!!!

  The bottom line is make sure the server does not start on a generic queue,
  unfortunately the field validation allows generic queues provided they are
  on the same node as the server is intended to run on.

  Could this have been your problem? I think shutting down ALL-IN-1 would kill
  the servers on all the nodes in the cluster and hence would allow STA to
  work if the startup batch job happened to get to an execution queue on 
  the correct node.

- Setting Distribution to ON when DNS is not set up. This caused the server to 
  fail on startup with no indication why. Accounting will show an exit status 
  that is a DNS error.

  Unfortunately you can not change distribution back to OFF without starting 
  the server, and you can't start the server until you change distribution
  back to OFF ....  8}

  The way round this is to delete and create the server again, this sounds
  drastic, but all you are doing is deleting and adding a record to the
  server master file (this contains the configuration information) and creating
  a new configuration file (contains the server attributes) with default
  attribute values. ALl you lose is any changes you made to the server
  attributes.

You can also check the server log file SYS$MANAGER:OAFC$SERVER.LOG for errors
and the server startup batch log file OA$LOG:OAFC$SERVER_STARTUP.LOG for any
errors.

If that does not tell you what is wrong try starting the server interactivly

$ FCS:=="$OAFC$SERVER"
$ FCS file

where file is the filename of the configuration file.

You will either get an error message or startup conformation if all is OK. Use
Ctrl-Y to stop the server if it starts OK.

Q8:

The only potential problems with transfer user that I know of are that
archived documents must be restored before the transfer (this has always
been the case since archiving was introduced in V2.3) and that reserved
documents must be unreserved.

Having said that, transfer user in V3.0 is a lot better than V2.3/4, it uses
less disk space and leaves the source account untouched (but locked) so if
there are problems they are 100 times easier to resolve.

HTH

Terry

>>    6. Are there any known problems with granting queue management
>>    privileges?
===
Kevin,

I know of no reported problems against Queue Management Authorization. 
Have you something in mind? I tried to capitalize on the facilities that
Groups gives us to make this authorization system work smoothly, and clean 
up after itself.

>>    The account we gave the privilege to received VMS rights
>>    id, but didn't receive the form libray, UQM.FLB.
===
As I recall this is not explicitly placed in the FRMLIB field in Profile, but
is opened according to some named data on Default which goes as follows:
;;OA$_MO_USER_QM;; UQM

RIGHTS FIND_ID "OA$USER_QM"\
.IF OA$STATUS EQ 0 THEN GET OA$DISPLAY = OA$_QM_NOACCESS\
IFSTATUS\
.IF OA$DIR:.ALLBUTVER["OA$LIB:UQM.FLB"] EQS ""
 THEN GET OA$DISPLAY = OA$_QM_NOFORM_LIB\\GET OA$STATUS = 0
 ELSE GET OA$STATUS = 1\
IFSTATUS\
.IF NOT (oa$form_search_order <=> "OA$LIB:UQM")
 THEN
     GET OA$DISPLAY = OA$_INIT_QM_SYSTEM\\
     FORCE\\
     OA$FLO_OPEN_LIB OA$LIB:SITEUQM\\
     OA$MSG_PURGE\
.IF oa$form_search_order <=> "OA$LIB:UQM"
 THEN
     FORM UQM$MAIN
 ELSE
     GET OA$DISPLAY = OA$_QM_NOACCESS

This was all done to avoid having to give otherwise-unprivileged users
access to OA$LIB:ADMIN, where the UQM forms originally resided.
Hope this helps.
DaveT

    
    Re: Servers and their starting up batch queues.
    
    I believe you'll find that this problems no longer exists with
    BL122 or later kits.
    
    Upon creating a server, the UI will first look at the queue defined
    by SYS$OA$MUA_QUEUE. If this is not node specific then it will reject
    it and find the first NODE SPECIFIC, NON GENERIC queue on the system.
    
    Note: SYS$BATCH may be used, but only if it's sub queues are all 
          specific to that node.
    
    
    I take it the problems described previously are from experience with
    older base levels ?
    
    
    
    Kevin.
    ~~~~~~
    
    

Kevin,

I just checked out BL123 and the validation of the server startup queue, both
on creation of the server and on subsequent edits of the server configuration
information, only checks that the selected queue is on the node that the server
should run on, it does not check for generic/non-generic queues.

It looks like the problem still exists ...

Terry

    RE: .3 & .8
    
    Do I hazard a guess and assume that a member of IOSG is using ALl to be
    a shortened form of ALL-IN-1?
    
    If Yes, then I didn't see any (abusive) notes to enlighten them in their
    ways! 
    
    If No, what does it mean?
    
    Dave

    
    	That was supposed to read "All non-trivial software has at least
    	one bug" the corollary of which is "Any software with no bugs is
    	trivial"... I thought it was a fairly well known "Murphy's Law".
    
    	ALl was a typo for All or ALL, and nothing to do with our beloved
    	ALL-IN-1 (except to say that it is non-trivial).
    
    Regards,
    Paul

    Paul,
    
    Cheers. Now it makes sense.
    
    Dave