Conference hydra::axp-developer

3552.0. "Scientific SW Intercomp - Point 26862" by KZIN::ASAP () Mon Apr 28 1997 04:01

    Company Name :  Scientific SW Intercomp - Point 26862
    Contact Name :  Martin Watson
    Phone        :  44 1784 430030
    Fax          :  44 1784 431889
    Email        :  [email protected]
    Date/Time in :  28-APR-1997 08:00:45
    Entered by   :  Ian Chamberlin
    SPE center   :  REO

    Category     :  unix
    OS Version   :  4
    System H/W   :  


    Brief Description of Problem:
    -----------------------------

From:	RDGENG::MRGATE::"RDGMTS::PMDF::mail.dec.com::Gaillat" 25-APR-1997 17:25:47.24
To:	RDGENG::ASAP
CC:	
Subj:	ESCALATION: POINT 26862 , Company  TO ASAP READING:      Scientific SW Intercomp Ltd

From:	NAME: Thomas Gaillat <[email protected]@PMDF@INTERNET>
To:	NAME: '[email protected]' <IMCEAX400-c=US+3Ba=+20+3Bp=DIGITAL+3Bo=SBUEURMFG+3Bdda+3ASMTP=asap+40reo+2Emts+2Edec+2Ecom+3B@mail.dec.com@PMDF@INTERNET>

Hello - 

POINT Log Number	26862
Company Name 	Scientific SW Intercomp
Engineers name	Martin Watson
Telephone Number 	44 1784 430030	
Fax Number		44 1784 431889
E-mail Address	[email protected]

Operating System, Version unix 3.2 4.0	
Platform	Alpha		

Problem Statement		


Problems on Alpha OSF/1 V4.0



Problem 1:

A program compiled under OSF/1 V3.2 runs quite happily
on another Alpha (OSF/1 V4.0 386). However, when the same
program is run on a platform with OSF/1 V4.0 564 the program
mis-behaves.

The folowing messages get generated:

"unable to unmap(rpc_num, rpc_ver, tcp)"
after which the process communications and startup begin to fail.

"unaligned access pid=21075 va=.........."
this message gets generated repeatedly until the application terminates
after several seconds. The va value is the only value which changes.

Simple client server application to demonstrate rpc behaviour appears to
run OK.

Please note that this is a standalone (no network card) workstation
although the workstations on which the softwrae is running do have
network cards installed.

Problem 2:

We have the line in a script which runs happily on OSF/1 V3.2 but
fails under V4.0:

egrep '^[*]CONFIG' <filelist>
the * cannot be forced to be treated as a standard character under V4.0
Is this a known bug?

Many thanks for your assistance

Reagrds,
Martin Watson




In replying, please use [email protected]




-----------------------------------------------------
Thomas Gaillat
Pre-Sales Technical Support Associate.
Fax: DTN 822 4445
Phone : DTN 822 4318

European Customer Service Centre      
Digital Equipment International B.V
-----------------------------------------------------
For Technical Enquiries,use our FREEPHONE number
 or E-Mail: [email protected] 
 Our FREEPHONE numbers are available on request.
-----------------------------------------------------


RFC-822-headers:
Received: from reoexc1.reo.dec.com by rg71rw.reo.dec.com (PMDF V5.0-7 #15552)
 id <[email protected]> for [email protected]; Fri,
 25 Apr 1997 15:07:48 +0100
Received: by reoexc1.reo.dec.com with SMTP
 (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63)
 id <[email protected]>; Fri, 25 Apr 1997 14:34:31 +0100
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63

Martin,

	I think your second question is a known problem with the C shell on
Digital Unix 4.0x. It manifests when there is a '*' followed by an unquoted *
(eg a file list). Somehow the '*' gets lost. 

	This is fixed in a later version of Digital Unix (not yet available). As
an interim workround you could try using a diferent shell, eg Korn shell.

Regarding your first question, I really need more information to understand the
unmap message. Do you know where the message originates, I can't find it in any
of the common header files or libraries.

The unaligned acesss message is what it says. The Alpha architecture requires
data types to be aligned on natural boundaries. Your application is trying to
access data which is not aligned, and thus the operating system is having to
fix up the accesses. The application will still use correct data, but the fix
ups will cause serious performance degradation, and of course, you get the
annoying messages. I don't know any reason why your application's data
alignment should change between revision's of Digital Unix, unless you were
making an assumption which is no longer valid. It may be that the problem is a
result of (or tied in with) the rpc unmap error, and I think you should
concentrate on this first.

regards,


Ian Chamberlin,

Digital Equipment Co, Software Partner Engineering.