| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2796.1 | loopback not implemented on Unix/NT | WHOS01::ELKIND | Steve Elkind, Digital SI @WHO | Mon Mar 03 1997 12:18 | 6 |
| I used to try this too. The simple answer is that loopback is not
implmemented on the Unix/NT versions of DmQ. I thought I was seeing
success until I spotted the "unsupport PAMS message type" messages in
my group log file on Unix, then tried turning verification "on" (I
hadn't bothered with the latter, since applications were already
exchanging messages successfully).
|
| 2796.2 | loop back test error happened on VMS | TPOVC::GARYCHENG | | Tue Mar 04 1997 05:03 | 6 |
| Actually, I did 2 kinds of different test.
1. Loop back test on OpenVMS, and got an data verification error.
2. Put-get message between OpenVMS and WinNT thru test program,
and from WinNT side, I spotted the "unsupport PAMS message type".
I think the problem is on the OpenVMS.
|
| 2796.3 | did you send to gcp? | WHOS01::ELKIND | Steve Elkind, Digital SI @WHO | Tue Mar 04 1997 11:10 | 12 |
| In the past when I tried the loop back test, the VMS side sent
PAMS-class test messages to the Unix COM server (gcp, queue 100?) with
a PAMS message type that the gcp did not recognize; it logged them with
"gcp, unsupport PAMS message type". The COM server sent back some sort
of error report or confirmation, which of course is different than the
test data and will cause verification errors.
When you used the test program (dmqtestc?), did you send data to queue
100 on NT, or to some application queue on NT? If the former, then I
might expect to see the gcp rejecting it out-of-hand, and possibly logging
the fact that it got something it didn't recognize - unless it was a
properly composed public or proprietary message API message.
|
| 2796.4 | dmqtestc ? | TPOVC::GARYCHENG | | Thu Mar 06 1997 05:06 | 12 |
| Yes, I use the test program dmqtestc both in VMS and NT.
In NT, I config a queue with no.1
In VMS, I use the temporary queue.
On most recently testing, I got something weird.
I put a message from VMS to NT, if the message is less than 8 bytes
then NT received it correctly. If it >= 8 bytes, then some unexpected
code, like "|u", will append to the message received.
When I put message from NT to VMS, the message received always one
byte longer(always "." in the end).
Is this normal ?
Gary
|
| 2796.5 | My guess is... | KLOVIA::MICHELSEN | BEA/DEC MessageQ Engineering | Fri Mar 07 1997 12:00 | 9 |
| re: .4
Is that NT assumes null-terminated strings and VMS does not. Therefore, the
"|u" is some garbage leftover in NT's buffer until a null is encountered.
Whereas, on VMS it will print exactly the number of characters it received upto
50. If VMS detects an unprintable (i.e. a null) it will subsitute a ".".
Marty
|
| 2796.6 | parsing null string ? | TPOVC::GARYCHENG | | Mon Mar 10 1997 02:09 | 8 |
| re: .5
Will the garbage leftover happen if I write a VB program (ver 4.0)
and use the DMQ PAMS API to transmit the message between NT and
VMS ?
Does my application need to parsing the null string ?
Gary
|
| 2796.7 | DmQ just moves a bunch of bytes... | KLOVIA::MICHELSEN | BEA/DEC MessageQ Engineering | Mon Mar 10 1997 11:31 | 16 |
| re: .6
> Will the garbage leftover happen if I write a VB program (ver 4.0)
> and use the DMQ PAMS API to transmit the message between NT and
> VMS ?
> Does my application need to parsing the null string ?
Your application decides how to send the data, be it null terminated strings,
counted string or fix length structures. What I am saying is that I believe
that the test program on NT needs and thus includes a null whereas the VMS test
program does not.
Marty
|