| Tranferring a message is no problem, assuming you are doing the
following sequence on your VMS process:
1. attach to permanent queue
2. attach to a temporary secondary queue
3. get from the permanent queue
4. put the same message body (and type, class if you need to) to
the temp queue. Note that you can't use a DQF or SAF delivery
mode to a temp queue.
1 and 2 can be reversed, if you want the temp queue as the primary.
Now, for the problems:
1. The WinNT client app cannot attach to a queue on another group,
which it needs to do to read messages from it.
2. Even if (1) weren't true, only one process can attach to a temp
queue, and its contents disappear if the owner process detaches.
3. Even if (2) weren't true, you can not attach to a specific temp
queue number, the group picks the number out of the bucket when
you ask to attach to one.
I assume what you really want to do is have the VMS server send to
message back to a temp q on WinNT that the client process IS attached
to already (you can't put to a temp queue which noone is attached to;
it doesn't exist). You can have the client specify that temp queue as
the resp_q argument when it puts the original request.
If the temp queue has to exist on the VMS system, your only solution is
to have your WinNT client app built using the DmQ client library, and
have it attach as a DmQ client to the VMS DmQ group. You could
probably set up CLS security so that the client can't attach to the
permanent queue for reading (I'm not familiar with the VMS CLS setup,
but I know you can do this on Unix DmQ). Obviously, there is no DmQ
group on WinNT which is involved with this.
If none of this solves your problem, perhaps you can state the security
problem they are trying to solve.
|