Conference iosg::all-in-1_v30

    Sunil,
    
    Very interesting. A couple of weeks ago a customer also had this
    problem. They could reproduce it by removing the DDS SUBSCRIBER entry
    for the manager, and run USERAGENT_POST twice. It seems that the
    existance of a manager subscriber entry causes the trouble.
    
    Unfortunatly I wasn't able to reproduce it, and the customer was in a
    hurry. So there was no time to play on their system. They also weren't
    able to reproduce it on their other systems.
    
    FWIW, Sjaak.

     While I was writing .2, my station was chugging away executing 
    USERAGENT_POST.SCP for the third time, it did not ACCVIO this time but
    I got error about LIB$FREE vm memory error bad block address (beats
    me) but it's working, DDS in my ALL-IN-1 V2.4 is working now. I ran 
    MAIL_DIR_CONVERT, completed fine.
      Now back to ALL-IN-1 V3.0 MESSAGE ROUTER V3.2, what else am I missing
    here? I started DDS from scratch (MBMAN>SET DDS CONFIG/NUMBER=0) and
    from there I did SET REC ENA. I created new UAPASSWRD and laboured over
    again recreating UA,PW etc,etc.
      When I execute USERAGENT_POST.SCP, same error 
      "form useragent not in the library". I made sure that I have the
    right OA$MAIN.EXE image installed (the one after modified A1CONFIG and
    re-linked ALL-IN-1). OA$DDS_PRIME = 1.
      
       PLEH please
       ricardo
     
    
    
        
        
    

Hi,

I think I cocvered this somewhere else in this conference but here it goes
again:

I'm writing about ALL-IN-1 V2.4, as I didn't do it on V3.0 until now.

1.) "Form useragent not found" leads to think, that the DDS code wasn't linked
with ALL-IN-1. This means : Define/SYSTEM/exec OA$DDS_PRIME 1 and relink the
image.

2.) Performing USERAGENT_POST.SCP and MAIL_DIR_CONVERT.SCP

This leads into trouble, if you don't setup the system correctly the first
time, and try it to do more than once, without cleaning up the system in
between.

Please perform the folowing steps accurately :
(For "node" insert your nodename or clusteralias.)

a.) With MBMAN delete the useragent entry (OA$node$ALLIN1).
MBMAN> delete dds ua/name=OA$node$ALLIN1

    With MBMAN add a new useragent entry (OA$node$ALLIN1), following page 3-10 of
the mail management guide. Watch out to that in "OA" is an O and NOT a ZERO
"0". Remember the password you give is not allowed to be longer than 8
characters.

MBMAN> build dds ua/name=OA$node$ALLIN1/pass=shortpw
MBMAN> add dds built

For "node" insert your nodename or clusteralias.

b.) With mbman delete the dds subscriber MANAGER

MBMAN> delete dds subscriber/surname=manager

    With MBMAN add a new subscriber entry (MANAGER), following page 3-10 of
the mail management guide. Watch out to that in "OA" (for the proxy and subid
qualifiers) is an O and NOT a ZERO "0".

MBMAN> build dds subscriber/surname=manager/proxy="OA$node$ALLIN1"
MBMAN> build dds subscriber/subid="OA$node$ALLIN1"
MBMAN> add dds built

For "node" insert your nodename or clusteralias.

c.) With ALL-IN-1 delete the DDSID field in the profil of MANAGER
<form profil/mode=update
(select manager)
{Gold 7} GET ddsid = ""
{return}
{return}
{return}

d.) With ALL-IN-1
<create uapasswrd
<dump_cache

e.) Check that UAPASSWRD is empty:
<form uapasswrd/mode=update
{GOLD L}

(shouldn't return any)

f.) Fill in UAPASSWRD with data you have until now:
<form uapasswrd/mode=add
Commname : OA$node$ALLIN1 {TAB}
Password : shortpw {return}
DDSid : _____________

DON'T touch the DDSid field!
{return}

