RMS services sys$connect

[pacab]

Thank you in advance for all of your input.

I currently support a C++ application that runs on a OpenVMS 7.3 and uses RMS services components to interact with VMS RMS files which reside in a separate VMS box running 6.2 version. The services being used are sys$open, sys$connect, sys$get...etc.

This C++ application used to be on a VMS 6.2 O.S. But we recently upgraded that box where the application used to exist living the data RMS files on its original alpha box runing VMS 6.2. The application does not work since we upgraded where it hangs when it invokes sys$connect.

Does anyone know if there is problem with RMS services (in particular sys$connect) not working properly between 2 OpenVMS with different versions (as described above)?

Any feedback is greatly appreciated.

Cheers,
Abel

[Robert Gezelter]

Abel,

Not particularly. I have been doing applications that involve cross system access for most of the life of OpenVMS (28 years) and have not encountered this type of problem in any generic way.

The fact that the at least one of the boxes "has been upgraded" leaves me with a suspicion that some aspect of the configuration was changed in an unanticipated way. On the VMS level, such problems are extremely rare.

In what way does it hang?

- Bob Gezelter, http://www.rlgsc.com
P.S. If you want to talk about this privately, my email address is listed on my www site.

[Ian Miller.]

It sounds like you are accessing the RMS files on the V6.2 system from the V7.3 system - is this correct? How are the systems connected?

[pacab]

Ian,
You are correct, the application is trying to connect from the 7.3 to the 6.2 box. And they are communicating via DecNet.


Thank you - Abel

[Ian Miller.]

can you access the files from the V7.3 node via DECnet using another program e.g. DIR or DUMP of the file. This is just to check for DECnet issues.

[Volker Halle]

Abel,

you could enable FAL logging on the V6.2 node (where the files reside):

$ DEFINE/SYS FAL$LOG FFFF

Then stop the application on the V7.3 node, make sure the network process on the V6.2 has exited (SHO SYS/NET). And then start the application again and wait until it hangs...

You will find a DAP message trace (DAP = Data Access Protocol, which is being used between RMS on the V7.3 system and FAL on the V6.2 system) on the V6.2 system in the login-directory of the user account used to access the files as NETSERVER.LOG (or NET$SERVER.LOG if using DECnet-OSI). It may take a while for the .LOG file contents to be flushed to disk.

Maybe you can guess from the DAP trace, where the problem might be...

Volker.

[pacab]

Ian,
Yes I can access the file from v7.3 using DIR on the directory where the file is located on the v6.2 box. I can actually open the file and read one record at a time.
So I guess DECnet is not the culprit here.

Any other thougths?

[Volker Halle]

Abel,

when you say 'the process hangs', what state is it in ? You could collect a little bit of info with SDA:

$ ANAL/SYS
SDA> SET PROC/IND=
SDA> SHOW PROC
SDA> SHOW PROC/CHAN
SDA> SHOW PROC/LOCK
SDA> CLUE CALL

Volker.

PS: If you are done with FAL/DAP tracing, don't forget to deassign the logical.

[pacab]

Thank you to all for you feedback and advice.

Volker, after the process gets to the SYS$CONNECT service it simply does not respond. Meaning, it does not returns to the next line of code where it checks for the status of that service. I tried setting up the FAL/DAP but there is no log build. I was able to use ANALYZE and view some process information at the initiating box (v7.3) and shows the process being active.

What bothers me is I am able to Open the file, read a record from the new box (v7.3) into where the data files live (v6.2) with out a problem. We currently have a proxy set up to log into the legacy box and use the following syntax: box"proxy"::directory:file.dat and again, I can see the file via DIR, TYPE/PAGE, and OPEN/SHARE. So, I do not understand why SYS$CONNECT service is not able to (what appears) establish the connection or not and return the status. I am not familiar with RMS services, in particular with sys$connect to figure out what could be the problem. The sys$open returns a successful status which is required for sys$connect to work (per the documentation). I am lost...

Abel

[Volker Halle]

Abel,

let's first fix the problem with the missing NETSERVER.LOG file:

- make sure that user "proxy" on node "box" has a valid login-directory, to which it can write. DIR box"proxy":: should list that login-directory. If that directory is writeable by the user "proxy", there should be NETSERVER.LOG (or NET$SERVER.LOG) files in that directory.

From your description, you seem to be running your program with the debugger. To get a clearer pciture of the hanging program, run it without the debugger and - once it hangs - look at it with SDA. What state is the process in: LEF ? Consider to provide the output of the SDA commands mentioned earlier.

