Clipper - Not allowed to run Clipper routine on Windows 2000 server

Author

Not allowed to run Clipper routine on Windows 2000 server

AnthonyL

2005-08-09, 8:59 am

The IT support staff at a site I am doing work for have banned the
running of a Clipper data extraction routine as they blame it for
unrecoverable errors on a Windows 2000 server.

As part of a data conversion project to SQL server I have a Clipper 5
application extracting and interpreting a number of dbf/dbt files from
a legacy system and producing new dbf files which are then imported
into SQL server.

The output process takes around 35 mins and is set to run via a DOS
batch file and scheduled tasks at 3am on a Saturday morning when no
other activity is taking place. It has been running every w

for
several months until 2 w

s ago (no changes my end!!)

The corruptions are said to:

a) have irreparably damaged my profile on the server (the job is run
unde my name).

b) have stopped the tape backup from working. They still can't make
it work.

c) made it impossible to install or un-install software on the server.

I am using Warplink and have set clipper=f51;e000 in the batch file.
oslib is used to prevent processor hogging.

The link file is:

ex +
,
,
,
clipper +
w:oslib106\lib\oslib + w:oslib106\cpmi\cpmi +
extend +
# TERMINAL.LIB goes
# in the root
terminal +
# DBFNTX.LIB goes
# in the root
dbfntx +

Am I being fed a load of bull**** or can running Clipper trash a
server? If so anything I can do to alleviate the issue. It is
unwieldy not to run the whole of the conversion process on the server
which is running SQL server.

Many thanks

--
AnthonyL

Markus Wiederstein

2005-08-09, 8:59 am

Anthony,

use xHarbour to compile your program and you'll have a native windows app.
Take a look at www.xHarbour.com and/or www.xharbour.org

Anyway, i don't believe that the problems on the server were produced
through your clipper proggy, it must be some other prob.

But this is hard to find out.

Markus

Am Tue, 09 Aug 2005 11:40:25 +0200 hat AnthonyL <nospam@please.invalid>
geschrieben:

> The IT support staff at a site I am doing work for have banned the
> running of a Clipper data extraction routine as they blame it for
> unrecoverable errors on a Windows 2000 server.
>
> As part of a data conversion project to SQL server I have a Clipper 5
> application extracting and interpreting a number of dbf/dbt files from
> a legacy system and producing new dbf files which are then imported
> into SQL server.
>
> The output process takes around 35 mins and is set to run via a DOS
> batch file and scheduled tasks at 3am on a Saturday morning when no
> other activity is taking place. It has been running every w

for
> several months until 2 w

s ago (no changes my end!!)
>
> The corruptions are said to:
>
> a) have irreparably damaged my profile on the server (the job is run
> unde my name).
>
> b) have stopped the tape backup from working. They still can't make
> it work.
>
> c) made it impossible to install or un-install software on the server.
>
> I am using Warplink and have set clipper=f51;e000 in the batch file.
> oslib is used to prevent processor hogging.
>
> The link file is:
>
> ex +
> ,
> ,
> ,
> clipper +
> w:oslib106\lib\oslib + w:oslib106\cpmi\cpmi +
> extend +
> # TERMINAL.LIB goes
> # in the root
> terminal +
> # DBFNTX.LIB goes
> # in the root
> dbfntx +
>
> Am I being fed a load of bull**** or can running Clipper trash a
> server? If so anything I can do to alleviate the issue. It is
> unwieldy not to run the whole of the conversion process on the server
> which is running SQL server.
>
> Many thanks
>
>

--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

AUGE_OHR

2005-08-09, 4:59 pm

hi,

>The IT support staff at a site I am doing work for have banned the
>running of a Clipper data extraction routine as they blame it for
>unrecoverable errors on a Windows 2000 server.

which Version of W2000 ?
which Service Pack ?
which Network Client ?
did you switch OFF "opportunistic locking" ?

> Windows application so the legacy DOS system (on Novell 3.12) can be
> finally retired.

so they go from a "stabil" NW-Server to a "unstable" M$-Server ...
tell your "IT support" to read M$ "knowledge base" before change from NW
to M$

