Conference lassie::ucx

5255.0. "?SMTP access violations: Is there a cure?" by RICKS::OPP () Thu Feb 20 1997 21:47

    	When I queried my site's MIS group regarding process dumps that
    I frequently encounter when trying to send e-mail via SMTP, they 
    told me:
    
    	SMTP is not supported on our VMScluster because of problems
    	with access violations.  
    
    The RICKS cluster is an OpenVMS mixed-architecture, mixed intercon-
    nect cluster running V6.1. But, I don't expect access violations when 
    using SMTP and never encountered them when I had V3.3 of UCX installed 
    on a single processor VAXft System running OpenVMS V6.1.  This prompts
    some questions:
    
    	1. Is UCX V4.0 supported on VMS for Alpha V6.1?
        2. Is there a patch or work-around for these access viola-
    	   tions?
        3. Certainly we don't tell revenue paying customers what my
    	   internal MIS group told me, do we?
    
    Any information which may reduce or elimiate this problem with SMTP
    would be appreciated.
    
    Greg
    
    
    --------------------- Attached MAIL message ----------------------------
    
From:	RICKS::OPP "ghettoblasters disintegrating  18-Feb-1997 1247" 18-FEB-1997 12:49:34.28
To:	SNAX::CSD
CC:	RICKS::OPP
Subj:	? Is the correct version of SMTP installed on my workstation??

    I ask, because it seems like whenever I try to use SMTP to send e-mail,
I get something like:

8 lines written to file TAZ$:[OPP]MAIL_230001BB_SEND.TMP;1

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000, 
PC
=00000000, PS=0000001B

  Improperly handled condition, image exit forced.
    Signal arguments:   Number = 00000005
                        Name   = 0000000C
                                 00010000
                                 00000000
                                 00000000
                                 0000001B

    Register dump:
    R0  = 0000000000000001  R1  = 000000000084E38C  R2  = 000000000081E0A0
    R3  = 000000004D4E0510  R4  = 009B01224C18864C  R5  = 0000000000000000
    R6  = 0000000000000000  R7  = 0000000000000000  R8  = 0000000000000000
    R9  = 0000000000000202  R10 = 0000000200000002  R11 = 372D3624000000F0
    R12 = 000000000032CFE2  R13 = 0000000000000007  R14 = 18864C000000004D
    R15 = 0000000000000005  R16 = 0000000000000000  R17 = 000000007FB2C3B0
    R18 = 0000000000000001  R19 = 0000000000000000  R20 = 0000000000000001
    R21 = 000000007FFF0140  R22 = 000000000084E384  R23 = 0000000000108108
    R24 = 0000000000108108  R25 = 0000000000000002  R26 = 4E05100000000000
    R27 = 0000000000000000  R28 = 0000000000000000  R29 = 000000009B01224C
    SP  = 000000007F914D8B  PC  = 4E05100000000000  PS  = 0B0000000000001B

Ugly, to say the least.  Thanks,

Greg

badge 65099
cost center 4YK

    Greg,
    
    I see no compatibility problem with your UCX and VMS versions.  Do you
    by any chance have the SMBSRVSHR logical defined on this system?
    
       $ SHOW LOGICAL/TABLE=* *SMBSRVSHR*
    
    You have a virtual address with a zero's and this was the behavior seen
    when the SMBSRVSHR logical was being defined.
    
    -Rick

    	Yes, it is defined:
    
    (LNM$SYSTEM_TABLE)
    
      "SMBSRVSHR_TV" = "SMBSRVSHR"
    
    For what purpose, I don't know.  So, the correction would be to 
    DEASSIGN SMBSRVSHR?  
    
    Greg