Failed to read reply" in GUI MASTER RECORD

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 20, 21, 22, 23

Description:
The message "Failed to read reply", "Communication error - Global-7" occurs in the GUI, appearing in the middle of the screen.

Resolution:

The "Failed to read reply" message is produced by the PC via this line in the .\alephcom\tab\eng\error.dat file:

GLOBAL -7#Communication error Failed to read reply.

This indicates that the operator pressed Enter and failed to receive a reply from the server.

The following are the reasons a reply may not have been received:

1. the PC request didn't get to the server;
2. there was an error on the server in processing the request; or
3. the response produced by the server didn't get to the PC.

If a *login* request doesn't get to the server, then the "Failed to connect to host" message will be received (rather than "Failed to read reply").

When the request gets to the server but there's an error in processing it (reason #2), relevant messages will be found in the $LOGDIR/pc_server log. Some conditions will cause *all* transactions, including the login transaction, to fail. (See below for such conditions.) In other cases, most requests will be processed successfully but there may be a program error in processing a particular kind of request. These will appear in the pc_server log as ".gnt" errors. There are many articles about specific gnt errors, for example, an error connected to order log records: " GUI Acq: "Failed to read reply"; pc_server log: "Execution error .../get_buf_z71.gnt' ".

In the case of reason #3, the $LOGDIR/pc_server log will show successful processing of the request, but the response indicating this success fails to reach the pc.

Reasons #1 and #3
These indicate communication problems. These problems can be due to firewalls separating the PC from the server, or network problems, such as general congestion. (Or, less likely, a problematic piece of hardware somewhere along the way, which affects pc_server traffic disproportionately.)

If the server is remote and the connection to the internet is very busy, campus networking staff may be prioritizing outgoing traffic. This is usually based on port numbers. If that is the case, they need to include the pc_server traffic in their priority list.

6nnn ports are high and non-standard ports that can be identified as p2p (peer-to-peer) ports. ISP or local IT services sometimes limit the port traffic rate to very low value.

The firewall of a hosted server can cause sessions to time out after a specific idle time. The first action of the client after the time out (or at startup each morning) can be affected by this. Bandwidth restrictions for certain ports can also come into play.

'ping' and 'traceroute' may help in narrowing down the problem.

#2. Messages in the pc_server log indicating problems (on the server) causing *all* requests to get "Failed to read reply" (Note for "2c" below only some transactions get the error) :

2a.
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
or
Oracle error: handle_connection
ORA-01033: ORACLE initialization or shutdown in progress
***************************************************
* No ORACLE connection - process is terminated... *
***************************************************
2b.
"license_check [err]: License expired on ..." Create a Salesforce Case, with a Notepad file containing the license attached to it, requesting an updated version of the license. If the license_check error message says something other than "License expired on ..." check for Salesforce articles containing that other text.

2c. In one case, temporarily changing "setenv pc_transactions_log N" to "Y" to activate the pc_ser_nnnn log, performing a transaction to get the "Failed to read reply" error, doing "pc_server view 6991 1000", which showed that the IN transaction was line "69", and then doing "pc_server check 6991 69" showed this message:

> fork: Cannot allocate memory

(NOTE: This happens for only certain transactions.) Increasing the memory corrected the problem.

2d.
A message ending in "encryption 1" or "encryption 2" appears in the pc_server log, such as:
2013-09-05 19:49:30 52 [000] [log] version 21.01 format ALEPH compression 3 encryption 1
or:
2010-09-09 14:08:41 39 [002] [log] version 20.01E format ALEPH compression 3 encryption 2
2010-09-09 14:08:41 39 [002] [log] DES mode is on
The server is set up for encryption and the PC is not (or vice versa).

* On the server, encryption is specified on the server in column 4 of $alephe_tab/tab_version
* On the PC, the value of the "Encryption=" parameter in the .\Alephcom\tab\alephcom.ini file must match the value specified in tab_version on the server.
If Encryption=2 is being used, the .\Alephcom\tab\des_key.dat file must contain the correct key.
* See also, the article "Set Up Encrypted Communication Between Aleph GUI and Server" .

Additional Information

It may be helpful to see whether other PC's at the site get the same error. Consult Article " Password not verified on connectable hosts" *MASTER RECORD* " if the "Failed to read reply" occurs in the box at upper left, rather than the center.

As noted above, the "Failed to read reply" message is coming from the PC. In contrast, the "Server failed to execute request after nn seconds" message comes from the *server*, from this line in the ./error_eng/global file:

global:0098 0000 L Server failed to execute request after $1 seconds.

It occurs when the processing time exceeds the $alephe_root/pc_server_defaults/PC_SERVER_TIMEOUT.

If the "Failed to read reply" message occurs only when more than one staff member is connected to a particular pc_server at a time, then consult the article "Failed to read reply" for Tech Services -- with multiple users per port . (The solution in this case was to start a separate pc_server for each heavy GUI Tech Services user.)

Article last edited: 29-Jun-2016