have a look at Dave Pearson <davep@davep.org>
"VERY FREQUENTLY ASKED QUESTIONS"

greetings by OHR
Jimmy

AnthonyL

2005-08-10, 8:59 am

On Tue, 9 Aug 2005 19:57:44 +0200, "AUGE_OHR"
<AUGE_OHR_NOSPAM_@CSI.COM> wrote:

>hi,
>
>
>which Version of W2000 ?
>which Service Pack ?
>which Network Client ?
>did you switch OFF "opportunistic locking" ?
>
>
>so they go from a "stabil" NW-Server to a "unstable" M$-Server ...

Shame isn't it? But so many major applications only now run on MS-SQL
and the application is a vertical market product and a leader in its
field. What else can one do?

>tell your "IT support" to read M$ "knowledge base" before change from NW
>to M$
>
>have a look at Dave Pearson <davep@davep.org>
>"VERY FREQUENTLY ASKED QUESTIONS"
>

I think you have misread what is happening. The Clipper routine is
purely running data extractions. It is doing this as a scheduled task
on the Windows server and on a copy of the data that is not being
accessed by anyone.

The legacy application continues to run on the Novell server until the
new system is ready. (We were already aware that we could not move
the data files to the Windows server for the very reasons you state)

The server Windows Server 2000 (5.00.2195) SP3. It is not accessing
the Novell server. As a single user routine I have assumed
"opportunist locking" doesn't come into it.

--
AnthonyL

AUGE_OHR

2005-08-10, 9:59 pm

hi,

>
> Shame isn't it? But so many major applications only now run on MS-SQL
> and the application is a vertical market product and a leader in its
> field. What else can one do?

NW + ADS ?!

> I think you have misread what is happening. The Clipper routine is
> purely running data extractions. It is doing this as a scheduled task
> on the Windows server and on a copy of the data that is not being
> accessed by anyone.

Yes i got it, but where are your "copy of data" are coming from ( NW Server
? )

if the data is from the NW Server, which Client do you use on the W2000 ?
(my Memo field are corrupt using M$-NW Client / Copy to)
.... and if NW Server, which protocol ( IPX, frame) are you using ?

.... are you Cl*pper routine finish his job before crashing the M$ Server ?

did you try to change Warplink (have not used it) into e.g. Blinker ?

> The legacy application continues to run on the Novell server until the
> new system is ready. (We were already aware that we could not move
> the data files to the Windows server for the very reasons you state)

That is exactly what i do, but upgrade your NW 3.12 to 3.20 (get it @eBay)
and you can use allmost all NW4 driver e.g. SMC509 100Mbit or IDE > 8GB

> The server Windows Server 2000 (5.00.2195) SP3.

sp3 was better than sp4 ... :)

>It is not accessing the Novell server.

again : where are the "copy of data" coming from ?

>As a single user routine I have assumed "opportunist locking" doesn't come
>into it.

did you use append or replace ?
i found out there is a different speed.
if turn off it was more than 3 times faster in exclusive mode (without
index).

.... if i remember right, M$ did "opportunist locking" for M$-SQL only ?

greetings by OHR
Jimmy

AnthonyL

2005-08-12, 4:59 pm

On Thu, 11 Aug 2005 03:37:24 +0200, "AUGE_OHR"
<AUGE_OHR_NOSPAM_@CSI.COM> wrote:

>
>Yes i got it, but where are your "copy of data" are coming from ( NW Server
>? )
>

A Win98 machine (using M$oft netware login) copies the data (about
70mb) every night from the Novell server to the Windows server. It
has done this for around 3 years with no issues.

--
AnthonyL

AUGE_OHR

2005-08-12, 4:59 pm

hi,

> A Win98 machine (using M$oft netware login) copies the data (about
> 70mb) every night from the Novell server ...

hm ... M$ Netware Client using IPX (frame_802.3) was not very stable ...
or do you use IP with NW3.12 ? (if yes HOW ?)
i had a lot of "funny bugs" with M$ IPX Client ...

was it always about 70mb or does it grow up ?

