APA makes the LUM License manager unavailable

[Jerome Bathias]

When installing APA and
LUM (license mgr for CAD isv) on HP11, LUM does no longer work due
to a pb in the DL_ATTACH_REQ primitive (dlpi package). LUM returns a NULL
information when requesting the id of the system.

According to the LUM dev team, when APA is installed, the request primitive DL_ATTACH_REQ fails.
The DLPI (Data Link Provider Interface) request/response primitives are exchanged as stream messages between the data link service user and the service provider.

The DL_ATTACH_REQ primitive requests the data link service (DLS) provider to associate a physical point of attachment (PPA) with a stream.

The DL_ATTACH_REQ primitive is needed for "style 2" DLS providers to identify
the physical medium over which communication is to transpire.
As soon as the PPA is attached with the stream, the data link factory physical address is requested with the DL_PHYS_ADDR_REQ: this primitive requests the DLS provider to return either the default (factory) or the current value of the physical
address associated with the stream depending upon the value of the address type selected in the request. The message is valid in any attached state in which a local acknowledgement is not pending. For a "style 2" provider, this would be after a PPA is attached using the DL_ATTACH_REQ.

Any help to understand while this primitive fails and what could be an
alternative solution ? Thanx.

[sven verhaegen]

HI

I can't fix this but I can give some more explanation on the behaviour of APA and dlpi numbering , in fact DLPI is a virtual device file for a physical card on a board , it means it is created by software and any request on it are sent to the network stack on the kernel , however APA is a whole different story , it is a special stack which creates its own devices e.g.

.... lan100 , lan101, lan102 ....

they also are dlpi devices but I am not sure they are handled by the normal network stack so the system-call refered to might address the kernel directly and ignore the APA stack thus finding no DLPI devices at all , this is logical becaise a lancard integrated in a APA agreggate in fact disappears for the system , it's DLPI address no longer visble as it is incorporated in the virtual DLPI address defineing the APA agregate lan100 dlpi device
so you could end up with a system with only one lan lan100 handeled by APA on top of the normal lanstack in the kernel not answering to specific system calls becaus it doesn't know that call type...

[Alice_11]

Thank you Sven for your answer.
I am a member of the LUM development team and I have a few questions I would like to ask you.

We use the DL_ATTACH_REQ primitive to attach the device in order to retrieve its physical address. The problem with APA is that the physical device is masked, so we have no access to it anymore (via dlpi, at least).

What do you mean by saying that you "can't fix this"? I mean... do you think there might be some easy workaround that we could use in our code that could help us avoiding the problem? (i.e., could we use something different from dlpi in order to retrieve the mac address of the device?)

Or else is it possible to change the APA in order to let the programs that use dlpi continue working?

Thank you,
Alice.

[sven verhaegen]

Hi

when I state I don't know "how to fix it" , I mean I have limited knowledge in system calls and programming (I'm more of a general networking specialist) so I cannot give any advise on that level , I gave this information to show that APA in fact is a stack on top of normal networking which migh handle request from system calls differently , as for the adaptation of APA , this is a hard nut to crack , it would require first a in depth study of the even looking exactly where the call fails to see if as I suspect it is APA not replying , that would require a request to the HP LAB's to get a explaining on the exact functioning of the DLPI numbering in HP-UX with APA .. then there would have to be a stern reason for the alteration of the product , if a valid (bussiness impact) reason exist a enhancement request could be launched , if this is the case we stil talk about a 6 month development and implementation(test) period before a fix would be released