Well maybe the subject got your attention but here is the problem as my
customer reported it and my apologies for the length. First some information
exaplanation and then I can tie it all together. I have a customer on a 5.0.7
and to my knowledge they do not have MP5 installed and we were not concerned
with the dates last year so in preparation for DST we simply changed the
/etc/TIMEZONE file as described in this group. Old line in this file was:
TZ='EST5EDT'
now
TZ='EST5EDT,M3.2.0/2,M11.1.0/2'
We then rebooted and logged on and checked the Environment and TZ was set to
the new form. System did change time on Sunday as expected.
This customer also has a process on their 5.0.7 system in their accounting
package where at a customers request they will Email them a copy of an invoice.
5.0.7 is using sendmail but while we are sending it out from the SCO machine
the actual from and the reply to email is set to an
info@customer.com account
(which is an email account they have set up on ther outside world email
system). The SCO machine has no other email function than standard system mail
and then these outbound invoices. This works well most of the time but
occassionally they will get some bad address or for some reason undelivered
returns. I will post on this in another post with some examples.
While researching this I could find no reason for these sporadic failures but
the customer mentioned a while back they had had to change to the Bellsouth DNS
servers on their windows system (which is the main connection plus a router and
DSL modem) to the outside world). So in keeping in line we changed the
Bellsouth DNS server IPs in the SCO 5.0.7 /etc/resolv.conf file.
Now to tie this all together. They retrieve several files daily from the SCO
Machine to a Windows machine via and ftp script using Windows ftp. They did
this last on Thursday afternoon of last week. I made the change for the DNS
IPs in /etc/resolv.conf on Thrusday Night and they changed the /etc/TIMEZONE
and rebooted early Friday Morning. The IT type on site is the only one with an
ethernet connection (besides on demand inbound VPN connections through a
windows machine) and all others are Serial through a Digi. Since these two
events the FTP process has failed to function and telnet attempts to get a
login are taking an unusually long time. I have connected via VPN and have
noticed the long times from point of attach (Tiny Term) to a login prompt and
attempting to use his ftp script or manually connect via windows ftp have
failed. The best I have achieved is by using Cygwin FTP and it takes a long
time but does connect and if I use sftp it connects quit quickly. It also
seems using ssh to connect vs telnet is quicker as well although not as
noticable as the sftp vs ftp.
Since then in an attempt to diagnose on the SCO machine I put the original two
DNS servers back in the /etc/resolv.conf file but that has not helped. Pings
on the four different BellSouth DNS servers we had showed the response time
from the first two was much almost instantaneous vs the two they had me change
to which is why we tried all 4 but with the originals listed first. Last night
I removed the two new ones leaving just the originals and advised client a
reboot might again be in order.
I see no reason that either of these above should affect the login or the ftp
procedure but I am at a loss to come up with any other explanation. I thought
at one point maybe the TZ expansion was causing an issue when the environment
was being established for login but.... wouldn't something like that affect the
serial connections as well as the network.
Any thoughts - anyone seen anything like this. Thanks to all in advance.
bk