>... to the Windows server.

did you use IP or IPX to connect into the W2K Server ?
did you use "DOS-Copy" or Cli*pper "copy to" ?

>It has done this for around 3 years with no issues.

so you are sure that your "source DBF" isn´t corrupt itself ?
did you verify it ? (e.g. create Index )
did your application "finish" before crashing the W2K Server

i saw you use "set clipper=f51;e000" so you do not use EMS.
is it a "real mode" application ? (don´t know Warplink syntax)
did you try to use a other Linker ?

greetings by OHR
Jimmy

AnthonyL

2005-08-13, 8:59 am

On Fri, 12 Aug 2005 22:05:31 +0200, "AUGE_OHR"
<AUGE_OHR_NOSPAM_@CSI.COM> wrote:

>hi,
>
>
>hm ... M$ Netware Client using IPX (frame_802.3) was not very stable ...

I'm not sure that I have ever, on any system, experienced a problem
with DOS copies.

>or do you use IP with NW3.12 ? (if yes HOW ?)

No.

>i had a lot of "funny bugs" with M$ IPX Client ...
>
>was it always about 70mb or does it grow up ?

Always around 70mB

>
>
>did you use IP or IPX to connect into the W2K Server ?

IP

>did you use "DOS-Copy" or Cli*pper "copy to" ?
>

Actually DOS xcopy.

>
>so you are sure that your "source DBF" isn´t corrupt itself ?

Yes the files are not corrupt. Even so how could this trash the
server?

>did you verify it ? (e.g. create Index )
>did your application "finish" before crashing the W2K Server

No, it hung as did the nightly tape backup that the W2K server takes.

>
>i saw you use "set clipper=f51;e000" so you do not use EMS.
>is it a "real mode" application ? (don´t know Warplink syntax)
>did you try to use a other Linker ?

Have always restricted EMS on all our Clipper applications which were
mainly Summer '87 or early Clipper 5. But the conversion routine is
not heavy on RAM and probably could use a simpler linker. The legacy
application with Warplink runs perfectly with multi-user access on the
Novell server.

I am coming of the opinion that other things brought the server down
and my conversion routine was just a casualty of it.

Cheers

--
AnthonyL

tom knauf

2005-08-15, 3:59 am

Hi,

do do all this bad things, I think your account must have administrator
privileges on the server ?
Is that so ?

Did the IT staff check the server logs, i.e. for harddisk problems ,
controller erorrs and so on?

I can barely imagine how a simple program should have done all this to a
stable server.

HTH
Tom

"AnthonyL" <nospam@please.invalid> schrieb im Newsbeitrag
news:42f87720.5289896@news.zen.co.uk...
> The IT support staff at a site I am doing work for have banned the
> running of a Clipper data extraction routine as they blame it for
> unrecoverable errors on a Windows 2000 server.
>
> As part of a data conversion project to SQL server I have a Clipper 5
> application extracting and interpreting a number of dbf/dbt files from
> a legacy system and producing new dbf files which are then imported
> into SQL server.
>
> The output process takes around 35 mins and is set to run via a DOS
> batch file and scheduled tasks at 3am on a Saturday morning when no
> other activity is taking place. It has been running every w

for
> several months until 2 w

AUGE_OHR

2005-08-15, 8:59 am

hi,

no more idea ...

this is one of those Msg about W98 / W2K :

*** snip ***

For WIN9X the following is the only registry setting we install on ALL
workstations

HKEY_LOCAL_MACHINE\System\CurrentControl
Set\Services\VxD\VREDIR\DiscardCache
OnOpen=1

For Win NT & 2000 (The first 2 are used if the computer is acting as a
server)

' HKEY_LOCAL_MACHINE\System\CurrentControl
Set\Services\'
' LanManServer\Parameters\CachedOpenLimit = 0'
' LanManServer\Parameters\EnableOpLocks = 0'
" LanmanWorkStation\Parameters\UseOpportun
isticLocking= 0"
" LanmanWorkStation\Parameters\UtilizeNtCa
ching= 0"
" LanmanWorkStation\Parameters\UseLockRead
Unlock= 0"

