Conference iosg::all-in-1_v30

    Ah ok I see now
    
    What version of ALL-IN-1 (v3.0 or v3.0-1) what value of OA$DDS_PRIME
    etc...
    
    I get %OA-F-VMGETFATAL, LIB$GET_VM failure, 20 bytes at 0015A64E -
    OASAR#1
    -LIB-F-BADBLOADR, bad block address
    
    After I realised that the script should be called EPO2 not EPO!
    
    Regards,
    
    Andrew.D.Wicks

    
    You will get an ACCVIO if you don't have DDS support included in your
    link of ALL-IN-1. This is because the location OA$GL_DDS_SEARCH which
    backs OA$DDS_SEARCH_SCOPE won't exist and is declared WEAK so it
    appears as address zero in the special symbols table.
    
    This would lead to an ACCVIO at VA=00000000 though - which is NOT what
    you are getting. It might be closely related, but I'm not convinced. You
    could help by determining where the PC was when the ACCVIO occured and
    also post the version and DDS setting as Andy requested. It would be
    even better if you could test it with a debug version of ALL-IN-1 and
    give the whole stack traceback showing all the calls active at the time
    of error.
    
    I couldn't produce the VM error which Andy got, but maybe I don't have
    DDS set up properly. Andy... Can you reproduce this error reliably?? If
    so, it might be worth getting in touch so we can track it down.
    
    Paul.
    

    Paul,
    
    ACCVIOs outside the Mail/DDS subsystem I can *always* reproduce. I've
    never seen one in DDS (:==:) This one was in the Kernel code
    as i'm sure you spotted.
    
    Let's wait until we get the information back from the customer.
    
    Regards,
    
    Andrew.D.Wicks
    
    

    Yeah...
    
    OADDS.B32 is a part of the IOS kernel - isn't it? :-)
    
    Funny - I can't quite make out the authors and maintainers names!
    
    
    
    Cheers,
    
    Paul.

    I sent your replies back to him, and he wrote back:
    
    
    	As for the information:
    
    -	OA$DDS_PRIME = 1
    
    -	DDS is linked into ALL-IN-1, and "conventional" access (GOLD-M)
    		works fine
    
    -	running V3.0 (-1 soon, but not yet)
    
    
  Monica
    
    

    Monica,
    
    Good so it's not DDS not being linked in ...
    
    Over to you Paul (:==:)
    
    Regards,
    
    Andrew.D.Wicks

    
    I think that this is a BUG in the OADDS code present in V2.4 AND V3.0.
    
    More details as they come to hand...
    
    Paul.

    Any more on why this might be a bug?
    
    Monica

    
    Well Monica...
    
    I've got another problem (a CLD in fact) which is ACCVIO's in a
    DDS environment because of a problem in the SUBSCRIBER DSAB.
    
    Now, I can't as yet guarentee that this is the exact same problem but
    I'd say there is probably a 95%+ chance of it being the same.
    
    Support (i.e. yours truly) is working on a patch for this other
    problem.
    
    I've been out of the office for a week, but I expect (not commit) that
    a patch to be available in 2 weeks or less. The hold-up has been
    getting a test plan so we can check that its fixed properly. These
    problems are rarely exactly reproducible.
    
    I will run a test on your problem in the near future just to verify
    that it is the same, but first priority is to get a fix rolling through
    the appropriate channels. If this problem is different, we'll have to
    look at whether we are able to include a fix at the same time.
    
    I trust you can sit tight in light of this information?
    
    Paul.

    Yes, this is just fine, thanks!
    BTW, I just just got a note from Bob (our customer) on this:
    
    
     ----------------------------------------------------------
    
    	Hi Monica !
    
    	You wanted me to break down the Access Violation problem.  How 
    about 3 lines total!
    
    	GET #EMDADDRESS = "X"
    	MAIL TO "Joe User                             ( USER.JOE )"
    	OA$SCL_INIT,,,OA$SCROLL_DATA_SET
    
    	If you remove or change any of these three lines, then ALL-IN-1 
    won't blow up.  The problem seems to be especially caused by the 
    OA$SCL_INIT.  It can't take the MAIL TO specification along with the 
    #EMDADDRESS at the same time!
    
    	If you take out the OA$SCL_INIT,  both addresses are registered, 
    even though initially it looks like only one is taken.  You have to 
    Re-read the memo to see both.
    
    	The MAIL TO is part of the DDS$INDEX form execution that can't be 
    avoided.  The other problem is that if I blank out the #EMDADDRESS, I 
    get a dumb message that the address is "not known".  This is the actual 
    root of the problem.
                     
    Bob
    

    
    OK... after more investigation...
    
    This is NOT the same problem that I'm working.
    
    The problem is caused by the fact that the scroll region and
    MAIL$SCL_FUNCTION data-set are being closed by the OA$SCL_INIT function
    call. This is DURING an OA$SCL_RETURN function call which is in
    progress when the MAIL address validation code invokes the CMU script.
    
    When the script returns back to the OA$SCL_RETURN function call, the
    previous scroll and DSAB context have been deallocated because the
    OA$SCL_INIT performs an implicit OA$SCL_EXIT. Therefore, it tries to
    use context information which has been deallocated [and the memory may
    have been re-allocated]. If you are lucky, this means an ACCVIO -
    otherwise it may mean VM corruption as Andy got.
    
    I've looked at the normal GOLD/M logic for ALL-IN-1's EMHEAD form and
    it seems to me that the difference is that this is not being invoked
    through the CMU mechanism.
    
    In fact, in this CMU environment, there is no need to re-initialize the
    scrolled region as it is probably still active. Just exiting the script
    without trying to do anything to the scrolled region should be
    sufficient for it to perform normally.
    
    So... "This behaviour is a restriction of current releases of ALL-IN-1".
    
    Don't hack the scrolled region or MAIL$SCL_FUNCTION DSAB from a CMU
    script!
    
    Paul.
    
    P.S> And a big thanks to Alan Cottingham too - for his help in
         investigating this problem.
    
    

    my thanks to all; I will let Bob know....
    
    Monica