Stefan:

Thanks for the analysis and information.  Why am I not surprised that the "No error" came from Windows!? 

I tried some of your suggestions with the following results:

1.  Ping ==>= works as expected on the failing machine; that is, can successfully ping "max13"  I also can ping successfully in the reverse direction; that is, from "max13" to my "client" machine.

2.  NSLookUp ==>does not work on any of the 3 machines.

3.  Added the computer name "max13" to HOSTS file; ==> observed no change in behavior (i.e., still fails)

I did notice that on the 2 machines that function as desired that there is no anti-virus software installed, while on the non-funcational machine there is A-V SW installed.  I am able to bring up eLOG via the browser on the non-functional machine, so am unsure if the A-V SW is a factor; that is, why does ELOG via browser work as expected, but not via command line. 

QUESTION:  does command line ELOG connect differently than ELOG through the browser?

I ask this question for perhaps the A-V SW *is* blocking some port or whatever, and I will need to ask our IT department how to remove such a restriction.

ELOG connects in the same way as the browser, but it is a different program. I have seen some firewalls which explicitly exclude browsers in firewall rules. So it might well be that yours blocks ELOG but not your browser. So give it a try and disable it.

Since both my machine and the Elog server PC are inside my company's "security zone", I am not running a firewall on my machine.

For what it's worth:  in trying to research the "No error" message, I did come across this information on MS's website; that is, their statement is:

The gethostbyname function retrieves host information corresponding to a host name from a host database.

Note  The gethostbyname function has been deprecated by the introduction of the getaddrinfo function. Developers creating Windows Sockets 2 applications are urged to use the getaddrinfo function instead of gethostbyname.

SOURCE:  http://msdn2.microsoft.com/en-us/library/ms738524.aspx

the following patch corrects the problem, plz apply :


--- elogd.c     2005-02-03 16:46:10.000000000 +0100
+++ elogd_albert.c      2005-02-08 15:40:36.000000000 +0100
@@ -6178,7 +6178,7 @@
    if (getcfg("global", "charset", str, sizeof(str)))
       rsprintf("Content-Type: text/html;charset=%s\r\n", str);
    else
-      rsprintf("Content-Type: text/html;charset=%S\r\n", DEFAULT_HTTP_CHARSET);
+      rsprintf("Content-Type: text/html;charset=%s\r\n", DEFAULT_HTTP_CHARSET);

    if (use_keepalive) {
       rsprintf("Connection: Keep-Alive\r\n");
@@ -11267,7 +11267,7 @@
    rsprintf("Server: ELOG HTTP %s\r\n", VERSION);
    rsprintf("Accept-Ranges: bytes\r\n");
    rsprintf("Connection: close\r\n");
-   rsprintf("Content-Type: text/plain;charset=%S\r\n", DEFAULT_HTTP_CHARSET);
+   rsprintf("Content-Type: text/plain;charset=%s\r\n", DEFAULT_HTTP_CHARSET);
    rsprintf("Pragma: no-cache\r\n");
    rsprintf("Expires: Fri, 01 Jan 1983 00:00:00 GMT\r\n\r\n");

> elog sends wrong HTTP headers, charset is empty and not separed from the
> next one "Connection: Keep-Alive ... this bug tells the browser that the
> encoding is "connection:" ... that is wrong.

This has to do with the "%S" vs. "%s" bug described elsewhere in this forum. 
I fixed that. The validator link above now also reports error free.

> Hello,
>     If you delete a message from the middle of a logbook that contains a 
> bunch of messages, the message numbers do not get updated properly.  For 
> instance, if you have 20 messages in the logbook, and delete number 15, 
> entry numbers 16 through 20 all do not get subtracted by one; their numbers 
> stay the same with #15 just missing in the middle.  
> 
> Mo

That's how it's supposed to be. Once a unique message ID is attached to a 
message, it stays there forever. Think of links to message like

http://midas.psi.ch/elogdemo/Forum/68

If you have such a link in a message or as a bookmark in your browser, and 
the ID gets changed from 68 to 67, then your link would be off.

Thanks, Andreas.  I was aware of the "pending draft" menu, and I am aware that you can manually browse to an entry even if it doesn't appear in the list.  However, for our operations group it is a requirement that any saved entry appears in the list, even if it's in the process of being edited.  We won't be able to upgrade until this is possible.  

Previous releases didn't have this problem, so hopefully it won't be too difficult to address with a new configuration option.  Please let me know if there's something I should do to submit an official feature request / bug report.

Thanks again,

Devin

Andreas Luedeke wrote:

Hi Devin, this is the intended bevaviour, there is nothing wrong with that. Only a submitted entry should be visible to the world. If you would have played a little bit longer, you would have found out yourself how you'll get access again to this so-called "draft" entry after closing the browser window: as soon as you attempt to create - as the same user - an new entry, you'll be asked if you want to continue editing your old draft entry instead. I've attached a screenshot of this "pending draft" menu, as it has been shown for this entry before I've submitted it. Kind Regards, Andreas PS: You gave a very clear "failure" description: what you did, what you expected to happen and what you've observed what happened instead. Well done: that deserves a swift answer! Devin Bougie wrote: When an entry is being edited, it does not appear in the list once it's been autosaved or the editor manually clicks on "Save."  This has been reproduced in the "Linux Demo" forum on this site, as well as on a clean installation of the 3.1.1 binary on EL6. It would be great if there was a configuraiton option to control this, but I haven't found it yet.  To reproduce: - edit an existing entry - click on "Save" - view the list for that logbook, and the entry will be hidden until you click "Submit" Obviously this becomes a problem when a user edits an entry, but navigates away from the browser window before submitting the changes. Any suggestions would be greatly appreciated.   Many thanks, Devin