> Web enablement of data access is another kettle of fish. All > computers are really good at doing what you tell them to do. > I'm already dealing with this one on several fronts as > applications move away from "green screens" to web front ends. > I mention it more as what possibilities the whole CD install > opens us up to.
The install method has nothing at all to do with the functionality that is installed or to the way that functionality is ultimately delivered to the user. You can install "web-enabled" functionality through normal SMP/E channels and you can install non-web functions through CD installers. The thing that lays down the bytes is not at all related to the bytes it lays down. Typically. Its easy to come up with counter examples and there are many examples of bad design. It is at least as easy to deliver badly designed user interfaces in "green screens" as it is in other UI's. So my point on this is; its not the user interface, its the design. Don't assume that they are the same thing. > The "enter" key was always a limiting factor in an end user's > hand's on process of using computers. Now "point and click" > trigger of a humongous data download becomes more slippery to > control. Applications developed by hand by your own programmers, > or a hired vendor, were one thing, CDs arriving for trials are another. Not at all. A user sitting in QMF can trivially cause an outer loop (table scan) join of two 90 million row tables. That's for sure going to keep your bad-ass high end z990 busy for a looooooooooong time. Once again, keep in mind the only issue is the application. The way it is delivered is irrelevant. > Accountability for resource use, like I/O, CPU, and customer data, > becomes more murky as users can install things like this. I now have > more to be concerned about, in my opinion, when programmers > can load up these kinds of things in "an hour". Two responses. One. Its fundamentally not our job to say NO to the business. The computer system and its resources exist for the business. If the business wants to burn resources (efficiently or not, its irrelevant to this issue) on outer loop joins, its your job to say "yes sir, this is what you're going to need to do to get your job done." If that means they have to buy another godzilla box, its their -business- choice to make. They may be willing to do that if its important enough to the business. More likely they will want you to figure out a way they can get their job done without buying another godzilla. That's called career enhancement opportunity. Two. The accountability of resources like I/O, CPU etc is again, no different. You already have (presumably) work arriving from multiple places, 3270s, atms, (G)UIs, etc. The origin of the work is not terribly relevant. It is not rational to allow access to those resources (and especially to data) without a logon with a userid and password, or some equivalent credential such as a digital certificate. If you are controlling access appropriately then "see point one". If you are not controlling access then its an entirely different issue, but again, there's nothing inherently bad or different in the means of accessing that functionality. CC ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
