[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

3547.0. "SPX speed breaks X-applications." by YZR500::OMELEY (Mirth and fun growing fast and furious...) Tue Oct 30 1990 02:29

    Hi all,
    
    	a quick question regarding the SPX platform.
    
    Background: I have a customer that is using a 3rd party database
    product called Finder (from Finder Corp) and they find that it is
    failing on any SPX machine in their MI-Cluster, if run locally.. If run
    using DECNet transport from a remote node (the 6000-460 boot node for
    example) or on a non-SPX workstation, it works fine. The SPX machinery
    is VS3100/38's and a VT1300. My feeling is that it is a timing problem
    with the client, somewhere they are missing events or are expecting an
    event sequence that is not occuring. The failure occurs when the
    program is starting and trying to display a menu bar.
    
    Question:
    	Has anyone else seen timing/speed related problems in applications
    with the SPX hardware ? (And just to make sure, are there any problems
    in this area with the server ?)
    
    Thankyou in advance for any pointers/help.
    
    	Rob
T.RTitleUserPersonal
Name		DateLines
3547.1What does "fail" mean?SITBUL::MCCARTNEYTue Oct 30 1990 15:079
    What do you mean by "failing"?  Is it not producing the expected
    numbers?  Is it giving an error message?  If so, is it from the
    package, layered product, DECwindows, X, or operating system?  What is
    the error message?  What version of VMS are they running?
    
    Basically, it's hard to give any hints on what might be happening
    without a description of what is happening.
    
    Irene
3547.2Where is it run and where does it display?DECWIN::FISHERI like my species the way it is" "A narrow view...Tue Oct 30 1990 18:506
    Also, you are talking about a VT1300.  Do you mean they run the client
    on the VS3100 and display it on an X terminal?  If so, that should have
    nothing at all to do with the SPX in the 3100.
    
    Burns
3547.3More info.YZR500::OMELEYMirth and fun growing fast and furious...Wed Oct 31 1990 02:5143
    Whoops, a little bit vague ...
    
    VMS V5.3-1. MI Cluster consisting of 3 VS3100/38 SPX (running the
    patched server that addresses the DECW$Server failing due to several
    user Quits, (cscpat_0183 I think)), workstations, 2 VS3100/30's (8Pl
    Colour, GPX) and a 6000-460 boot server. They have an application that
    is run on the cluster named Finder, this is some X-interface
    application to an ORACLE database. They are also testing a VT1300
    (using the EWS sftwr), which boots from the 6000-460 as well.
    
    They are having an accvio in the application program, when it is run
    locally on the SPX workstations, accessing the cluster-available
    database. If it is run on the 6000-460 (having done a set
    disp/node=<spx_node>/cre/super/trans=decnet) the program will not
    accvio.
    
    If the program is run on one of the clustered non-SPX VS's it works Ok,
    and they have also found that the VT1300 (EWS running on a SPX-kitted
    3100, ref: Note 3299 this conf) will cause the problem to occur in the
    application when the client is run from the 6000-460, via a set display
    to the VT1300.
    
    If the application is run using access SQLNET to the database (rather
    than Cluster) it will run Ok. The underlying point being that if the
    application is spead up, it fails. Slow it down using network access to
    the database or to the display server and it will work. The exception
    being the VT1300 having a network display link, but this is possibly
    due to ELN vs VMS scheduling/overhead.. etc, basically it is _real_
    quick.
    
    If it is run under the debugger then it works. so it appears as if
    "slowing it down" fixes. The failing PC is 008e1d44 being in a module 
    wi_define_menu (rel PC 17c) and is a CALLS instruction (calls
    #^01,@l^00a6f4e8).
    
    Like I mentioned in .0, I believe that it is an application problem to
    do with event/widget processing.
    
    Thankypu both for your input to date.
    
    Rob