| Title: | "ASK THE WIZARDS" |
| Moderator: | QUARK::LIONEL |
| Created: | Mon Oct 30 1995 |
| Last Modified: | Mon May 12 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1857 |
| Total number of notes: | 3728 |
Return-Path: "VMS001::WWW"@vms001.das-x.dec.com Received: by vmsmkt.zko.dec.com (UCX V4.1-12, OpenVMS V6.2 VAX); Tue, 22 Apr 1997 09:18:51 -0400 Received: from vms001 by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id JAA07875; Tue, 22 Apr 1997 09:12:06 -0400 (EDT) Date: Tue, 22 Apr 1997 08:15:46 -0400 Message-Id: <[email protected]> From: "VMS001::WWW"@vms001.das-x.dec.com (22-Apr-1997 0815) To: [email protected], [email protected], [email protected] Subject: Ask the Wizard: '[email protected]' X-VMS-To: [email protected] Remote Host: gatekeeper.nera.no Browser Type: Mozilla/2.0 (Win16; I) Remote Info: <null> Name: Kjerstin Sandvik Email Address: [email protected] CPU Architecture: VAX and Alpha Version: Other Questions: Is it possible to read one and only one message received on a TCP/IP connection if the sender set the PUSH flag for each message? We have no way to make sure that a message is read before we receives a new. Let say we receives two messages with the PUSH flag set in both. Will the QIO read call return ALL bytes received since last read (in this case all bytes in both messages) or only the first message? When using UCX, how is the PUSH flag set? (Default??) We use Open VMS 7.1 and UCX 4.1. Thanks
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1792.1 | Additional Software Required | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Tue Apr 29 1997 16:14 | 11 |
Without application or additional layered product assistance, there is no way to assure that a DECnet or TCP/IP message has been read and has been processed by a remote task, only that it has been successfully queued, and that there have been no errors on the datalink. If you need to ensure that the message has been received and processed, consider using a package such as RTR, the reliable transaction router package, or consider adding a confirmation notification mechanism to the application protocol. | |||||