Text 1051, 70 rader
Skriven 2008-10-20 20:42:00 av Mike Luther (1:117/3001.0)
   Kommentar till text 1050 av Johan Zwiekhorst (2:292/100)
Ärende: More stuff gone!
========================
Thanks Johan ..

 JZ> That's the same here. A hung program doesn't require a 
 JZ> reboot on my system, though, because I use a process 
 JZ> controller program. I use WatchCat (see Hobbes), so I 
 JZ> can do ctrl-alt-F12 and simply kill the offending 
 JZ> program. A reboot is not needed to regain full control.

As long as the CPU isn't nashed 100% I can do these things also even with
killfeature set in CONFIG.SYS.   However, the subsequent tests show that in
some cases the 100% CPU bashing isn't there.  As well, the use of <CTRL BREAK>
will kill the process and the box reboot isn't needed.

How .. as to ..

 JZ> I assume the PAVCL and PAV programs were never 
 JZ> designed for such a huge virus list and can't cope 
 JZ> with it. I suggest you simply refrain from telling the 
 JZ> programs to generate that list.

I agree 100% with your thoughts.

Another interesting curious point for those wanting to work with this which is
a 'glitch' of sorts here!  I notice that your IP address posted for the
###.###.###.### address for the Panda update server is different from mine! 
Further, in agreement with your advice to watch for the time the daily is
posted to the Panda update server site and after that run the REXX script, I've
found out something else about this.

Because virtually all of my boxes in my 'local' CDST time zone operation are
used for international logging and telecommunications work for what I need, all
the time zone settings on them are UTC time.  Duhhhh ..

My 'day' on even the systems here ends in UTC time at 7:00PM CDST and at that
time we roll through to the next day.  Well, of course, your suggested REXX
script picks off the needed WGET file name based on the time/date setting for
the system.  Well guess what here?

As far as I can see, the Panda WGET server I get connected with from the DNS
routing from my IP address, is sent to a Panda server which is on a local time
zone somewhere here in the USA.  And that means that with a more or less common
update time for the Panda server here for the update being late in the 'local'
day here, I wind up not being able to get the update because the 'date' data in
the name for the file is the NEXT day from the file on the Panda server, which
wasn't even there some of the time by the time at 6:00 or 7:00 PM local (23:00
or 24:00 GMT) when the script is run.  So the request even if the file is there
comes back with the expected ERROR 404 for the Panda server.

I'm not sure how I want to try to mess with that now.  I guess one could do a
string conversion for the date data in the REXX script to convert it to a date
for 'local' time instead of GMT to do this.  In your case,it looks like because
your DNS service for a Panda server to handle this is 'coordinated' to your
local time, you don't have to worry about this.

As well, I'm still studying this, but I think I see that the PAV.SIG file which
comes from a Seamonkey download with the 'latest' and supposedly same day
archive, when it comes in from the WGET successful file pickup, isn't the same
size sig file.  As well, even when the Seamonkey file is downloaded when that
way says it is available, it may be hours before the SIG file is available yet
on the WGET server!

Hmmmmmm ..


--> Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
 * Origin: Ziplog Public Port (1:117/3001)