What I liked best about m/f is they were never down while I worked. The o/s is in a separate partition from the users and nothing can stop that train. Furthermore, the packed decimal arithmetic is best for business and financial apps.
I remember much of the "Ditch the mainframe/COBOL/CICS/VSAM" mindset was supported by the need for faster and simpler IT solutions. These never materialized. It was marketing brilliance of Microsoft and other major vendors that got us to the point where the security guards have $2500 desktop appliances that have color displays and Word. An engineer seeking to write a Newton-Raphson method won't find anything that came included with a similar workstation because there is no money to be made on licenses and training. The little BASIC package that used to be there made these guys a little too independent for the vendors and the top management they lobbied. Another useful freebee that disappeared was SORT. That was also a little too powerful and too "mainframish".
$2 per hour is pitiful. $25 would be more like it, but people are often too cheap and self-centered. Even geeks. It is rather amazing to look at that document and compare it to the Word(tm) docs we take for granted today.
For 40 years IBM made computers that were pretty robust. The o/s memory and files were in a privileged part of the machine and out of the reach of ANY user. Why can't we do this with pc's?
When I worked at Equifax I was supposed to fix wire transfer links without passwords or id's. If I can't be trusted as an employee then who can they trust.
Re:It's funny that you should say that.
on
Pro C#
·
· Score: 1
The King has no Clothes! Something terrible happened to programming. I can never re-use anything because it always becomes obsolete first.
Yeah, much of this was a Telecom. No wonder they tanked! Another painful lesson from the cubicle: The better and more diligent you are, the more likely that you will kept right there. To advance, you have to cross departmental boundaries, be free of any unrelenting technical responsibility and, be a good bullshitter. Of couse being kept there now is a rare "reward" compared to those who got downsized. Just two things they could have done to save a lot of money and get more accomplished: 1) Draw straws and eliminate one person at the top. What're they making now? You do the math. 2) Keep just those who make the phones ring and send the bills and empower them to do what they see fit.
I'm 60. 30 years ago it was the coolest thing to be doing. I had a sense of growth, future, learning and making an important contributions. I bought terminal with my own money to work from home! What killed it? Greedy, arrogant bosses who just politick their way up. Insecure techies who hide code, secrets and, possibly evidence of their own lack of expertise. Distrustful managers who want you to fix broken fund transfer links but without any ID's or passwords. Getting reamed for wanting to really improve matters by cleaning up the code I have to repair at 3 am. Big companies actually wanted us to keep track of and maintain LINE NUMBERS in the code which contributed nothing.
It is exposing the user/customer to increased risk. Yes, there is a monetary cost. I had an ASUS A7S333 that had no end of problems, especially with sound. I had to disable it and work deaf/dumb. Still, I got BSOD's. It was supposed to be a very high end machine but I finally replaced it with a very generic machine that did not crash and served me better (and faster w/o the reboots).
Hams are just more aware of the issues. I am one (KA4UPC). BPL is a crappy technology with its own capacity limitations as well as deleterious effects on other communications. Fiber is much more economical for a right-of-way backbone and wifi can handle the "last mile". I think the economics will take care of the BPL problem. Interference is a serious problem to many radio services, not just "ham". "Notching" is a joke. How would you like to have to watch the game with less interference than without the notching, but interference just the same.
There is an old saying about "garbage in garbage out" (GIGO) that still applies. m/f are not very fault tolerant in this respect but a return code of zero speaks volumes for data integrity.
I have worked with all systems but started on m/f. The two most pervasive differences to me are data structures using fixed-length fields (m/f) vs those using delimiters (non m/f) and decimal arithmetic (m/f packed binary-coded-decimal) vs non-m/f alternatives (integer,float,double). I tend to prefer the fixed-length fields for readability and predictability, even though it can be "wasteful" of once-precious resources. I miss the decimal math for business-oriented apps but use integer cents displayed as 2 decimal dollar floats. Passing data between these two worlds always has to deal with these differences. Occasionally the computational differences are an issue that can be mitigated, but not eliminated.
This is all very true. It is frustrating to me that today, many things don't work, or only work sometimes, or only work on some machines and that it is considered "normal" or "acceptable". Especially irritating are functions involving plain text. I can understand a few kinks if I am trying to watch a movie on my computer. But if I just want to pass a string of text and get a simple, but crucial result, I am often disapointed.
I started on m/f and now work with all systems. I enjoy the work enough to do it for free sometimes. The m/f is fussy about what you tell it to do but the worst that can happen is my "job" would fail. I made my own share of mistakes but never, ever, did I see an individual user crash a m/f. I often wonder about "buffer overruns" and such that create so many terrible problems in the non m/f realm today. Did the user not set the length parameter to agree with the intended physical transmission? I would rather have the o/s catch these oversights before doing something I didn't really want. Also, the error messages, though seemingly "random nonsense", do contain every bit of information needed to correct the problem, unlike today's "drop dead" messages that tell you little more than something didn't work.
Don't pay anything for them. Life is a much better movie anyway. I have been trying to think of something cool to do with a bunch of well-preserved AOL disks.
There is no need to feel victimized by a corp. Remember all the dumb things they made you do?
Offer what they did to their customer base and compete. You can do it better and cheaper!
Slashdot Mirror
What I liked best about m/f is they were never down while I worked. The o/s is in a separate partition from the users and nothing can stop that train. Furthermore, the packed decimal arithmetic is best for business and financial apps.
I remember much of the "Ditch the mainframe/COBOL/CICS/VSAM" mindset was supported by the need for faster and simpler IT solutions. These never materialized. It was marketing brilliance of Microsoft and other major vendors that got us to the point where the security guards have $2500 desktop appliances that have color displays and Word. An engineer seeking to write a Newton-Raphson method won't find anything that came included with a similar workstation because there is no money to be made on licenses and training. The little BASIC package that used to be there made these guys a little too independent for the vendors and the top management they lobbied. Another useful freebee that disappeared was SORT. That was also a little too powerful and too "mainframish".
$2 per hour is pitiful. $25 would be more like it, but people are often too cheap and self-centered. Even geeks. It is rather amazing to look at that document and compare it to the Word(tm) docs we take for granted today.
Want nothing and have everything. The way to be independently wealthy is to never pay interest, just collect it.
For 40 years IBM made computers that were pretty robust. The o/s memory and files were in a privileged part of the machine and out of the reach of ANY user. Why can't we do this with pc's?
When I worked at Equifax I was supposed to fix wire transfer links without passwords or id's. If I can't be trusted as an employee then who can they trust.
The King has no Clothes! Something terrible happened to programming. I can never re-use anything because it always becomes obsolete first.
Yeah, much of this was a Telecom. No wonder they tanked! Another painful lesson from the cubicle: The better and more diligent you are, the more likely that you will kept right there. To advance, you have to cross departmental boundaries, be free of any unrelenting technical responsibility and, be a good bullshitter. Of couse being kept there now is a rare "reward" compared to those who got downsized. Just two things they could have done to save a lot of money and get more accomplished: 1) Draw straws and eliminate one person at the top. What're they making now? You do the math. 2) Keep just those who make the phones ring and send the bills and empower them to do what they see fit.
I'm 60. 30 years ago it was the coolest thing to be doing. I had a sense of growth, future, learning and making an important contributions. I bought terminal with my own money to work from home! What killed it? Greedy, arrogant bosses who just politick their way up. Insecure techies who hide code, secrets and, possibly evidence of their own lack of expertise. Distrustful managers who want you to fix broken fund transfer links but without any ID's or passwords. Getting reamed for wanting to really improve matters by cleaning up the code I have to repair at 3 am. Big companies actually wanted us to keep track of and maintain LINE NUMBERS in the code which contributed nothing.
It is exposing the user/customer to increased risk. Yes, there is a monetary cost. I had an ASUS A7S333 that had no end of problems, especially with sound. I had to disable it and work deaf/dumb. Still, I got BSOD's. It was supposed to be a very high end machine but I finally replaced it with a very generic machine that did not crash and served me better (and faster w/o the reboots).
Hams are just more aware of the issues. I am one (KA4UPC). BPL is a crappy technology with its own capacity limitations as well as deleterious effects on other communications. Fiber is much more economical for a right-of-way backbone and wifi can handle the "last mile". I think the economics will take care of the BPL problem. Interference is a serious problem to many radio services, not just "ham". "Notching" is a joke. How would you like to have to watch the game with less interference than without the notching, but interference just the same.
There is an old saying about "garbage in garbage out" (GIGO) that still applies. m/f are not very fault tolerant in this respect but a return code of zero speaks volumes for data integrity.
I have worked with all systems but started on m/f. The two most pervasive differences to me are data structures using fixed-length fields (m/f) vs those using delimiters (non m/f) and decimal arithmetic (m/f packed binary-coded-decimal) vs non-m/f alternatives (integer,float,double). I tend to prefer the fixed-length fields for readability and predictability, even though it can be "wasteful" of once-precious resources. I miss the decimal math for business-oriented apps but use integer cents displayed as 2 decimal dollar floats. Passing data between these two worlds always has to deal with these differences. Occasionally the computational differences are an issue that can be mitigated, but not eliminated.
This is all very true. It is frustrating to me that today, many things don't work, or only work sometimes, or only work on some machines and that it is considered "normal" or "acceptable". Especially irritating are functions involving plain text. I can understand a few kinks if I am trying to watch a movie on my computer. But if I just want to pass a string of text and get a simple, but crucial result, I am often disapointed.
I started on m/f and now work with all systems. I enjoy the work enough to do it for free sometimes. The m/f is fussy about what you tell it to do but the worst that can happen is my "job" would fail. I made my own share of mistakes but never, ever, did I see an individual user crash a m/f. I often wonder about "buffer overruns" and such that create so many terrible problems in the non m/f realm today. Did the user not set the length parameter to agree with the intended physical transmission? I would rather have the o/s catch these oversights before doing something I didn't really want. Also, the error messages, though seemingly "random nonsense", do contain every bit of information needed to correct the problem, unlike today's "drop dead" messages that tell you little more than something didn't work.
Don't pay anything for them. Life is a much better movie anyway. I have been trying to think of something cool to do with a bunch of well-preserved AOL disks.
There is no need to feel victimized by a corp. Remember all the dumb things they made you do? Offer what they did to their customer base and compete. You can do it better and cheaper!