With these settings and the appropriate use of DBCOMMIT() after all
REPLACE/APPEND comands you should not have any caching problems.

"The location of the client registry entry for opportunistic locking has
changed in Windows 2000 from the earlier location in Microsoft Windows
NT. In Windows 2000, the registry entry that disables opportunistic
locking is:

HKEY_LOCAL_MACHINE\System\CurrentControl
Set\Services\MRXSmb\Parameters\
OplocksDisabled REG_DWORD 0 or 1
Default: 0 (not disabled)"

I have seen this and similar things happening in three distinct and
concrete cases on Windows and Novell networks. I have never
seen this on local or stand-alone computers, at least not with any
of the "official" Xbase++ releases -- even though several intermittent
versions had some issues with this!

Here are the three scenarios that I know for sure could lead to the
problems that you describe:

First, if you use a Windows 9x/ME computer as the "file server" for Windows
NT/2000/XP computers in a peer-to-peer network, you will (sooner rather
than later) get those kind of caching and lost-updates errors. There is
nothing
you can do about it, but making one of the Windows NT/2000/XP computers
your "server". And if you do that, you also have to make sure opportunistic
locking and caching is disabled, preferable on all of the computers, the
server as well as the workstations. And even if you have a dedicated
Windows NT/2000/2003 file server, you should still make sure that
opportunistic
locking and caching is disabled!

The second case -- which is much more seldom but also much worse, as it
will often lead to runtime errors and crashes -- is if you have the same
computer name and/or IP address for different workstations in a Windows
peer-to-peer or file server network. If the IP addresses are not unique, you
might not even get the program to start on both of the workstations at the
same time.
If the computer name is the same, access to the same database from both
workstations will wipe out each others changes, or lead to index or database
corruptions, which can lead to runtime errors or lost updates, as the wrong
record(s) might be updated or locked, or existing data might be overwritten,
or databases might be closed for no apparent reason.

The third case is related to Novell Netware networks. If you do not use the
correct Novell Client on each workstation, you might get all sorts of
problems, including the loss of updates. For Windows 9x/ME workstations,
you should only use Novell Client 3.32 SP.2 (and possibly 3.34 Update.C, but
I
am not so sure about that one), while for Windows NT/2000/XP workstations,
you should only use Novell Client 4.83 SP.2 or SP.3 (and possibly 4.9
SP.2).
All others will create lost updates, index corruptions, inability to open
Memo files, inability to create or update indexes, etc. In addition to the
correct Novell Client, you should also have the Novell Client's (Advanced)
Settings updated, to disable opportunistic locking and caching.

For Windows 9x/ME Client 3.x, you should update at least the following:
* Cache Writes: Set to OFF
* Close Behind Ticks: Set to 0
* Delay Writes: Set to OFF
* File Cache Level: Set to 0
* Max Cache Size: Set to 0
* Name Cache Level: Set to 0
* Opportunistic Locking: Set to OFF
* True Commit: Set to ON

For Windows NT/2000/XP Client 4.x, you should update at least the following:
* File Caching: Set to OFF
* File Commit: Set to ON

All of those problems definitely happen with shared databases and possibly
also with exclusively opened ones, but I don't know for sure, as I only use
exclusively opened databases for re-indexing or data conversions.

*** eof ***

greetings by OHR
Jimmy

AnthonyL

2005-08-16, 4:59 pm

On Mon, 15 Aug 2005 15:49:03 +0200, "AUGE_OHR"
<AUGE_OHR_NOSPAM_@CSI.COM> wrote:

>hi,
>
>no more idea ...
>
>this is one of those Msg about W98 / W2K :
>
>*** snip ***
>

for all the reasons you gave is why the legacy system remains on the
Novell server. We had a stable DOS Cobol application that was rock
solid until we put the shared data on a Windows machine. The
application expected record locks to occur when the program called for
the lock and not when Bill Gates felt like doing it, similarly with
writes.

--
AnthonyL

AnthonyL

2005-08-16, 4:59 pm

