Conference help::decnet-osi_for_vms

>They would like Digital to fix their OSAK problem and they are willing to pay
>per call rate to do so.  My manager requested that I place this request to see
>if there is any one within Digital is willing to tackle a problem like this. 

hahahahahahahahahahahahaha.  That's a good one Alan.

I doubt you'd find anyone willing to touch extensions with a 10 foot, no make
that a 20 foot pole at this point.

>They dont want to do this as the applicatiuon may not run under VMS 6.x.

Actually, unless the application has some VMS version specific dependencies
outside of OSAK, upgrading would probably be a good thing to try.  The version
of OSAK V1.1 that's available (assuming it is OSAK V1.1 that they are using) on
the current versions of DECnet/OSI and DECnet-Plus is basically the same version
that shipped with extensions (and in fact, predates extensions by more than a
few years).  Doing this would at least eliminate the possibility that you were
encountering one of the *many* lower layer problems that existed in extensions. 
Of course, since OSAK V1.1 isn't supported anymore on any platform, you're still
going to find it difficult to get engineering support regardless of platform.

>The customer admits it may be the Application

That could be a real problem.  I've seen at least one other situation where the
nature of the application design was such that it simply would not work under
heavy load with OSAK V1.1; and there's really nothing to be done about it.  OSAK
V1.1 design had certain contraints (as does all software for that matter) which
precluded anything but an application change.  That may not be the case here,
but there is not really enough data on the application to say.

Best of luck.
--Scott

Wow.  Extensions.  I'm not sure you'll find anyone willing to take a look at
that.

Couple of comments and questions:

I think the suggestion of upgrading to a currently supported version of
DECnet/OSI should be looked at further.  The version of OSAK that the customer
is probably using (V1.1) is basically the same on 6.3 as it was on Extnesions
(excepting bug fixes).  So, unless the application itself has any specific
dependencies on the particular release of OpenVMS, upgrading will eliminate the
possiblity that you are dealing with one of the many lower layer problems that
existed in extensions.  If they are willing to pay per-call rates, it seems like
they'd be willing to borrow a 3100 from somewhere to give this option a try.
The only problem with this is that since OSAK V1.1 isn't supported on any
platform anymore, if it is a problem within OSAK, it's not going to be fixed.

>logical links time out.

Who's timing out the link?  The application or OSI Transport?  I wouldn't expect
OSI Transport to time out the link unless the PLC wasn't sending AK's.  On the
other hand, many applications for this type of thing have "built-in" timers.

>But the old channel is hung and cannot be deassigned.

How do they determine this?  Presumably the application will try to close the
OSAK channel associated with the particular PLC - what happens?  Does the
operation hang?

>They would like Digital to fix their OSAK problem

First would be to determine if they are having a problem with OSAK or a lower
layer problem.  if it's a lower layer problem, they don't have any choice but to
upgrade to a supported version.  If it's really an OSAK problem, then they don't
have any choice but to migrate to the SPI interface available with OSAK V3.0.

>The customer admits it may be the Application

That's going to be the tough part to sort out.  I've seen one other application
which was designed such that it flooded OSAK with outbound data over a slow
datalink.  The design of OSAK V1.1 is such that inbound data may not be
processed if OSAK is still trying to send outbound data and it's backed up.
A couple of attempts were made to resolve this, but as it was a basic design
issue within OSAK, it never was resolved to anyones satisfaction.  If the
customer is willing to admit that this may be an application issue though, they
may be willing to examine migrating the application to SPI and a supported
interface.  Something to think about.

--Scott

         
    Quick question, what is the customer running above OSAK, i.e. which
    product.  Is it a digital product like DEComni?  Or is it a 3rd party
    product like MMS-EASE from SISCO, could be that they are using
    CIMplicity from GE-Fanuc?  What profile is he using, i.e. is
    his PLC talking MAP/MMS.
    
    Who is the customer, GM, Ford?

    There must be a product involved because nobody writes a full protocol
    themselves.

    It is very probable that the protocol above will have to be changed,
    I'm speaking from experience with DEComni, where we've done lots of
    changes to correct our OSAK usage problem.
    
    Migration should not be a to big an issue.  Perhaps, if they are not
    already using it, sell them DEComni-API and DEComni-MMS.  This is
    sucessfully running in many plants.  We had some of the above issues
    but when OSI, OSAK and DEComni put their heads together (IPMTs) the
    problems were all worked out.
    
    Chris

>Wow.  Extensions.  I'm not sure you'll find anyone willing to take a look at
>that.
    
    Wow. Extensions. I'm not sure that you'll find anybody *ABLE* to look
    at that. Certainly in REO we archived our extensions baselevel several
    years ago. By way of comparison, PSI V4.3 (Phase IV) only hit the tape
    racks a few weeks ago.
    
    Even if you can get someone to look at it for them and they find
    anything other than a simple config problem, they are extremely
    unlikely to get a bug fix: it just couldn't be done without someone
    restoring the archived release and working on that (at least if my
    experience in REO is anything to go by).
    
    If you explain this to the customer, perhaps they might consider going
    to the latest releases (if they jump, a long jump is probably less
    painful than a short jump which we *know* will land them in buggy
    code). V7.1/V7.1 is what they should aim for.
    
    The longer they stay at their current release. the longer they will
    have to pay per-call rates to be told "It's a bug and thanks for the
    money".
    
    Antonio

I got the answer I expected, my manager just wanted to make sure.

The customer has two DECnet extensions systems.  Each running a differant OSAK
application.  One fails and the other does not.  Both talk to PLC's on the shop
floor.

The customer went out and purchased DECnet OSI 5.6B from Digital archives
(apparently we still sell it).  I'll make sure he has ECO12 then he is on his 
own.    

It looks like there were some channel deallocation issues fixed in DECnet
extensions then more later in one of the ECO's for DECnet/OSI 5.6B.
  

Alan