I have hit on someting interesting - took a while to figure it out as I wasn’t expecting it.
Many years ago I purchased a data manager called SoftFocus. A bloke in Canada wrote it and it has served me well with QNX4 and Linux. Today I decided to compile it on QNX6.5.0 Sp1. That went surprisingly well. This package is written in C - I am using C++ (QCC).
Until I linked it into a server process that attaches a name using name_attach().
When the data manager is linked in name_open() calls fail. It returns -1 and errno is 2 (ENOENT). It doesn’t matter whether it is a local or remote (global) name. The server sees the _IO_CONNECT message and duly responds with a valid rcvid (MsgReply returns 0). The name does exists in /dev/name/local (or global as the case may be) but name_open() always returns -1 with errno 2.
Take the data manager away and it all works fine.
What on earth could cause some C code in an application break the QNET naming system?
gns is running appropriately (that means well). If I stop gns and use only local names, it still fails. So I don’t think gns has anythng to do with it.
Any ideas?
Ultimately I intend to purchase a database package like the ITTIA one advertised on this website but my intention at this time was to simply knock something up that was quick and supposedly easy (and cheap to play with during the initial program development). So much for that! Best part of a day tracking this one down!
A few things appear to have changed in 6.5 with regards to gns and name_attach(). You might want to check the doc’s here and search for ‘gns’. The issue with name_attach may be what’s causing your failure on the network side.
On the local side when you get the name_open() call you have to respond with EOK (search for name_open in the link below) for it to connect. qnx.com/developers/docs/6.3. … ttach.html
The clue was the EOK in the MsgReply to the _IO_CONNECT message (in the server).
It turned out that the SoftFocus database redefined EOK to be long (-1). I guess it was written before EOK became 0 in the UNIX type operating systems like Linux and QNX6. They also redefined EEXIST 10 be 10 instead of 17 but that doesn’t seem to be a problem for me - at this time.
I looked at the SoftFocus manual and it is dated 1993. A nice little gotcha but apart from that, it is actually an great little data manager package and lightening fast (using B+ tree indexing). So I will continue using it for the time being - at least until I can justify the expense of a more modern equivalent that will also work on QNX6. Right now I am mainly scoping out a project and putting together a basic “proof of concept” system.
This redefinition of EOK has reared up on me only because of the _IO_CONNECT mechanism - that message being sent by the client when a name_attach() call is made on the server. I was inadvertently sending a reply of -1 instead of 0 (which is what EOK was supposed to be!)
On a different topic, after 27 years using QNX I think I have come to the end of the road at 6.5.0. The main reason is the loss of Photon and consequently Phindows. To a similar extent the loss of the self hoted environment. I have never been comfortable with the Ecllipse IDE and I guess I’m now too old a dog to learn a new trick. I’m not too cut up about it - 6.5.0 does everything I want (and more) and the hardware I am using it in will be around for quite a while yet.
For what it is worth, I think QNX has made a major boo-boo by killing Photon and forcing developers onto a Windows based development platform.
Agreed about the development platform (we don’t use Photon on our finished product). As someone who has used QNX for 25 years I’m not much for the Eclipse environment either. But then we are dinosaurs from an era before GUI based development environments and we’ll be extinct sooner than we’d care to admit.