On Mon, 15 Aug 2005 09:44:39 +0200, "tom knauf" <hbgmail@pdtgmbh.de>
wrote:

>Hi,
>
>do do all this bad things, I think your account must have administrator
>privileges on the server ?
>Is that so ?

Yes

>
>Did the IT staff check the server logs, i.e. for harddisk problems ,
>controller erorrs and so on?

I'm keeping out of this.

>
>I can barely imagine how a simple program should have done all this to a
>stable server.

Agreed (if the server was indeed stable)

--
AnthonyL

Martin

2005-08-24, 6:55 pm

>>The data extraction routines are to get the data into SQL for a new[color=darkred]

Oh dear TWO downgrades!

Try Netware 6.5 and ADS 7.1

AnthonyL

2005-08-24, 6:55 pm

On Wed, 24 Aug 2005 16:05:37 +0100, "Martin" <spamspam@spam.spam>
wrote:

>
>Oh dear TWO downgrades!
>
>Try Netware 6.5 and ADS 7.1
>
>

Does the above allow for an application written for MSSQL to run?

--
AnthonyL

Ross McKenzie

2005-08-25, 6:55 pm

On Wed, 24 Aug 2005 20:00:22 GMT, nospam@please.invalid (AnthonyL)
wrote:

>On Wed, 24 Aug 2005 16:05:37 +0100, "Martin" <spamspam@spam.spam>
>wrote:
>
>
>Does the above allow for an application written for MSSQL to run?
>
>
>--
>AnthonyL

Anthony,

For what I am about to say, I apologise if it is totally irrelevant.

I was called into a local company recently because their legacy
C5.2/Six application needed to be forced to export data into a SQL
Server application (yet to be written). The original source code was
not available and the original programmers did not want to help,
except by selling a US$50k alternative/upgrade.

Through a series of minor proving steps, via an xharbour middleware
application, we have now got to the point where we can sense a change
in any of the 88 dbf (292Mbytes) without affecting the original
application's operations. The next step is to export the altered or
new records to SQL Server via XML. The generation of the XML file by
the middleware app is simply the creation of a self documenting text
file for each of the dbfs altered.

As I suggested, throw away as appropriate.

Regards,

Ross McKenzie
ValuSoft
Melbourne Australia

valusoft AT optusnet DOT com DOT au

AnthonyL

2005-08-26, 6:55 pm

On Thu, 25 Aug 2005 13:04:49 GMT, NoJunk_valusoft@optusnet.com.au
(Ross McKenzie) wrote:

>On Wed, 24 Aug 2005 20:00:22 GMT, nospam@please.invalid (AnthonyL)
>wrote:
>
>
>Anthony,
>
>For what I am about to say, I apologise if it is totally irrelevant.
>

<snipped>

>As I suggested, throw away as appropriate.
>

I would never "just" throw away anything you contributed Ross. We
wrote the legacy application in S'87 in the late 80's. It was a one
off in a very specialised market and not a market that we grew into.
We have since found a highly sophisticated internationally supplied
and supported product that does all the things that our package could
not do. That product runs in MSSQL. We are simply now doing the data
conversion to get from our legacy system to this new system in
conjunction with the new suppliers.

Simple process initiated by scheduled task on SQL server using a copy
of the legacy data that has been copied to the Windows server running
SQL.

1) Run an extract routine (Clipper 5) on the legacy data, interpreting
and re-organising as necessary.

2) Suck the data into SQL using DTS.

3) Run import routines to put the data into the final form required
for the new application.

Step 1) is being accused of bringing down the server.

There are lots of options but they do not include re-writing our
legacy system, abandoning the new software.

What I really wanted to know is whether anyone else had ever
experienced trashing a high spec (Compaq twin processor) Windows 2000
server by running a stable Clipper 5 routine basically doing nothing
more than reading dBase .dbf and .dbt files and writing them out again
in a different shape.

Cheers

--
AnthonyL

Norman Perelson

2005-08-27, 6:55 pm

