WM wrote: > I think you're on the right track, John. I've got a kind of > half-developed theory that staff that grew up in the mainframe era, > where computing resources were extremely expensive and data centers > were, actually, awesome, take their work very seriously. > > Conversely, staff that learned on small Intel or Unix systems that were > easily available and may have just been in their basement, of course, > never had the concept that this is serious stuff requiring an > engineering approach. The stakes were lower. And of course with > develoment tools beyond 3GL languages, the effort to get *something* > programmed is much lower. Less entry barrier for writing simple > applications. Think MS Access here.
I've often voiced a different perspective on the subject. many of the mainframes grew up with a batch paradigm ... which implied that the responsible person wasn't around when the program was being run ... and therefor a huge amount of hueristics grew up over the years about the system taking care of the stuff itself. Correllary is that the huge body of stuff for system operational characteristics eventually has created a steeper learning curve for people wanting to do industrial strength dataprocessing. The alternative are the systems evolving from the interactive, desktop paradigm ... which assume that the responsible person is right there and the system can always rely on a human for resolution rather than having it figured all out by the system. So almost all servers these days (even in the internet world) tend to have industrial strength dataprocessing requirements ... even when the server clients are of the desktop variety. The batch paradigm with the system having resolution responsible also applies to many of the online environments (as opposed to the strictly interactive kind) ... for instance large ATM cash machine network ... when there is a problem, doesn't really want the customer out at an ATM machine, exercising administrative type operations on the core authentication & authorization engine. part of the issue in large server infrastructures ... is that while the actual $$/mip has drastically decreased ... the aggregate value involved when there is a glitch in a large online system might be enormous (because of possibly involving an impact for thousands of people). ... various past postings regarding batch paradigm platfroms vis-a-vis interactive paradigm platforms http://www.garlic.com/~lynn/98.html#18 Reviving the OS/360 thread (Questions about OS/360) http://www.garlic.com/~lynn/98.html#51 Mainframes suck? (was Re: Possibly OT: Disney Computing) http://www.garlic.com/~lynn/99.html#16 Old Computers http://www.garlic.com/~lynn/99.html#197 Computing As She Really Is. Was: Re: Life-Advancing Work of Timothy Berners-Lee http://www.garlic.com/~lynn/2000f.html#58 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.) http://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit http://www.garlic.com/~lynn/2004.html#40 AMD/Linux vs Intel/Microsoft http://www.garlic.com/~lynn/2004.html#43 [Fwd: Re: Mainframe not a good architecture for interactive w http://www.garlic.com/~lynn/2004b.html#10 Mars Rover Not Responding http://www.garlic.com/~lynn/2004c.html#28 Moribund TSO/E http://www.garlic.com/~lynn/2004o.html#21 Integer types for 128-bit addressing .... this is a test ... my recent newsgroup postings have been forwarded to the mailing list processor ... but are being bounced (even tho I'm otherwise authorized) ... will see if this direct mailing works. a few of the recent bit-listserv.ibm-main postings ... a couple may have been manually handled for the mailing list: http://www.garlic.com/~lynn/2005o.html#45 Article: The True Value of Mainframe Security http://www.garlic.com/~lynn/2005o.html#46 Article: The True Value of Mainframe Security http://www.garlic.com/~lynn/2005o.html#47 Article: The True Value of Mainframe Security http://www.garlic.com/~lynn/2005p.html#0 Article: The True Value of Mainframe Security http://www.garlic.com/~lynn/2005p.html#13 One more about SYRES Sharing http://www.garlic.com/~lynn/2005p.html#15 DUMP Datasets and SMS http://www.garlic.com/~lynn/2005p.html#16 DUMP Datasets and SMS http://www.garlic.com/~lynn/2005p.html#17 DUMP Datasets and SMS http://www.garlic.com/~lynn/2005p.html#18 address space http://www.garlic.com/~lynn/2005p.html#19 address space http://www.garlic.com/~lynn/2005p.html#20 address space http://www.garlic.com/~lynn/2005p.html#29 Documentation for the New Instructions for the z9 Processor http://www.garlic.com/~lynn/2005p.html#34 What is CRJE http://www.garlic.com/~lynn/2005p.html#37 CRJE and CRBE http://www.garlic.com/~lynn/2005p.html#38 storage key question http://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3 http://www.garlic.com/~lynn/2005q.html#0 HASP/ASP JES/JES2/JES3 ---------------------------------------------------------------------- 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
