Good catch but it makes me wonder how the SC/CM is managed today? Open or closed source is vulnerable for developer access. I can understand that open source projects don't always have resources to run full SC/CM systems but I don't see full control even in some closed source environments I know. It is not difficult but needs some planning and computer resources, not human resources! Almost only places I have seen that kind of system controls are some insurance, banking (less often) and governments (often a mess). It is not just security, mistakes happen, and on long run it always pays back, try to tell that to management(heh!) Maybe I'm biased but after a couple of mishaps a long time ago we implemented a SC/CM system to protect against unverified and/or untested systems going to production and several other companies started using similar methods after us. It really can be automated with some planning. First everybody hates it and 6 months later they love the benefits, as I said, everybody makes mistakes and one command recovery is very nice when that happens before anything goes wrong.
When you hear the voice "hey, good looking, take the next door, third floor, 3001" you start understanding the potential of technology helping people. The poor persons don't have to stand on the street, in cold and rain, but they can more efficiently work inside. Or maybe if you like other good things in life "Step in, we have a whiskey tasting going, happy hour just started, and so on.."
Yes, HP wins. And they have to, they have Tandem ( NonStop ) previously de facto stock exchange system but for several reasons now diminishing even if used where large transaction support is needed, IBM has AIX and Linux, Sun has (open) Solaris and maybe a little Linux ( can't really make sense of that? ) and MS doesn't yet have anything but hungry to get to the field. Good for HP and Linux and very good for NYSE, it changes times back when the users were more active on their systems instead of just paying packages and letting vendors to run their business. And if you ever have used HP-UX ( and other system ) I think you will agree that it is not a viable solution, HP has done some work on that but not enough (IMHO.)
Re:Guarantee of Reliability is not Free (as in bee
on
NYSE Moves to Linux
·
· Score: 1
Correct, except maybe that Cobol ( I don't like it but ) is way over C/Java in business. Once you have done fixed point calculations in C (Java,C++,C#,,,pick your language..) you start understanding what it means to trust the language doing the right thing. Also, I still hope other languages would get the native data types, no problems moving from one platform to another. And maybe another thing about mainframes, you can run 10K+ servers ( Linux ) in one box that will not break down. Now, it depends of application types, should you? Huge transactions, lot's of data, are the best in mainframe, think moving data in xxx GB's/second between your servers without external lines, controllers, switches, and so on, almost at memory speed through standard TCP/IP connections. Think about systems with hundreds of CPU's where one, two, three,.. failures only means slowing down a little and only if you are already running near %100 capacity. Of course workload balancing may actually be a little more tricky than in distributed servers but other reasons which can be learned. Stock exchange transactions are small (actually very small) so they may be better in server farms today but the design is not easy, who wants to lose a $100 million sale / buy order! Also, I wonder how they handle the timings? Remember last panic, everybody selling, servers queuing hours, arguments later whose transaction was 1 microsecond before some other? It took years, FCC and courts to solve. Anyway, hats of for NYSE, I remember when Tandem was an unknown and some stock exchanges and banks took the leap and trusted them. Correctly built Tandem systems are still the only real NonStop systems but need skills you can't easily find today. And HP is not helping on that because, like it or not, Tandem is a niche system today and HP doesn't like diversity.
I knew that. It is actually a funny comment if I would have had any points left. The problem I have are the younger/. users who take these literally. Last week talking a couple of a managers in a huge software company - they really believe those things so I'm a little too touchy just now, it will go over after Xmas, I hope.
You are absolutely right. But think what would happen if any side would fix their ways? They would win and then we wouldn't have ( any needs ) for/. etc any more. As painful all the different views are, they create different paths for future systems and, of course, more work for us. Yes, Microsoft has a lot of very, very good people, fortunately, as you say, the management screws it up enough so we don't all have to go MS way but pick up what good comes out from MS development and forget the rest. I love what MS, IBM, Sun, HP, Fujitsu, Hitachi, even Cisco, Nokia, Oracle, etc creates with their huge research budgets, they are different enough to give some very good ideas. I don't have to use their OS, programs, what ever but just the ideas are enough, you don't have to use their OS, programs, "IP", etc but the ideas which can not be patented or protected by copyright ( at least not in a sane world, sorry to add this! )
A perfect comment! I can understand the top level management because for them IT is just a corporate function, one of many, but save me from middle management who do not understand the mechanics they are supposed to manage. They don't have to and they don't really always have time to be specialists on subjects but they should (must) have a very good understanding how and why some things work the way they do. Now, unfortunately, even I think everyone understands that but lately it has gone worse which means more politics and inside fighting instead of doing a good job and more profits for company.
A very good comment, as the first response! My experience over long time before there was a Microsoft, they are not alike any other company. I'm a software developer who has to see the whole infrastructure, not just a small piece of it and I have the same experience, not that Microsoft is any different of other vendors I have had to deal over years but currently.. They had things going (almost) right with NT and even XP was still on ballpark but lately, give me a break! As you, I have to design / develop secure, non failing, 24x7, etc systems which work with standard protocols, interfaces, frameworks, existing hardware and so on and what I see is that Microsoft wants to redefine those. Not a bad idea in itself but we have huge infrastructures already running by current standards and any disruption to that will not work without big changes and a lot of new work, be it a protocol, hardware, API or even the user experience. Of course, good for us, more work but for users, corporations, etc it will have a cost and problems.
OT and old but just have to answer to this. Cobol, PL/I, Fortran, etc or mainframes had nothing to do with Y2K! In 70's I had several large insurance, government, bank, army, manufacturing companies as my customers and none (zero) had Y2K problem. Why, because they all designed their systems capable calculating +/- 100 years. Y2K was the problem of very bad design, it happened then as well as today. And it is not the developers fault if the system, data, displays, etc are designed wrong. Unfortunately this hasn't changed, I see bad designs today as much as ever and actually more because systems have grown and have more interacting components. Bad especially in networks, SOA implementation, and so on, why do you think support costs haven't gone down but up? I'm great believer on agile, XP, SCRUM, etc, they work very well but but only if they have a whole system view, not in vacuum, too easy to test one component which works well alone or in small test systems but breaks when brought to dynamic infrastructure. The same could be said of threading, multiple cpus, etc. All (almost) my customers were ready for that at end of 70's, beginning of 80's. Systems were designed to run parallel tasks, asynchronous I/O, threaded (tasks) queries, background audit and statistics, shared disk farms, etc from ground up.
Great, now they have a tool to encrypt! Let's hope they thought about key management before implementing it. It's great for vendors that some have no idea of security - more sales. Next we will read all the keys stolen by an employee (usually high in hierarchy, just my experience) and have to start all over again. Or am I too pessimistic / skeptical when it comes to security?
The patent describes an Ericsson PPX/pager/phone system I was using in early, mid 80's perfectly except it didn't use names to display the caller but the telephone numbers. Once you contacted(phoned) the PPX you got the names of the caller(s) in voice (if programmed in PPX) and a list of messages by caller in any order you selected. You could listen, skip, delete and archive those messages for later use. You could also tell the PPX to call back the caller or reroute the calls to another phone(user) or start a conference call or etc.. But no visual except there were "intelligent" phones which gave you the list of numbers on a small display, number and time of each message, capability to listen any or none, save or delete and archive, call back the caller, etc. So, the only real difference was the visual maybe because of the technology at that time. Now - there was even earlier the huge (and expensive) IBM PPXs, I just don't remember all its capabilities but they did interesting tricks with messages no matter in which country you were and maybe it did show the names on 3270(heh!) Really have to wonder what can be patented today and how broken the whole system is! It is so obvious to connect names to numbers / messages / whatever once you have a little memory and a small processor. And caller ID.
A good comment! And the IP part is important, you just can't take any code you see, you can read it and code the solution yourself in most cases but there are some darn patent issues - stupid laws patenting algorithms ! Another good point in comment "every good programmer should take the time to create a really good library" And this should go without saying, build your own library of templates and snippets you carry as long as you do coding, often saves a lot of time. Some companies which use SM/CM ( source/configuration management ) have ready made / canned templates, snippets, etc already bound to editors, IDEs, and so on. Unfortunately very few. Just don't get too hooked to those, some day you are in environment where the only tools are notepad or vi and a compiler, how to start now? And usually in those systems all the help files, man pages, etc are nonexistent. Also, be careful, code may be written to specific platform, OS, compiler, etc. I'm tired of fixing for example code written to PPC when compiling for x86 or 32 bit code going to 64. Did you think all systems have bytes in same order? Did you think all compilers and systems align same way? Did you think that all systems let you manipulate the stack? Did you think they are on same POSIX level? Did you think that objects with same names are equal? Well, you were wrong. Especially some Unix developers with fast cut and paste fingers have created millions of lines such code ( just my experience, sorry ) Another ( one of many ) issue, did the original code writer think security? Ouch - all the string functions, etc. Yes, even if the code comes from experienced developers and (currently) well behaving systems does not guarantee that it will work for you. All that said, old code is a great source to learn especially if you are new and you have someone to explain it.
Rated as funny and, yes, it seems funny today. I'm from time we had secretaries and I miss those times. Scheduling between internal and external (customer) connections is PITA. The secretaries were able to negotiate, no system can do that, it is out of your time. They knew personal things what you never would put to any scheduling system, bring flowers or a bottle of whiskey to next meeting because the big boss has a birthday, whatever. They reminded you of all the papers you will need to take to the meeting, they had your flights ready, they proposed to have another person to go with you or just sending another person because whatever reason, etc. No calendar, scheduling, computer system can never do that and it is out of your time - sometimes a lot! So hire an assistant!
Re:Don't get in over your head...
on
Head First SQL
·
· Score: 1
Yes, you are right. My gripe is that too often it is the integration without planning / design. It is not the developers / DBAs fault but how the management sees it and buys all the marketing hype "this product solves all your business problems"! Information management, what any database is supposed to be part of, is really not an easy thing but I still think there should be someone in company responsible of that. Nothing new, same with security, performance, development environment, etc. We still too often (IMHO) make things in vacuum, too specialized for one small part of the system, whatever. This actually can accelerate the development, pieces and parts can be built to common good, think for ex. SOA.
Re:Don't get in over your head...
on
Head First SQL
·
· Score: 1
Very insightful. IMHO this is the problem today, learn a little of one product dialect and you are the master of information management, yeah, great! Vellmont is absolutely right, database design is much more and corporate information management in those databases is even more. Even if a good start can be found in books it needs years, most often very specific industry knowledge and every day learning before you can master it. SQL dialects, structures, tables, even normalization are easy but really the future needs, capacity, performance, expandability, predicting changing business needs and technology, etc are totally another ballpark. And I'm not a DBA, just a person who has gone through all the pain designing and managing huge amounts corporate information over years from card sorters through direct access, structured files, relational algebra to modern(?) object databases and still learning. Nothing against the book, haven't read it but just the impression often given and bought by some corporations, the way to trouble which someone else then have to fix ( try to fix. )
I would like to comment this and turnaround. Some countries have laws for billing and salary systems so you better be fast otherwise someone may in worst case lose their business license, you or your customer, or at least it is very costly. About the bug in OS, if it has an effect to your business, you again better be fast. Been there, done that 2am for a system on other side of globe. IMHO the mainframe support is the best, my dealing with IBM and they were always able to deliver a PTF ( program temporary fix ) in hours at any time of day.
Some have already mentioned that it is not possible to answer your question without more knowledge but we all have opinions, this is/. All I can add that it depends, if you rush just for a change order there is something wrong with your management. If you take 48h to fix a problem for a 24x7 something else is a problem. I like that toilet paper answer except - I once had a paper mill as a customer, simple ? application taking care of the warehouse. The problem, 6pm 100 miles away it started crashing but it is just the warehouse application? Except, if you can't manage a warehouse you have to stop the production, if you can't manage the warehouse you can't send the paper out, nobody can track all that without a computer. So the estimated deadline was midnight and after that 3 ships would sail without paper, machinery stopped and restarted, cost XXX millions. Not 48h, not even 12h to fix - I got the system fixed 11.45pm by patching a live/running system in memory ( with help of a person in other country more experienced of that part of the system ) So, yes, I have taken my time to fix something and lazy as I am, sometimes days but (un)fortunately most my customers are/have been 24x7 - you fix it now ! So, case by case and remember to build your system they way they are easy to analyze and easy to fix.
Yes, I totally agree! But try to make any corporate management to understand that, no way (yet?) OS can not protect when application makes stupid things. And for me, if you build a stack, it is an applications, if you build a driver, it is an application, if you build the authorization server,.. you get the picture. Unfortunately security is not (yet?) very high on list, even lower than performance in most cases I have seen. As you say, it is the design! There may be code problems but if the design is good they usually are very easy to test and find or the application just doesn't work. Now, especially lately, I have seen bad or no design at all, the word for developers is use this/that vendor/OS/IDE whatever and don't worry, it will work, you don't have to know/think such things like security/performance/manageability/testability/etc. Sad!
You don't loose the mainframe, it may slow down a little for some part of it failing, but it may come unavailable for external reasons, loosing all electricity in installation, earthquake, flood, even terrorists or one postal worker, whatever. Now your normal backup procedures kick in, did you think you can work without those even if you have a mainframe? It is actually simpler with a mainframe than a server farm, you don't have to reload nnn systems, connect them to network, configure whatever, etc. You simply tell your backup site ( if they already are not already up and running, remote monitoring! ), to load the system and you are done. Designed a couple of those, tested, never used in real emergency but never failed. And if you have important enough business for continuous processing your IT will have one!
Yes, the talk is about less CO2 but how little./ readers know about mainframes and business systems overall? Fortunately I see some answers which save the day, thank you. And I want to emphasis their point, if you don't know what mainframes do, go and learn. I could tell you from 70's, 3000+ users, 512KB memory, 1MIPS mainframes (the measuring base for later, IBM 158), 8000+ online applications ( big transactions ), 1 second response times, etc but you have to see it and there are no such things any more. Yes, mainframes are totally different beasts of your super, 3GHz+ PC. Nothing wrong in that but the throughput of those systems is way beyond even large server farms. And, as someone mentioned, nothing new in VM, bring your online systems up for testing in VM, bring your whole OS up, bring one up for coding and unit testing, all old. And we had no problems showing microfilms, faxes, etc in those green terminals. Actually most changed to color later on. And if you really needed graphics, Tektronix or some CAD station for very high definition graphics did that. More expensive at that time, of course, what technology wasn't, but available. And the reliability is really something else, not just availability(HA) or NonStop(Tandem) but they just keep running, software bugs excluded there Tandem may still be better but just a little. I almost forgot, mainframe security is something other systems just dream!
Now, places who want a secure environment / systems have been doing this a long time. An insurance company where I did work in 70's and I was part of security, managing mainly systems and operations access security, we had a company once/twice a year making a check. And I can tell you, they found a lot of ways in, loose papers, open terminals, unlocked doors, whatever. Very useful. Haven't done that for a while but you should see the Swiss bank security or the France military security, scary. And these guys who did the work for us, they sometimes were even able to penetrate those, don't know to what level but even a small is bad. So, let's hope they do a good work before someone else does it. And they also did other security checks so don't talk too much business after a couple of beers, charming fellows!
Maybe it's me, I'm sure it is just me, but lately it seems that there is more lost and found mass in universe than files in a system? Maybe it is more difficult subject? I'm waiting when they get the final numbers out, I'm still under 1000 years old.
Right except they don't have to be on same OS. It is enough to be on same platform today, one system or cluster or even in servers. What the user cares is to be able to use all together, 1 to n displays, same inpute devices, cut/paste between apps, same file system/directories access, etc. And that is available today in many ways so OS is the smallest problem, in case of Adobe the graphics shared between systems is a pain but I think Adobe could solve that. It is a problem that has not had a high priority.
That is a good idea. Make your application an appliance, boot/load/run it in OsX, Windows, Linux, x86(32 or 64), PPC, whatever. I know a lot of people who would love that. And I have been running VMWare, other VM's a while in x86(32 and 64) and in MacBook ( my favorite, run Osx, XP and Linux at the same time ) with many appliances, Linux, Solaris under XP(Windows), XP, Linux, Solaris under Linux, Linux, XP, Solaris under OsX without any problems. Now, the graphics could/should use some upgrading for Adope type work but otherwise it just works. There are ways to make the graphics work but the virtual system manufacturers don't seem to have it as a priority today, just wait a while.
Hi, yes and no. 370 runs 360 code but, as too often even today, people coded to bypass the OS. Old devices, drums, paper / magnetic card readers, terminals, channels, etc. Even todays systems have the idea, VM especially, of 80 column cards, punches, readers, etc and if used correcly they work wonders, trust me, 360 architecture is one of the best even today. The problems is that not too many people any more want to learn the basics, i.e. Priciples of Operation ( any 3xx, a good book to read, required reading, IMHO ). Search on which OS version macro libraries Linux ( 370 HAL ) was first compiled on 360/370, you will be amazed. Emulations in 360-xxx mostly mean address space differences ( 24/31/32/64/.. ) and some added machine code / functionality, done by OS/hardware. And of course a long time trapping the floating point was/is(?) one if you didn't have the fp hardware installed.
Slashdot Mirror
Good catch but it makes me wonder how the SC/CM is managed today? Open or closed source is vulnerable for developer access. I can understand that open source projects don't always have resources to run full SC/CM systems but I don't see full control even in some closed source environments I know. It is not difficult but needs some planning and computer resources, not human resources! Almost only places I have seen that kind of system controls are some insurance, banking (less often) and governments (often a mess). It is not just security, mistakes happen, and on long run it always pays back, try to tell that to management(heh!) Maybe I'm biased but after a couple of mishaps a long time ago we implemented a SC/CM system to protect against unverified and/or untested systems going to production and several other companies started using similar methods after us. It really can be automated with some planning. First everybody hates it and 6 months later they love the benefits, as I said, everybody makes mistakes and one command recovery is very nice when that happens before anything goes wrong.
When you hear the voice "hey, good looking, take the next door, third floor, 3001" you start understanding the potential of technology helping people. The poor persons don't have to stand on the street, in cold and rain, but they can more efficiently work inside. Or maybe if you like other good things in life "Step in, we have a whiskey tasting going, happy hour just started, and so on.."
Yes, HP wins. And they have to, they have Tandem ( NonStop ) previously de facto stock exchange system but for several reasons now diminishing even if used where large transaction support is needed, IBM has AIX and Linux, Sun has (open) Solaris and maybe a little Linux ( can't really make sense of that? ) and MS doesn't yet have anything but hungry to get to the field. Good for HP and Linux and very good for NYSE, it changes times back when the users were more active on their systems instead of just paying packages and letting vendors to run their business. And if you ever have used HP-UX ( and other system ) I think you will agree that it is not a viable solution, HP has done some work on that but not enough (IMHO.)
Correct, except maybe that Cobol ( I don't like it but ) is way over C/Java in business. Once you have done fixed point calculations in C (Java,C++,C#,,,pick your language..) you start understanding what it means to trust the language doing the right thing. Also, I still hope other languages would get the native data types, no problems moving from one platform to another. And maybe another thing about mainframes, you can run 10K+ servers ( Linux ) in one box that will not break down. Now, it depends of application types, should you? Huge transactions, lot's of data, are the best in mainframe, think moving data in xxx GB's/second between your servers without external lines, controllers, switches, and so on, almost at memory speed through standard TCP/IP connections. Think about systems with hundreds of CPU's where one, two, three, .. failures only means slowing down a little and only if you are already running near %100 capacity. Of course workload balancing may actually be a little more tricky than in distributed servers but other reasons which can be learned. Stock exchange transactions are small (actually very small) so they may be better in server farms today but the design is not easy, who wants to lose a $100 million sale / buy order! Also, I wonder how they handle the timings? Remember last panic, everybody selling, servers queuing hours, arguments later whose transaction was 1 microsecond before some other? It took years, FCC and courts to solve. Anyway, hats of for NYSE, I remember when Tandem was an unknown and some stock exchanges and banks took the leap and trusted them. Correctly built Tandem systems are still the only real NonStop systems but need skills you can't easily find today. And HP is not helping on that because, like it or not, Tandem is a niche system today and HP doesn't like diversity.
I knew that. It is actually a funny comment if I would have had any points left. The problem I have are the younger /. users who take these literally. Last week talking a couple of a managers in a huge software company - they really believe those things so I'm a little too touchy just now, it will go over after Xmas, I hope.
You are absolutely right. But think what would happen if any side would fix their ways? They would win and then we wouldn't have ( any needs ) for /. etc any more. As painful all the different views are, they create different paths for future systems and, of course, more work for us. Yes, Microsoft has a lot of very, very good people, fortunately, as you say, the management screws it up enough so we don't all have to go MS way but pick up what good comes out from MS development and forget the rest. I love what MS, IBM, Sun, HP, Fujitsu, Hitachi, even Cisco, Nokia, Oracle, etc creates with their huge research budgets, they are different enough to give some very good ideas. I don't have to use their OS, programs, what ever but just the ideas are enough, you don't have to use their OS, programs, "IP", etc but the ideas which can not be patented or protected by copyright ( at least not in a sane world, sorry to add this! )
A perfect comment! I can understand the top level management because for them IT is just a corporate function, one of many, but save me from middle management who do not understand the mechanics they are supposed to manage. They don't have to and they don't really always have time to be specialists on subjects but they should (must) have a very good understanding how and why some things work the way they do. Now, unfortunately, even I think everyone understands that but lately it has gone worse which means more politics and inside fighting instead of doing a good job and more profits for company.
A very good comment, as the first response! My experience over long time before there was a Microsoft, they are not alike any other company. I'm a software developer who has to see the whole infrastructure, not just a small piece of it and I have the same experience, not that Microsoft is any different of other vendors I have had to deal over years but currently.. They had things going (almost) right with NT and even XP was still on ballpark but lately, give me a break! As you, I have to design / develop secure, non failing, 24x7, etc systems which work with standard protocols, interfaces, frameworks, existing hardware and so on and what I see is that Microsoft wants to redefine those. Not a bad idea in itself but we have huge infrastructures already running by current standards and any disruption to that will not work without big changes and a lot of new work, be it a protocol, hardware, API or even the user experience. Of course, good for us, more work but for users, corporations, etc it will have a cost and problems.
OT and old but just have to answer to this. Cobol, PL/I, Fortran, etc or mainframes had nothing to do with Y2K! In 70's I had several large insurance, government, bank, army, manufacturing companies as my customers and none (zero) had Y2K problem. Why, because they all designed their systems capable calculating +/- 100 years. Y2K was the problem of very bad design, it happened then as well as today. And it is not the developers fault if the system, data, displays, etc are designed wrong. Unfortunately this hasn't changed, I see bad designs today as much as ever and actually more because systems have grown and have more interacting components. Bad especially in networks, SOA implementation, and so on, why do you think support costs haven't gone down but up? I'm great believer on agile, XP, SCRUM, etc, they work very well but but only if they have a whole system view, not in vacuum, too easy to test one component which works well alone or in small test systems but breaks when brought to dynamic infrastructure. The same could be said of threading, multiple cpus, etc. All (almost) my customers were ready for that at end of 70's, beginning of 80's. Systems were designed to run parallel tasks, asynchronous I/O, threaded (tasks) queries, background audit and statistics, shared disk farms, etc from ground up.
Great, now they have a tool to encrypt! Let's hope they thought about key management before implementing it. It's great for vendors that some have no idea of security - more sales. Next we will read all the keys stolen by an employee (usually high in hierarchy, just my experience) and have to start all over again. Or am I too pessimistic / skeptical when it comes to security?
The patent describes an Ericsson PPX/pager/phone system I was using in early, mid 80's perfectly except it didn't use names to display the caller but the telephone numbers.
Once you contacted(phoned) the PPX you got the names of the caller(s) in voice (if programmed in PPX) and a list of messages by caller in any order you selected. You could listen, skip, delete and archive those messages for later use. You could also tell the PPX to call back the caller or reroute the calls to another phone(user) or start a conference call or etc.. But no visual except there were "intelligent" phones which gave you the list of numbers on a small display, number and time of each message, capability to listen any or none, save or delete and archive, call back the caller, etc.
So, the only real difference was the visual maybe because of the technology at that time. Now - there was even earlier the huge (and expensive) IBM PPXs, I just don't remember all its capabilities but they did interesting tricks with messages no matter in which country you were and maybe it did show the names on 3270(heh!)
Really have to wonder what can be patented today and how broken the whole system is! It is so obvious to connect names to numbers / messages / whatever once you have a little memory and a small processor. And caller ID.
A good comment! And the IP part is important, you just can't take any code you see, you can read it and code the solution yourself in most cases but there are some darn patent issues - stupid laws patenting algorithms !
Another good point in comment "every good programmer should take the time to create a really good library" And this should go without saying, build your own library of templates and snippets you carry as long as you do coding, often saves a lot of time. Some companies which use SM/CM ( source/configuration management ) have ready made / canned templates, snippets, etc already bound to editors, IDEs, and so on. Unfortunately very few.
Just don't get too hooked to those, some day you are in environment where the only tools are notepad or vi and a compiler, how to start now? And usually in those systems all the help files, man pages, etc are nonexistent.
Also, be careful, code may be written to specific platform, OS, compiler, etc. I'm tired of fixing for example code written to PPC when compiling for x86 or 32 bit code going to 64. Did you think all systems have bytes in same order? Did you think all compilers and systems align same way? Did you think that all systems let you manipulate the stack? Did you think they are on same POSIX level? Did you think that objects with same names are equal? Well, you were wrong. Especially some Unix developers with fast cut and paste fingers have created millions of lines such code ( just my experience, sorry )
Another ( one of many ) issue, did the original code writer think security? Ouch - all the string functions, etc. Yes, even if the code comes from experienced developers and (currently) well behaving systems does not guarantee that it will work for you.
All that said, old code is a great source to learn especially if you are new and you have someone to explain it.
Rated as funny and, yes, it seems funny today. I'm from time we had secretaries and I miss those times. Scheduling between internal and external (customer) connections is PITA. The secretaries were able to negotiate, no system can do that, it is out of your time. They knew personal things what you never would put to any scheduling system, bring flowers or a bottle of whiskey to next meeting because the big boss has a birthday, whatever. They reminded you of all the papers you will need to take to the meeting, they had your flights ready, they proposed to have another person to go with you or just sending another person because whatever reason, etc. No calendar, scheduling, computer system can never do that and it is out of your time - sometimes a lot! So hire an assistant!
Yes, you are right. My gripe is that too often it is the integration without planning / design. It is not the developers / DBAs fault but how the management sees it and buys all the marketing hype "this product solves all your business problems"! Information management, what any database is supposed to be part of, is really not an easy thing but I still think there should be someone in company responsible of that. Nothing new, same with security, performance, development environment, etc. We still too often (IMHO) make things in vacuum, too specialized for one small part of the system, whatever. This actually can accelerate the development, pieces and parts can be built to common good, think for ex. SOA.
Very insightful. IMHO this is the problem today, learn a little of one product dialect and you are the master of information management, yeah, great! Vellmont is absolutely right, database design is much more and corporate information management in those databases is even more. Even if a good start can be found in books it needs years, most often very specific industry knowledge and every day learning before you can master it. SQL dialects, structures, tables, even normalization are easy but really the future needs, capacity, performance, expandability, predicting changing business needs and technology, etc are totally another ballpark. And I'm not a DBA, just a person who has gone through all the pain designing and managing huge amounts corporate information over years from card sorters through direct access, structured files, relational algebra to modern(?) object databases and still learning. Nothing against the book, haven't read it but just the impression often given and bought by some corporations, the way to trouble which someone else then have to fix ( try to fix. )
I would like to comment this and turnaround. Some countries have laws for billing and salary systems so you better be fast otherwise someone may in worst case lose their business license, you or your customer, or at least it is very costly. About the bug in OS, if it has an effect to your business, you again better be fast. Been there, done that 2am for a system on other side of globe. IMHO the mainframe support is the best, my dealing with IBM and they were always able to deliver a PTF ( program temporary fix ) in hours at any time of day.
Some have already mentioned that it is not possible to answer your question without more knowledge but we all have opinions, this is /. All I can add that it depends, if you rush just for a change order there is something wrong with your management. If you take 48h to fix a problem for a 24x7 something else is a problem. I like that toilet paper answer except - I once had a paper mill as a customer, simple ? application taking care of the warehouse. The problem, 6pm 100 miles away it started crashing but it is just the warehouse application? Except, if you can't manage a warehouse you have to stop the production, if you can't manage the warehouse you can't send the paper out, nobody can track all that without a computer. So the estimated deadline was midnight and after that 3 ships would sail without paper, machinery stopped and restarted, cost XXX millions. Not 48h, not even 12h to fix - I got the system fixed 11.45pm by patching a live/running system in memory ( with help of a person in other country more experienced of that part of the system ) So, yes, I have taken my time to fix something and lazy as I am, sometimes days but (un)fortunately most my customers are/have been 24x7 - you fix it now ! So, case by case and remember to build your system they way they are easy to analyze and easy to fix.
Yes, I totally agree! But try to make any corporate management to understand that, no way (yet?) OS can not protect when application makes stupid things. And for me, if you build a stack, it is an applications, if you build a driver, it is an application, if you build the authorization server, .. you get the picture. Unfortunately security is not (yet?) very high on list, even lower than performance in most cases I have seen. As you say, it is the design! There may be code problems but if the design is good they usually are very easy to test and find or the application just doesn't work. Now, especially lately, I have seen bad or no design at all, the word for developers is use this/that vendor/OS/IDE whatever and don't worry, it will work, you don't have to know/think such things like security/performance/manageability/testability/etc. Sad!
You don't loose the mainframe, it may slow down a little for some part of it failing, but it may come unavailable for external reasons, loosing all electricity in installation, earthquake, flood, even terrorists or one postal worker, whatever. Now your normal backup procedures kick in, did you think you can work without those even if you have a mainframe? It is actually simpler with a mainframe than a server farm, you don't have to reload nnn systems, connect them to network, configure whatever, etc. You simply tell your backup site ( if they already are not already up and running, remote monitoring! ), to load the system and you are done. Designed a couple of those, tested, never used in real emergency but never failed. And if you have important enough business for continuous processing your IT will have one!
Yes, the talk is about less CO2 but how little ./ readers know about mainframes and business systems overall? Fortunately I see some answers which save the day, thank you. And I want to emphasis their point, if you don't know what mainframes do, go and learn. I could tell you from 70's, 3000+ users, 512KB memory, 1MIPS mainframes (the measuring base for later, IBM 158), 8000+ online applications ( big transactions ), 1 second response times, etc but you have to see it and there are no such things any more. Yes, mainframes are totally different beasts of your super, 3GHz+ PC. Nothing wrong in that but the throughput of those systems is way beyond even large server farms. And, as someone mentioned, nothing new in VM, bring your online systems up for testing in VM, bring your whole OS up, bring one up for coding and unit testing, all old. And we had no problems showing microfilms, faxes, etc in those green terminals. Actually most changed to color later on. And if you really needed graphics, Tektronix or some CAD station for very high definition graphics did that. More expensive at that time, of course, what technology wasn't, but available. And the reliability is really something else, not just availability(HA) or NonStop(Tandem) but they just keep running, software bugs excluded there Tandem may still be better but just a little. I almost forgot, mainframe security is something other systems just dream!
Now, places who want a secure environment / systems have been doing this a long time. An insurance company where I did work in 70's and I was part of security, managing mainly systems and operations access security, we had a company once/twice a year making a check. And I can tell you, they found a lot of ways in, loose papers, open terminals, unlocked doors, whatever. Very useful. Haven't done that for a while but you should see the Swiss bank security or the France military security, scary. And these guys who did the work for us, they sometimes were even able to penetrate those, don't know to what level but even a small is bad. So, let's hope they do a good work before someone else does it. And they also did other security checks so don't talk too much business after a couple of beers, charming fellows!
Maybe it's me, I'm sure it is just me, but lately it seems that there is more lost and found mass in universe than files in a system? Maybe it is more difficult subject? I'm waiting when they get the final numbers out, I'm still under 1000 years old.
Right except they don't have to be on same OS. It is enough to be on same platform today, one system or cluster or even in servers. What the user cares is to be able to use all together, 1 to n displays, same inpute devices, cut/paste between apps, same file system/directories access, etc. And that is available today in many ways so OS is the smallest problem, in case of Adobe the graphics shared between systems is a pain but I think Adobe could solve that. It is a problem that has not had a high priority.
That is a good idea. Make your application an appliance, boot/load/run it in OsX, Windows, Linux, x86(32 or 64), PPC, whatever. I know a lot of people who would love that. And I have been running VMWare, other VM's a while in x86(32 and 64) and in MacBook ( my favorite, run Osx, XP and Linux at the same time ) with many appliances, Linux, Solaris under XP(Windows), XP, Linux, Solaris under Linux, Linux, XP, Solaris under OsX without any problems. Now, the graphics could/should use some upgrading for Adope type work but otherwise it just works. There are ways to make the graphics work but the virtual system manufacturers don't seem to have it as a priority today, just wait a while.
Hi, yes and no. 370 runs 360 code but, as too often even today, people coded to bypass the OS. Old devices, drums, paper / magnetic card readers, terminals, channels, etc. Even todays systems have the idea, VM especially, of 80 column cards, punches, readers, etc and if used correcly they work wonders, trust me, 360 architecture is one of the best even today. The problems is that not too many people any more want to learn the basics, i.e. Priciples of Operation ( any 3xx, a good book to read, required reading, IMHO ). Search on which OS version macro libraries Linux ( 370 HAL ) was first compiled on 360/370, you will be amazed. Emulations in 360-xxx mostly mean address space differences ( 24/31/32/64/.. ) and some added machine code / functionality, done by OS/hardware. And of course a long time trapping the floating point was/is(?) one if you didn't have the fp hardware installed.