g.) for area code, orgname  and location check the mail management guide,
p.3-11.

h.) Do it NOW !

<do useragent_post

i.) Check it NOW :

Goto customisation management, third form and use the wonderful ESC "Examine
symbol contents" form: (type in the left row, ALL-IN-1 should display the right
row as follows)

CM3 ESC {return}
#useragent_____________________	    OA$node$ALLIN1
useragent.ddsid[#useragent]____	    2B280A000952F38F1B2F9006CC4000 (on my sys.)
uapasswrd.uaddsid[#useragent]__     2B280A000952F38F1B2F9006CC4000 ( " )

these two lines must match, and if they don't, you didn't perform the steps
above as mentioned, or you have a problem...

also check
profil.ddsid["MANAGER] against
subscriber.ddsid["MANAGER"]

j.) double check it :
<form uapasswrd/mode=inquire
{GOLD L}
{return}

Only ONE entry should appear (OA$node$ALLIN1), and magically the field DDSid is
filled !

{return}

k.) triple check:
MBMAN> show dds ua/name=OA$node$ALLIN1/full

This will show you some additional fields, that useragent_post.scp entered for
you.

MBMAN> show dds subscriber /Sur=manager/full

This will show you some additional fields, that useragent_post.scp entered for
you.

l.) <DO MAIL_DIR_CONVERT
to enter all ALL-IN-1 users into DDS. Be sure, that they weren't in there
before, otherwise, it's like the managers entry, you should delete the
profil.ddsid field from each user, before trying to run this script. (small For
loop will do it, be aware not to delete the managers ddsid field now!)

m.) everything should be ok now...

Perhaps I forgot something, but I'm sure somebody will correct me.

Hope it helps.