"AnthonyL" <nospam@please.invalid> wrote in message
news:430f0717.74878709@news.zen.co.uk...
> On Thu, 25 Aug 2005 13:04:49 GMT, NoJunk_valusoft@optusnet.com.au
> (Ross McKenzie) wrote:
>
>
> <snipped>
>
>
> I would never "just" throw away anything you contributed Ross. We
> wrote the legacy application in S'87 in the late 80's. It was a one
> off in a very specialised market and not a market that we grew into.
> We have since found a highly sophisticated internationally supplied
> and supported product that does all the things that our package could
> not do. That product runs in MSSQL. We are simply now doing the data
> conversion to get from our legacy system to this new system in
> conjunction with the new suppliers.
>
> Simple process initiated by scheduled task on SQL server using a copy
> of the legacy data that has been copied to the Windows server running
> SQL.
>
> 1) Run an extract routine (Clipper 5) on the legacy data, interpreting
> and re-organising as necessary.
>
> 2) Suck the data into SQL using DTS.
>
> 3) Run import routines to put the data into the final form required
> for the new application.
>
> Step 1) is being accused of bringing down the server.
>
> There are lots of options but they do not include re-writing our
> legacy system, abandoning the new software.
>
> What I really wanted to know is whether anyone else had ever
> experienced trashing a high spec (Compaq twin processor) Windows 2000
> server by running a stable Clipper 5 routine basically doing nothing
> more than reading dBase .dbf and .dbt files and writing them out again
> in a different shape.
>
Hi Anthony,

Why don't you run the Clipper stuff on another computer. Then transfer the
converted data through a LAN.

Then Clipper can't possibly be blamed for bringing down the server.

Regards
Norman
---
Norman Perelson
www.shopkeeper.co.za

AnthonyL

2005-08-28, 6:55 pm

On Sat, 27 Aug 2005 20:38:44 +0200, "Norman Perelson"
<norman@shoso.co.za> wrote:

>
>"AnthonyL" <nospam@please.invalid> wrote in message
>news:430f0717.74878709@news.zen.co.uk...
[color=darkred]
>Hi Anthony,
>
>Why don't you run the Clipper stuff on another computer. Then transfer the
>converted data through a LAN.
>
>Then Clipper can't possibly be blamed for bringing down the server.
>

with all due respect Norman I am capable to working out such things
for myself. It doesn't however answer my question and I am being put
in a bad light by my client's IT support because they say my
application irrepairably brought down the server.

--
AnthonyL

Joe Wright

2005-08-28, 6:55 pm

AnthonyL wrote:
> On Sat, 27 Aug 2005 20:38:44 +0200, "Norman Perelson"
> <norman@shoso.co.za> wrote:
>
>
>
>
>
>
> with all due respect Norman I am capable to working out such things
> for myself. It doesn't however answer my question and I am being put
> in a bad light by my client's IT support because they say my
> application irrepairably brought down the server.
>
>

Don't let the client bully you.

Your application is not trying to bring their server down. Your Clipper
stuff doesn't know from servers. Clipper deals with DOS file specs like
"d:\import\coco\customer" and it is the server's job to do the "right
thing" given the spec.

If the client's IT Support claims your app broke their system, and it's
your fault, how do they address actual attempts to break it?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Norman Perelson

2005-08-28, 6:55 pm

"AnthonyL" <nospam@please.invalid> wrote in message
news:4311c1bb.95648074@news.zen.co.uk...
> On Sat, 27 Aug 2005 20:38:44 +0200, "Norman Perelson"
> <norman@shoso.co.za> wrote:
>
>
>
> with all due respect Norman I am capable to working out such things
> for myself. It doesn't however answer my question and I am being put
> in a bad light by my client's IT support because they say my
> application irrepairably brought down the server.
>
Anthony,

Maybe I should have expressed my idea more fully. Anyone with Clipper
experiance will "know" that it would take deliberately malicious code to
bring down a Windows 2000 server. The real problem is that it is
practically impossible to prove.

You can get expert opinions and assurances from any number of authorities
that will all say that your Clipper app could not cause the problem, but if
it happens again you will again be blamed. One way to prove that Clipper is
not to blame is to eliminate Clipper from the suspect server.

