Dorris,

This may not seem too helpful, but I do believe that it is a legitimate answer:

The "platform" for the application should matter hardly at all (from a performance perspective).
It is the USAGE of the application which should dictate its performance characteristics. . .
. . . an INTERACTIVE real-time application should have sub-second response times for all clicking/enter-key except for its initial loading. A "start-up" time of 3 seconds to 333 seconds should be tolerated, but once started up vitrually all responses should happen in under 1 second. It should also be acceptable for some RARELY-USED functionality to take more time, the key being hardly ever used AND slowness known in advance to the user.
. . . Reports are a different story. There should generally be much more latitude here on the part of the user(s). And of course the volume of rows processed and tables involved also has direct bearing. *IF* you have a user who insists on a report being fast and frequent but it requires lots of rows/tables processing, then a reasonable appraoch is sometimes to maintain extra summarizations in the "regular" processing so that they can be quickly calculated/reported as required.

Also critical in evaluating "performance" is the state/capacity of the network. I have seen excellent performing applications look terrible in real life and the WHOLE PROBLEM WAS POOR NETWORK CONFIGURATION/tuning Once the network was "fixed" things were tickedy-boo.

so, to summarize:

1) You should explicitly define the performance expected, given the networking and concurrency of usage of the network. Get down to the "transaction" level and, if necessary, kinds of users. But do *NOT* vary them because of "platform" (language). The language chosen should be based exclusively on shop standards and other criteria hardly related to performance.

2) For reports, make sure your users are in synch with "performance" specifications. There are many other factors which affect the ability to deliver a report when wanted. For instance, if a perfectly accurate report of some particular point in time is required, then the ability to change the data used in the report must be PREVENTED. This usually limits such reports to overnight, during (online) "down" time.

Have fun
Jim N

I>All
>
>I'm in the position to suggest/propose performance standards for future contracts and I'm wondering what constitutes a 'reasonable' amount of time.
>
>I'm talking about NOT getting systems whose reports average 3-18 hours to run (yes, I said HOURS), screens that take upwards of 2-3 minutes to display, etc.
>
>We're talking Novell 3.x, 4.x networks, individual workstations are (on average) 486-66 DX's 16 M RAM and we run VFP, VFP/Sybase, MicroFocus COBOL, and will soon be stepping off into VB combing with various backends. I'm looking for suggestions, recommendations, etc..... especially for languages other than VFP/FP. Any help would be appreciated.