Conference noted::dnu_osi

RFC1006 is identical (literally) between DECnet/OSI V4.0A and V3.2B.

The real difference is that XTI is not thread-safe in V3.x but is 
thread-safe in V4.x.  Also, the kernel parts of XTI were rewritten
in V4.0 to support XPG4.

Hi Matt

You thing that it can be related to the rewrite of the xti. By the way , 

which kernel parts are modified.

the osi-application is statically linked with -losak -lxtiosi -lxti under

Digital Unix 3.2B .It run as i said perfectly under Digital Unix 4.0B

Not under Digital Unix 3.2X. 

Do you know any answer . Is it a kernel-related problem . How can find it out

by using a debugger.

Ahmet

Is the application linked with pthreads?

He's using the CMA version of OSAK that was done for the OSI Transaction
Processing project.  Does that tell you enough?

Hi Matt ,

I was at the customer side today , i found out that the problem is also existent

under Digital UNIX 4.0B . So i have to reformulate my question .

The application ois-tp is multithreaded , used to use the cma-safe version of
the OSAK specially designed for the OSI-TP.Now we are using the standard OSAK
which comes with DECNET OSI (also non-thread safe ) . we link with the 
 cc -l osak -lxtiosi -lxti o .The OSI-TP server which i build with the same 
 cc -losak -lxtiosi -lxti under Unix 4.0B works perfectly. 

I suspect that the xti-library under 3.2X causes problems .

I tried to use the sharable libraries like libosak.so , libxtiosi.so , 

and libxti.so to link my SERVER image against , i was completely succesfull.

I think , it is not a kernel-related problem , rather a xti-problem .

Dou you know any serious known bugs under Digital Unix 3.2c

Thanks 


Ahmet

If the difference in XTI between 3.x and 4.x is that in 4.x XTI is thread safe
and in 3.x XTI is not, then why aren't you using the thread safe OSAK on 3.x?

As I recall, the special CMA OSAK simply jacketed the XTI calls with a global
lock, since apparently from what Matt was saying XTI didn't do this itself on
3.x, so it makes sense that OSAK would have to.  So, if you insist on using a
non-thread safe OSAK on 3.x XTI which also isn't thread safe, why are you so
surprised that you're having problems?

--Scott

Hi Scott 

I do still use the cma version of the osak library under UNIX 3.2X

 
 If i build the osi-tp with the static libraries under UNIX 3.2X 

 , it hangs under heavy load both on the Digital UNIX 4.0B and Digital Unix

 3.2X .

 If i build the osi-tp with the shared libraries like libosak.so , libxti.so

 , libxtiosi.so under Digital UNIX 3.2X  , the application run under Digital

 UNIX 4.0B perfectly.

 How can you explain this.

 I suspect XTI-library under 3.X for the problem.

 Thanks

  Ahmet

 

It sounds to me like you need to use the OSAK CMA library on 3.2x, because it
provides the thread safety that XTI doesn't.  On 4.0 you can use the standard
OSAK library because XTI is thread safe.

Hi

we use the osak_libray (the standard) , because Siemens corrected the problem

with a-acsocciate-response (no reason given ).

Ahmet

Do you have any suggestions

 Thanks

>Do you have any suggestions

Yes.  It's still not clear from your responses what your problem is.  It would
appear to me that you have a way to make this work on both platforms.  So what's
the problem?

Let me ask this - if you use the OSAK CMA library on 3.x, does it work on 3.x?
If you use the standard shared libraries on 4.0 (linking under either 3.x or
4.0), does it work on 4.0?

--Scott

HI

The SERVER built on the 3.2 runs both on the 4.0B and 3.2 .

The problem is that the customer has a benchmark program , which fires 10

Initiators at the same time on our machines which communicate with the BS2000

Siemens-Mainframe) . The data-flow for every application is the following


Digital UNIX                               Bs2000 -RESPONDER


Begin-dialogue (unconfirmed)---------->     

SEnD 4Kbyte DATA    ------------------------> 

 GRANT-CONTROL      ------------------------------->

                    <--------------------------  32KByte  DATA


                    <---------------------------- 32 Kbyte Data

                    <------------------------------- 20 KByte DATA

                    <------------------------------  end_dialogue

  close-dialogue


The initiator-applications are running in the loop until they fineshed

 with the time-limit (alarm-signal-call ).


THE PROBLEM WE HAVE IS : THIS TEST IS RUNNING DIFFERENTLY ON THE UNIX

MACHINES.

THE OSITPCM-SERVER IS HANGING UNDER DIGITAL UNIX 3.2X , CONSUMES A LOT OF THE

CPU_TIME .


 BOTH IF I BUILT A OSITPCM SERVER UNDER UNIX 4.0B BY USING THE LIBOSAK , 

 LIBXTI and LIBXTIOSI ( SHARED OR NON-SHARED ) , IT RUNS WITHOUT HANGING

 DURING THE TEST .


 THE QUESTION IS WHY THIS DIFFERENNCE.

 
 WHO IS RESPONSIBLE FOR THAT HANGER UNDER 3.2X.

 
 I LOOKED WITH DEBUGGER (LADEBUG ) ON THE 3.2X SYTEMS TO FIND WHICH THREAD

 IS RUNNING , FOUND OUT THAT "PI_THREAD" IS HANGING IN THE CALL osak_select.

 
 I LOOKED IN THE OSITPCM_DEBUG NOTES CONFERENCES , FOUND OUT THAT SIMILAR
PROBLEMS WAS ALSO EXISTENT WITH LARGE DATA TRANSFER UNDER OSF1 .


NOW , THE QUESTION IS WHAT IS RESPONSIBLE FOR THE PERFECT BEHAVIEOR 

UNDER 4.0 . 

1- IS IT THE NEWLY REWRITTEN XTI LIBRARY

2- ARE THEY THE NEW XTI-RELATED KERNEL MODULES

3 - IS THE NEW OSAK


THESE ARE THE MATTERS WE HAVE TO GIVE A ANSWER TO THE CUSTOMER.

THEY HAVE 85 ALPHAS FROM RUNNING 3.2X . 

THEY ARE RELUCTANT TO MIGRATE TO 4.0X BECAUSE OF THE NUNMBER SERVERS



THANKS

What is this with all the capital letters?  Reminds me of the what I was told
the British approach to someone that doesn't understand something.  Repeat it,
but SPEAK LOUDER.

You are contridicting yourself.  First you say:

"The SERVER built on the 3.2 runs both on the 4.0B and 3.2 ."

and then you say:

"THE OSITPCM-SERVER IS HANGING UNDER DIGITAL UNIX 3.2X "

So which is it?

Hi

Sorry for the capital letters , the caps lock was not functioning properly on
that worktstation.

When i mean that the server are running on both systems , i mean they run 
on those systems with the example programm which are very simple programms

The server ositpcm hangs under Digital Unix 3.2X under the conditions i
described in .11 .The server under Digital Unix 4.0B does not hang .

I also took the server which was generated under Digital Unix 3.2X (linked

 with the libraries from Digital Unix 3.2X) , run it on a Digital Unix
 4.0X , it hangs also .

 I only have success with a server compiled , and linked under Digital Unix
 4.0

 Ahmet