If you take a proactive and responsible action to remove your application
from the server, while at the same time maintaining your innocence, you
cannot lose - and if the server does crash again, you can laugh at them for
pointing a finger at you the first time it happened.

If I were you, I'd want to get as far away from that server as possible as
quickly as possible. I am sure that you also have other customers who
appreciate and trust your services.

Regards
Norman
---
Norman Perelson
www.shopkeeper.co.za

AnthonyL

2005-08-29, 7:55 am

On Sun, 28 Aug 2005 21:20:33 +0200, "Norman Perelson"
<norman@shoso.co.za> wrote:

>
>"AnthonyL" <nospam@please.invalid> wrote in message
>news:4311c1bb.95648074@news.zen.co.uk...
>Anthony,
>
>Maybe I should have expressed my idea more fully. Anyone with Clipper
>experiance will "know" that it would take deliberately malicious code to
>bring down a Windows 2000 server. The real problem is that it is
>practically impossible to prove.
>
>You can get expert opinions and assurances from any number of authorities
>that will all say that your Clipper app could not cause the problem, but if
>it happens again you will again be blamed. One way to prove that Clipper is
>not to blame is to eliminate Clipper from the suspect server.
>
>If you take a proactive and responsible action to remove your application
>from the server, while at the same time maintaining your innocence, you
>cannot lose - and if the server does crash again, you can laugh at them for
>pointing a finger at you the first time it happened.
>

The routine has been running at least w

ly on the server for the
best part of 6 months and runs at least w

ly on my XP Pro laptop.

If no-one here has experienced similar issues then I deduce that the
IT Support people are talking rubbish and it was a server issue that
brought my application down.

The only conclusive responses would be:

a) if I could replcate the failure by running the routine again on the
server

or

b) as you say, if the server collapsed again without the routine
running.

Unfortunately the server has now been replaced and I am not allowed to
run the routine on the new server so the facts may never be known.

--
AnthonyL

Ross McKenzie

2005-08-29, 7:55 am

>
>Unfortunately the server has now been replaced and I am not allowed to
>run the routine on the new server so the facts may never be known.
>
>
>--
>AnthonyL

Anthony,

It sounds like you are the victim of a "kangaroo court". The "High
Priest" of the server won.

AnthonyL

2005-08-30, 7:55 am

On Mon, 29 Aug 2005 10:41:18 GMT, NoJunk_valusoft@optusnet.com.au
(Ross McKenzie) wrote:

>
>It sounds like you are the victim of a "kangaroo court". The "High
>Priest" of the server won.
>

Put as one would expect from someone Down Under :)

Hope you are enjoying the Tests.

--
AnthonyL

Ross McKenzie

2005-08-30, 6:55 pm

On Tue, 30 Aug 2005 11:06:30 GMT, nospam@please.invalid (AnthonyL)
wrote:

>On Mon, 29 Aug 2005 10:41:18 GMT, NoJunk_valusoft@optusnet.com.au
>(Ross McKenzie) wrote:
>
>
>Put as one would expect from someone Down Under :)

Personally, I am not a big supporter of the "geographically determined
origin of vocabulary" hypothesis.

>
>Hope you are enjoying the Tests.

Yes, it is a refreshing change to see England put a team on the field.
The fifth test may see us retain the Ashes yet. All good for the game.
Pity your bowlers don't seem to have the stamina to stay on the field
after their overs. Must have awfully weak bladders....but then we do
describe your beer as p@^s <g>.

>AnthonyL

Regards,

Ross McKenzie
ValuSoft
Melbourne Australia

valusoft AT optusnet DOT com DOT au

Ian Boys

2005-08-31, 3:55 am

> Yes, it is a refreshing change to see England put a team on the field.
> The fifth test may see us retain the Ashes yet. All good for the game.
> Pity your bowlers don't seem to have the stamina to stay on the field
> after their overs. Must have awfully weak bladders....but then we do
> describe your beer as p@^s <g>.

Is that why Shane was in training with those diuretics?

Ian Boys
DTE

Ross McKenzie

2005-08-31, 7:55 am

