OpenVMS v8.2-1 and FTAM

[CA1296764]

Hi again,

I still have not resolved my issues with FTAM, but I am making progress.

I now have FTAM_API based software that 'works' on Alpha and IA64 OpenVMS.

The main issue is that some of the calls to the osif commands on IA64 OpenVMS still accvio, even though the data being passed to the function is as expected.

The list of products I have installed are attached.

When can I get confirmation that the list of products I have are compatible and that the FTAM/FTAM-API software has been tested as working on IA-64?

I have also tried the API-IVP software on Alpha and IA-64 OpenVMS, and it only works on Alpha......

DCL based FTAM commands work fine on both Alpha and IA64 OpenVMS. This issues I am having are with the FTAM-API software.

Any suggestions appreciated.

Many thanks
Regards
JC


----------------------------------- ----------- ------------
PRODUCT KIT TYPE STATE
----------------------------------- ----------- ------------
HP I64VMS AVAIL_MAN_BASE V8.2-1 Full LP Installed
HP I64VMS C V7.1-11 Full LP Installed
HP I64VMS CDSA V2.1-355 Full LP Installed
HP I64VMS CXX V7.1-11 Full LP Installed
HP I64VMS DECNET_PLUS V8.2-1 Full LP Installed
HP I64VMS DWMOTIF V1.5 Full LP Installed
HP I64VMS FTAM V3.1-P Full LP Installed
HP I64VMS KERBEROS V2.1-75 Full LP Installed
HP I64VMS OPENVMS V8.2-1 Platform Installed
HP I64VMS OSAK V3.0-T Full LP Installed
HP I64VMS TCPIP V5.5-11 Full LP Installed
HP I64VMS TDC_RT V2.1-78 Full LP Installed
HP I64VMS VMS V8.2-1 Oper System Installed
HP I64VMS VT V2.1-K Full LP Installed
----------------------------------- ----------- ------------

[John Gillings]

JC,
Make sure you check the actual arguments passed at run time. Also read the ACCVIO to work out exactly what it's complaining about (rm, VA & PC). Maybe there's an alignment issue?

If you can't find anything obvious, please log a case with your local customer support centre for a detailed diagnosis, or perhaps to elevate it as a bug.

[CA1296764]

Hi,

Thanks for the suggestions.

Yes, I have checked the actual arguments being passed and I have also run the modified software on both Alpha and IA64.

I'll post the ACCVIO text later if anyone is interested....

I think the giveaway here is that the IVP does not work on my IA64 box either......

Also the FTAM documentation is dated 1996!

Many thanks
JC

[CA1296764]

Hi again,

How do I report possible bugs to HP from the UK?

Weblinks or telephone ?

Many thnaks
JC

[Volker Halle]

JC,

to log a call with HP, you probably need a software service contract. If you have one - and the right 'magic number' - you can use the Support Case Manager in ITRC, to register your contract and log a call.

Volker.

[CA1296764]

Hi again,

We are registered with DSSP.
Can we report this issue through DSSP?

Any pointers?

Many thanks
JC

[Volker Halle]

JC,

regarding problem reporting through DSPP, I don't know.

Until you figure out, how to report this problem, would you mind to provide the ACCVIO details and the IVP error, so maybe we can help you ? This also provides the advantage to 'document' the symptoms for the future reader.

Volker.

[CA1296764]

Hi again,

Here is the ACCVIO message on IA64

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
004C, PC=000000000016B7C0, PS=0000001B
break on unhandled exception preceding OSIF_SEND+1488
%DEBUG-I-SOURCESCOPE, source lines not available for %PC in scope number 0
Displaying source for 1\%PC


How do I make sense of the above?

The IVP doesn't report anything, and the responder and initiator programs hang.

Regards
JC

[Volker Halle]

JC,

what the ACCVIO message is telling you is this:

The machine instruction at PC=16B7C0 - is this in your program ? - tried to read from a virtual memory address of 4C and failed. This virtual address belongs to the null access page and cannot be accessed.

Could you run the program with /NODEBUG to get the traceback information or can you issue a DBG> SHOW CALLS ?

At the DBG> prompt, issue the following command to look at the machine instructions:

DBG> EXA/INS @PC-10:@PC

When running the IVP, do a REPLY/ENABLE to watch any DECnet event messages. Are there any logfiles associated with the program run in the IVP ? Any errors in there ?

Volker.

[CA1296764]

Hi again,

Here goes:

DBG> show calls
module name routine name line rel PC abs PC
OSIF_SEND 000000000009B7C0 000000000016B7C0
*FTAMMOVE ProcessGroup
25762 00000000000041C0 00000000000F0180
*FTAMMOVE MoveBegin
25361 0000000000001960 00000000000ED920
*MAIN_PROCESS
FileBegin
13495 0000000000001290 00000000000D1290
*BASE ProcessFiles
33690 0000000000000C90 00000000000DAC00
*MAIN_PROCESS
main 12972 0000000000000720 00000000000D0720
*MAIN_PROCESS
__main 12802 0000000000000110 00000000000D0110
FFFFFFFF80AFABA0 FFFFFFFF80AFABA0

DBG> EXA/INS @PC-10:@PC
OSIF_SEND+1478: nop.i 000000 ;;
OSIF_SEND+1488: ld1 r9 = [r9] ;;

I'll check IVP later.....

Many thanks
JC

[Volker Halle]

JC,

so R9 probably has a value of 4C - which is an invalid address.

DBG> SET LAN MAC
DBG> EXA R9

Is OSIF_SEND your code/module ? Or is it in some DECnet library ? A LINK/MAP should tell. If it's your code, compile/link with /MACHINE_CODE/LIST. If it's DECnet/FTAM code, what's the last call frame from your code ? And what does the call look like ?

Volker.

[Volker Halle]

JC,

this is the continuation of this thread, right ?

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1045471

So I'm assuming that OSIF_SEND() is a DECnet/FTAM routine and it ACCVIOs on some field in your input parameter structure...

Volker.

[CA1296764]

Hi again,

Yes, exactly.

On OpenVMS Alpha the code works fine.

Most of the code on IA64 also works but then the ACCVIO comes up.

I have manually checked (using the debugger) the data structure being passed to the OSIF_SEND code and it looks to be correct.....

Doesn't look good that the IVP doesn't work or the fact that anyone else has this working on IA64.....

First things first I would like to see the IVP working before spending more time on my code.....

Regards
JC.