Tomas
CSC Munich

    G'day,
    
    Having spend a good few hours on the customers system and doing such
    things as @sys$manager:mb$config and recovering the various components. 
                               
    My helpful friend Darrin Rogers (Mr. Mailbus) checked what version of
    MAILbus was installed it was Version 3.2.  This is a field test version
    and is/maybe (just covering myself) the cause of the problem.
    
    To check do the following MC MBMAN the version is displayed.  If it
    displays MBMAN V3.2-000 (BL5.26) it's the correct kit ident. BUT if it
    displays MBMAN V3.2 it's the incorrect kit inent.
    
    To get further information please see FORTY2::MAILbus_update Conference
    Note #36.1.  I'll keep you posted on the progress.
    
    Sunil
    
    (I have a bit of a :-) now)

    Hi,
    
    Just a bit more the kits available through January and March CONDIST
    releases, for the following products, do not contain the SSB release of
    the software :
    
    		VAX Message Router 3.2
    		VAX Message Router VMSmail Gateway 3.2
    		VAX Message Router X.400 Gateway 2.2
    
    NOTE - This only affects kits available through CONDIST and not those
    available by tape distribution.  The May CONDIST will contain the
    correct versions of these products.
    
    As mentioned please read note #36.1 in the FORTY2::MAILbus_update
    Conference for further details.
    
    Sunil
    
    keep on :-)
    

    G'day Andrew,
    
    >    1) USERAGENT_POST ACCViong from Sunil in the base note
    
    The customer had the wrong version of the CONDIST kit.  He has
    installed the correct version and the last thing he told me was that he
    was getting the following error message after he did the following :-(
    
    1. Stop all the MAILbus components
    2. Recover all the components
    3. Enable all the components
    4. Startup the MAILbus components.
    5. Then run the USERAGEN_POST.SCP
    
    %DDS-F-OPSYSFATAL, Fatal operating system interface error
    -SYSTEM-F-IVLOCKID, invalid lock id
    
    The customer has solved the problem but he is not available until
    Wednesday.  So I'll get as much information as possible to complete the
    story of the Access Violation and the USERAGENT_POST.SCP.
    
    I was going to suggest that he does a MBMAN> create mb to make sure
    that the database for the MAILbus was not corrupted.  Because of the
    incorrect version of CONDIST being installed and eliminating that
    possibility.
    
    Sunil

    G'day,
    
    The customer said he did all that I suggested in recovering the various
    components of MAILbus.  As mentioned in note .10 he kept on getting the
    error message below the ACCVio problem was solved with the correct
    version of MAILbus.
    
    %DDS-F-OPSYSFATAL, Fatal operating system interface error
    -SYSTEM-F-IVLOCKID, invalid lock id
    
    What does it mean ?
    
    The customer put the trace on (gold %) and the problem went away he has
    not had any problems running the USERAGENT_POST.SCP.  Don't ask me why
    the trace got rid of the problem so it appears !!!!
    

    Sunil

Just for anyone else who might hit this problem I had a call
logged here where customer was upgrading to v3 and had not
been using the Mail Directory previously. When doing the 
post-installation task of adopting the Mail Directory they
got the error when running USERAGENT_POST.SCP (tried 4 times):

	%DDS-F-OPSYSFATAL, Fatal operating system interface error
	-SYSTEM-F-IVLOCKID, invalid lock id

He had done a trace and the error occurred once it had called
SUBSCRIBER_CHANGE.SCP and was doing the write change subscriber so it looked
like a problem with the set up in MBMAN. I got him to actually delete the UA, 
delete the subscriber entry for Manager, blank the ddsid for Manager and 
<CREATE UAPASSWRD. Then follow the Management Guide on how to adopt
the Mail Directory after Installation. It all worked fine after that.

One solution.....

Alan Crooks UK CSC.

    G'day All,
    
    Here is an interesting bit of information that may explain why we are
    having some of these Access Violations and unpredictable results.  A
    customer ran the USERAGENT_POST.SCP as per the manual then he ran the
    MAIL_DIR_CONVERT.  The result was that it access violated and he has had 
    many problems with the behaviour of DDS.
    
    I followd the advise in note .4 and it was most helpful in tracking down
    the problem.  What I did in addition to the recommendation was to set a
    trace on to see what files were being accessed while USERAGENT_POST.SCP
    was executing by doing a SET WATCH/CLASS=(ALL,NODUMP,NOMAJOR) FILE at
    the DCL prompt.
    
    I discovered that the DDS$OUTQUE.DAT was being accessed and it
    contained the previous DDSID so there was a mismatch in id's.  See
    below
    
    #useragent                          OA$LRSN0$ALLIN1
    useragent.ddsid[#useragent]         2B280A8000960BE0F29CE920468C0000
    uapasswrd.uaddsid[#useragent]       2B280A8000960BE0F29CE920468C0000
    profil.ddsid["MANAGER"]             21280A8000960BE0F2B7E920468C0000
    subscriber.ddsid["MANAGER"]         21280A8000960BE0F2B7E920468C0000
    <form uapasswrd/mode=inquire        2B280A8000960BE0F29CE920468C0000
    
    It's best to stop DDS and restart it before following .4 this out flush
    the cache (DDS$OUTQUE.DAT).  If this is not possible than do the
    following
    
    MC MBMAN
    
    MBMAN> create dds outqueue
    
         Creates the output queue file for the Directory Service.
    
                                            NOTE
    
                  If you use this command while the Directory Service is
                  operational, it creates an empty output queue file, so
                  results may be lost and users may need to repeat
                  enquiries.
    
    The above is from MBMAN help.  This is not an ALL-IN-1 problem it how
    DDS works.  I will keep you posted.
    
    Sunil

    Hi,
    
    The customer followed the advise I had given him the combination of
    doing MBMAN> create dds outqueue and the advise in note .4 this solved
    the problem.
    
    Interesting thing was that the MAIL_DIR_CONVERT.SCP access violated. 
    The customer had to abort the first attempt because the ALL-IN-1
    Managers account did not have the correct privs. and the customer had
    forgotten to clear out DDS$OUTQUE.DAT.
    
    The customer had had many attempts at creating his DDS enteries and
    failing due the access violation problems.  That's why he had the
    previous DDSID in DDS$OUTQUE.DAT.  The SUBSCRIBER DSAB actually picks up 
    the information from DDS$OUTQUE.DAT, as I have said this is not an 
    ALL-IN-1 problem but the way Mailbus (DDS) works.
    
    I hope this will be helpful in explaining the problems of access
    violation in part.  Any other insight would be most welcomed.
    
    Sunil

HI ALL

I still seem to be having a problem similar to .0 but there is a slight 
difference. I can seem to get it to run when I follow the instructions 
detailed in .4 when I run it interactively by logging into the ALLIN1 system 
manager's account.

However I want to run this as a command procedure for various reasons, but I 
seem to get an access violation.

Everything else is perfectly okay with regard to the user agent and the 
subscriber "MANAGER" entry and they never seem to get touched.

I really urgently need to have this problem resolved.  I have spoken to the CSC 
about this and am following their instructions by posting here.  There is a
serious customer impact potential here.

Attached are the ALL-IN-1 commands that are being executed and also a copy of 
the trace.

I got the trace by putting the ALL-IN-1 commands in a script file and 
running this script from within ALL-IN-1.

Also included is a trace from SET WATCH FILE/CLASS=ALL.

Thanks in advance,
Kieran

***************************************************************************

600 lines of trace removed to IOSG::NOTES$LIBRARY:ALL-IN-1_461-18.LOG

Graham

***************************************************************************

    Hi Kieran,
    
    Have you seen replies .16 and .17 ?  They contain the missing bit's
    in .4.  I have not got the time to go through the logfile that you have
    attached.
    
    Basically the access violation occured because the DDS ID in UAPASSWRD
    and in the DDS database were different.  The INQUE and OUTQUE .dat's
    were the cause of the problem.  Please see the above mentioned replies
    and if you still have no luck let us know.
    
    Regards,
    
    Sunil

Hi 

Thanks for the reply.  Yes I have tried out all the previous replies and I still
seem to have no success. I've tried all the advice up to reply 17.

I don't believe that the DDS IDs in the UAPASSWRD file and the DDS database 
were in fact different - I checked this!

What do you mean the INQUEUE and the OUTQUEUE .DAT files were the cause of the 
problem?  I did do a DDS> CREATE DDS OUTQUEUE as suggested but this seemed to
have no effect.



Regards
Kieran

    Hi Kieran,
    
>What do you mean the INQUEUE and the OUTQUEUE .DAT files were the cause of the 
>problem?  I did do a DDS> CREATE DDS OUTQUEUE as suggested but this seemed to
>have no effect.
    
    What happens is that the DDS database may have 1000's of entries and
    searching for a user can take time (index as well as sequential). 
    Entries are put in a cache and the files used for caching are called
    DDS$OUTQUE.DAT and DDS$INQUE.DAT.
    
    The DDS$TIDY housekeeping procedure when it runs clears the cache and
    creates new files.
    
    Now looking at your logfile I could not find the set watch trace part
    from the lines:
    
   > Here is SET WATCH FILE trace...
    > %XQP-I-FUNCTION, FIB contents:<CR>
   >          00000000 00000000 09BE0000 0000000B 00000000 00000000 00000000
   > 	     0000000 00000000 00000000 00000000 00030000
    
    Unfortunately right now I am out of ideas, however if I think of
    something I'll post it here.  By the way if you have found the solution
    please let us know.
    
    Sorry it's taken time for me to get back to you I have been very busy.
    
    Regards,
    
    Sunil

    Hi All,                         
    
    Please find a copy of a letter that was sent to me by a customer that
    expresses a view that I sympathise with too a large extent.  This EM
    will be forwarded as a CLD priority 3 to engineering.
    
    DDS may or may not be an issue in a PFR BUT whatever procedures are put
    into place should address the customers concerns.  I have come across a
    number of customer that have expressed rather negative opinions about
    this procedure.  However, this is the first customer to actually put
    his fingers to the keyboard and type up something as well as ask for
    the call to be CLD'd.
    
    The cause of the problem at this site was the mismatch of the DDSID's
    as discussed in my reply to this topic.  Since this has now been
    offically raised, I hope we can improve the quality of our product in
    this area.
    
    Regards,
    
    Sunil
    
    -------    LETTER FOLLOWS ------
    
    PIONEER CONCRETE (N.S.W) PTY. LTD.,
    
             RE: DEC CALL #QA2063 - CHANGING ALL-IN-1 MAIL DIRECTORY SET UP
    
    
    Thank you for your assistance in resolving our problems.  As you are
    submitting an SPR, I felt it was important to clarify a few points 
    regarding our ALL-IN-1 installation and subsequent attempt to implement the
    change to the mail Directory Setup.
    
    Firstly, I believe the ALL-IN-1 setup on our MicroVax 3100 model 90 is
    entirely standard, with no customisation and no variations from the standard
    "Out of the box" VM$INSTALLed version.  While on the subject, I must say 
    that I was disappointed that is took six attempts to install ALL-IN-1 in 
    the first place, because of an obscure "can't parse file spec" message 
    caused by a missing logical CDA$LIBRARY; even though we were not installing
    CDA support.
    
    Since we were installing a standalone ALL-IN-1 system, we saw no need
    to install the mail directory support.  Subsequently, my colleague Liliana
    Lora undertook to evaluate Digital's TEAMLINKS product, and Digital's Paul
    Hummerston advised us that the change was required.
    
    Liliana and I together sat down to make the change.  It seemed a fairly
    simple exercise to follow section 3.3 of the "Mail Management Guide" (P/N
    AA-KX88C-TE), which included a relink of ALL-IN-1 described in the "ALL-IN-1
    Management Guide".
    
    We set the OA$DDS_PRIME logical and followed the manual instructions 
    EXACTLY.  I have SETHOST logs documenting everything that we did, should 
    anyone care to check.  There were two of us watching for typos etc, and I 
    have no doubt that we followed the required procedure.  It was surprising 
    therefore to be confronted with a "stack dump" when attempting to perform 
    the second last step, running "<DO USERAGENT_POST.SCP" from within the 
    ALL-IN-1 manager account.
    
    One problem we ran into after contacting you and attempting the change
    a second time was that we could not re-install OA$MAIN.EXE because of a 
    "Global Page Table Full".  This potential problem is also not documented 
    anywhere in the relinking instructions.  It caused some problems for our 
    users, as we had been advised that relinking was a "no user impact" 
    procedure.
    
    Liliana and I were extremely frustrated spending 10 hours over the last
    week trying to follow a four page, 7 step procedure which should have taken
    no more than an hour.  During this time, a number of users commented on the
    message "The User Agent is unknown in the mail directory" which seems to 
    appear unnecessarily in some circumstances.
    
    I concede that Pioneer Systems management in general and myself in
    particular may have committed some error or other during either the 
    installation or the subsequent mail directory change.  Nevertheless, I feel
    that the whole procedure was badly designed, with a lot of redundant 
    keying, thus increasing the likelihood of error.  It was probably better 
    suited to a batch job or background procedure, where the 3 or 4 parameters
    are entered on a form and then the user receives a log at the end.  Perhaps
    the frequency of this operation precludes this, but surely we were only 
    duplicating what would have been done  during a VMSINSTAL with the Mail 
    directory activated?
    
    My final comment is that while I appreciate ALL-IN-1 is a sophicsticated
    product, it does not seem to present the quality, reliability and ease
    of use from a System Manager's perspective that I have come to expect from
    Digital software products.  "Stack dumps" in particular are not the sort of
    events which inspire confidence in a product!
    
    Thank you again for your assistance in this matter.
    
    Edward Kerr