On Wed, 31 Aug 2005 07:31:41 +0000 (UTC), "Ian Boys"
<TooMuchSpam@BTInternet.com> wrote:

>
>Is that why Shane was in training with those diuretics?
>
>Ian Boys
>DTE
>
>

Probably.

Regards,

Ross McKenzie
ValuSoft
Melbourne Australia

valusoft AT optusnet DOT com DOT au

AnthonyL

2005-08-31, 7:55 am

On Tue, 30 Aug 2005 22:55:22 GMT, NoJunk_valusoft@optusnet.com.au
(Ross McKenzie) wrote:

>On Tue, 30 Aug 2005 11:06:30 GMT, nospam@please.invalid (AnthonyL)
>wrote:
>
>
>Personally, I am not a big supporter of the "geographically determined
>origin of vocabulary" hypothesis.
>

it was the reference to the 'roos that gave it away mate.

>
>Yes, it is a refreshing change to see England put a team on the field.
>The fifth test may see us retain the Ashes yet. All good for the game.
>Pity your bowlers don't seem to have the stamina to stay on the field
>after their overs. Must have awfully weak bladders....but then we do
>describe your beer as p@^s <g>.
>

don't get me onto that. Unless you down yours within 30secs of being
served it also is p@^s. Took me 3 years to get used to it then when I
got back here it took another 3 years to get used to ours again. btw -
we drink pints at a time here not 5oz. which explains the extra trips
required :)

--
AnthonyL

AnthonyL

2005-09-01, 7:55 am

On Wed, 31 Aug 2005 14:11:04 GMT, NoJunk_valusoft@optusnet.com.au
(Ross McKenzie) wrote:

>You must have been in NSW. Here in Melbourne its 7 and 10 oz.

Perth

>Why did you go back?
>

It was a mistake, I took a wrong turning somewhere :(

--
AnthonyL

Ross McKenzie

2005-09-01, 7:55 am

On Thu, 01 Sep 2005 11:31:50 GMT, nospam@please.invalid (AnthonyL)
wrote:

>On Wed, 31 Aug 2005 14:11:04 GMT, NoJunk_valusoft@optusnet.com.au
>(Ross McKenzie) wrote:
>
>
>
>Perth
>
>
>It was a mistake, I took a wrong turning somewhere :(

Well you can come back. All is forgiven <VBG>

>
>
>--
>AnthonyL

Regards,

Ross McKenzie
ValuSoft
Melbourne Australia

valusoft AT optusnet DOT com DOT au

Joe Wright

2005-09-01, 6:55 pm

AnthonyL wrote:
> On Wed, 31 Aug 2005 14:11:04 GMT, NoJunk_valusoft@optusnet.com.au
> (Ross McKenzie) wrote:
>
>
>
>
>
> Perth
>
>
>
>
> It was a mistake, I took a wrong turning somewhere :(
>
>
In Sydney (many years ago now) its the midi at 10 oz. and the pint at 20
oz. Seven ounces seems a strange size for a beer glass.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Ross McKenzie

2005-09-01, 6:55 pm

On Thu, 01 Sep 2005 17:32:23 -0400, Joe Wright <jwright@comcast.net>
wrote:

>AnthonyL wrote:
>In Sydney (many years ago now) its the midi at 10 oz. and the pint at 20
>oz. Seven ounces seems a strange size for a beer glass.
>
>--
>Joe Wright
>"Everything should be made as simple as possible, but not simpler."
> --- Albert Einstein ---

Hi Joe,

The sizes and names of beer orders has long been used as a means of
identifying a "foreigner" in the pub <g>.

Seven ounces (200 ml) is called a "glass" in both NSW and Victoria.
But here in Victoria we call 10 ounces (285ml) a "Pot", whereas in NSW
it is called a "Middy".

The following link, interestingly maintained by the University of NSW
(probably the Faculty of Good Times), has a good summary.

http://www.cse.unsw.edu.au/~jas/beer/misc/

Regards,

Ross McKenzie
ValuSoft
Melbourne Australia

valusoft AT optusnet DOT com DOT au

Sponsored Links