Note that you can also look at the RMS structures of that process with SDA> SHOW PROC/RMS=...

SYS$CONNECT is not a very complicated operation, it associates a record stream with an open file. Internally, it will create an IRAB and some I/O buffers.

Would it be possible - for a simple test to rule out DECnet involvement - to temporarily copy the data file to the V7.3 node and access the file locally ?

Volker.

[Hein van den Heuvel]

There are no reported problems with 7.3 -> 6.2 Decnet remote file access.

I actually suspect a programming bug that went unnoticed before, but become apparent now with some (network) delay involved. Admittedly it is hard to explain a hang.
I would encourage you to triple check the FAB & RAB setup code, notably the FOP and ROP fields. You are not per chance using xAB$V_xxxx as a mask?
That is for example: erroneously use FAB.FAB$L_FOP = FAB$V_SQO when you should be using fab.fab$v_sqo = 1 or fab.fab$l_fop |= FAB$M_SQO.
You would not be the first to do this, and in the process accidently be setting xAB$V_ASY. ASY being bit 0 in fab and rab, it has 50% odds of accidently being set when confusing a bit number with a mask.

Please carefully follow up any and all of Volker's questions/suggestion. They are the right investigation methods.

An additional suggestion could be to try DECnet access from the 6.2 system to itself. You know... use 0:: in the file name (logical).

>>> can see the file via DIR, TYPE/PAGE, and OPEN/SHARE. So, I do not understand why SYS$CONNECT service is not able to (what appears) establish the connection or not and return the status.

TYPE and OPEN/SHARE will of course internally use a $CONNECT call.
They have to, just like any other program. So this is further proof that something is amiss with the coding of your program, not with the connect code itself.

Can you reduce the program to a bare-bone $open + $connect which supposedly still hangs? Please share that simple source with us in an attached .txt file (easier on most browser settings).

Good luck!
Hein.

[pacab]

Hein and All,

Attached is a snip of the open module using RMS services I have been talking off. I looked and there is not appear to be any problems.

Thx,
Abel

[Hein van den Heuvel]

>> Attached is a snip of the open module using RMS services I have been talking off. I looked and there is not appear to be any problems.

HUH? That program IS showing EXACTLY the errors that I suggest it might have:
It is using BIT NUMBERS where BIT MASKS are expected:

>> fab.fab$b_shr = FAB$V_UPI;
:
>> rab.rab$l_rop = RAB$V_NLK & RAB$V_RRL;

That looks like really bad code to me.
Was that not supposed to be an OR (|) not and (&)?
But anyway... you may still be setting bit 1, the ASY bit.
RAB$V_RLK = 19, RAB$V_RRL = 3. Both odd.

The code is also half-hearted about wanting to create an index file on the fly.
That, IMHO, is rarely adviseable.
I would suggest you make the open fail, NOT create-if for an indexed file and use a tuned FDL file to create it if needed on error.

>> // xab.xab$b_siz0 = 9;
You can not create an indexed file without a primary key size.

>> int RMSFile::pendloop(void)
while(rab.rab$l_sts == 0)
;
return rab.rab$l_sts;

Yikes.... this suggests you are expecting ASYNC work. Are you really ready for that?
This should probably not be needed.
To see this raises a red flag.
Is some (thread in) your code poking the active RAB? That would be ugly, or is that per chance an attempt to deal with the unintended ASY setting?

Cheers,
Hein.

[pacab]

Hein,
Thank you for taking the time to review the material and providing feedback. I actually do not understand much of what this module is doing, I took over support of this application and there was no supporting documentation provided. I am learning and documenting as I go and encounter this type of issues. But, once again, thank you for your input it really helps to sheed some light.

Abel

[Hein van den Heuvel]

That's fine. No problem.

You should seriously consider getting rid of the 'pendloop' function.
I suspect it is there only because an error was made elsewhere.

And fix the V_ usage.
Replace by M_ and OR operations ( | )
Or... properly use bitmask Vields: .ab$v_xxx = 1;

Once you fix that I suspect the hang will go away. Furthermore... the 'read regardless of lock' and stuff like that will finally start to work as intended!

Do report back if the problem persist.


Hein.

[Ian Miller.]

The VMS manuals are your friend :-)
http://h71000.www7.hp.com/doc/731FINAL/4506/4506PRO.HTML
http://h71000.www7.hp.com/doc/731FINAL/4523/4523PRO.HTML
and possibly
http://h71000.www7.hp.com/doc/82FINAL/5841/5841PRO.HTML