If they were bere in Cobb County, Georgia (USA), they'd probably be out setting up speed traps on hidden curves just below a hill. There are tons of those around here.:-)
It's my understanding that CICS transaction processing on an IBM mainframe is roughly analogous to TIP/HVTIP transaction processing on a Unisys mainframe. The whole idea of each transaction (assuming a conversation is not being used) is to get in quickly, get out quickly, and leave no residuals when done. Typical actions are:
* Display a fill-in entry mask (screen) for subsequent data entry and exit.
* Accept a filled-in entry mask containing data, validate and store it, and exit.
* Display a filled-in display mask containing the data I just saved and exit.
Kinda like the web on a green screen, but with fast (often 10 millisecond) response times.:-)
The nice thing about intelligent terminals like 3270 and UTS terminals is that the entering/editing of the data on the screen is handled by the terminal, not the mainframe, and requires no network activity. Sophisticated HVTIP apps using DPS or other methods of generating UTS FCCs on the screen can enforce things like numeric/alpha and field justification automatically as part of that process, and the terminal can be configured to only send those parts of the screen that have changed since the last screen transmision (again saving LAN bandwidth).
I wish the UNIX world had a better analog. Most of the UNIX people I know seem to want to through relational databases at everything, but when one wants transaction latencies under.025 seconds or something it's a lot harder to do that and still be able to perform multiple I/O's along the way...
Record-setting profits are easy when the profit margin is 80%+, and selling quickly is easy when each new PC sold has a copy of your product bundled with it.
That removes things like production costs and consumer choice from the equation.:-)
We already fought them in court, and won. It's hard to gain much ground, however, when some elements of the government seems to be in bed with the company which is violating anti-trust laws...
US$100k is a nice wage but not spectacular in New York or the Silican Valley due to the high cost of living in those areas. A similar position making US$70k someplace like Atlanta might result in more disposable income, however.
FWIW, I've worked in four shops where the slow-but-sure approach seemed to be the norm: Unisys (their Airline Development and Support Center), Northwest Airlines, a small window-making company called Viracon, and here at SITA (airline communications/solutions company).
I'm personally glad that such exceptions exist. The practices you refer to above might help to explain the poor level of software quality we often see on the desktop these days.:-(
What kind of resources does/did it take to keep such a system running?
The team to bring up the application (obtained from another airline) and modify it to fit NWA's requirements at the start in 1988-1990 was around 35 people on the programming side and another dozen or two business analysts and subjet experts in the SOC. Those numbers were trimmed down when the Unisys programmers' contract expired after two years, and again when a wave of layoffs hit in late 1992.
Between 1993 and late 2001 we had 12-13 people supporting and modifying the software (roughly 2.5 million lines of Fortran code (~2000 programs, ~1500 subroutines used by the various programs, ~1000 individual transaction codes).
That number is somewhat less now. Eight?
Did the airline industry logistics change much over time, or was/is it really a set of static business rules?
The "application" I'm talking about was actually a series of individual subapplications running in a common environment, and it did a number of things, including weight and balance and "gross weights" (optimal weight/flaps/thrust) calculations, flight plan generation (optimal flight path, climbs, engine burns, etc.), real-time flight info and weather delivery, ACARS (radio-to-ground) message processing, etc. It was heavily used by ground ops (the folks who handled the cargo/baggage loading), flight scheduling, flight dispatch, pilots, and folks at the gate who needed Flight info, Meteorology, Performance Engineering, etc.
Some areas changed quite a bit as the airline grew and added the ability to host other airlines (like Mesaba), needed more and/or different types of information stored and disseminated, etc., and some areas were completely rewritten when NWA obtained the code (some initially, other bits later on as we had time).
Some things were easily handled by the applications like the additional of new aircraft/engine combinations for performance purposes, the addition of new ULD (cargo container) types for cargo, etc.
Some areas changed as the result of outside mandates or changes -- the National Weather Service changed its basic weather format around the end of 1999, for example, requiring that we change the way we handled the basic data handling for all of the weather messages (METAR, TAF, NOTEMs, TWIP/Microburst alerts, etc.) that we processed, but most changes were driven by the pilots, flight dispatch, or ground ops.
Also - please take note your a mainframe man - I'm on internet time where I often see 4-6 programming languages used in even a simple application. It gets messy and fast, after a few years of internet-speed-pace, we really need to redesign it clean from the beginning.
The problems you cite above seem to be environment issues (a lack of discipline when choosing tools, and perhaps also a lack of high-quality project management) and are really not an inherent quality of "software development" per se, even when doing the development of complex systems.
Continuity is *IMPORTANT* if one expects to obtain a consistent result. Tell your management this -- it sounds like they need to know. Using "the latest tool" is not always the best way to be productive.
I also see this a lot in enterprise computing, where business rules and needs change fast.
Sounds like some of these folks need to work in a serious enterprise shop where thousands of people can be adversely impacted in a few minutes (or when serious fines or losses occur) when something goes wrong.
Modular programming assumes a certain kind of design framework to begin with - even some of those assumptions change over time from what I see.
The whole point of modular system design is that you have a series of black boxes connected using a series of well-defined and well-documented interfaces. This is something Microsoft should consider using.:-)
In such a system, any single box can be taken out and redesigned/reimplemented without having an impact on the rest of the system as long as it continues to correctly processes the defined inputs and outputs in the defined manner.
I've worked on production airline applications for most of the the past 18 years, mainly mainframe-based real-time transaction systems running on Unisys 1100- and 2200-series hardware, and some of those systems have been multiple decades old. The one I'm working now now has been running in production for only around ten years or so, but the flight ops I worked on at NWA had been running in production for over 30 years (portions of it -- other portions of the system had to change gradually over time as the airline's internal operational procedures changed).
While some degradation occured over time as an application changed, mainly the result of organic changes and the cruft that results from such patching (especially patching doen by folks who only partially understood the code), that cruft was eliminated locally in most cases by rewriting specific areas of the application.
This can do quite a bit (at least in my experience) to make the application more cohesive and stable in the long term. The UNIMATIC system ran at UAL for 40 years, and it's been running at NWA since we kickstarted it in 1988, so it has an almost 20-year history there now. And it isn't going anywhere soon.
There's no need to redo the whole thing if the software was written in a modular manner in the first place.
Even in older procedural code (the apps I work with are mostly Fortran 66 or F77), the tendency I've seen is to create a set of common library functions and to use sets of said functions to perform more complex tasks, not to write everything as monolithic mainlines. That makes a huge difference.
Until we know precisely what we can and cannot do with digital media (insofar as actions like media tranfer and other activities which are considered "fair use" for analog media), it's hard to know precisely what "attempted" copyright infringement really means.
Assuming the software is organized in a modular manner, a "patch" might often be a new module rewritten to include the fix. Not all patches are organic in nature.
Microsoft's behavior wasn't any better in the early 90's regarding OS/2 and Windows 3.1, either (WIN32S.DLL, anyone?), or in the mid-90's regarding OS/2 and Windows 95 (when MS strongarmed IBM into dropping OS/2 from its own machines!).
Things like ROTFL, IMHO, GD&R, etc., were all pretty common in the BBS days of the mid-to-late 1980's and early 1990's (Fido, RIME, and friends). FWIW. HTH. LOL.:-)
Why do you assume that Linux is the only alternative OS which is relatively hassle-free? OS/2, FreeBSD, Solaris, and MacOS (X or otherwise) are all good examples of OSes which require far less maintenance than the currently available Windows variants.
You can use Technology to create solutions, but technology by itself without intelligent application is basically a waste of money. It won't magically solve problems -- it's just a toolset like any other.
What if the same people who do for-profit development are also maintaining internal systems? The two groups are sometimes heavily-crosslinked in smaller companies.
Out of curiosity: What do you consider for-profit software development if it isn't Information Technology?
At home I back things up to my Buffalo LinkStation fileserver, but I also make secondary backups to other boxes and to the same box on which I work (different disk).
At work I tend to back the UNIX stuff I'm working on to my PC, my mainframe files to my PC, and my important PC stuff to either the UNIX box or to CD-R. The UNIX stuff is also in CVS.
I've invested a year or more in some of this software, and I don't want to lose it even if the entire data center fails.
You're right. They are not in the want ads. They are not on the web sites. But there are plenty available, and we have mega trouble filling positions.
If you're having problems finding people and you aren't publicizing those positions where Joe Experienced-But-Unemployed programmer can find them, could we have a little cause/effect situation going here?
Why make it hard for folks to learn about your openings? Make those openings known!
Then why is there a shortage of people willing to do it?
If American employers are so willing to cross international boundaries to obtain technical talent, why aren't they also willing to cross state lines to obtain the same level of talent (keeping those jobs inside the US)? After all, isn't telecommuting == telecommuting and relocating == relocating?
I suspect most shortages are due to one of the following:
(1) An employer who is looking for an unlikely/unreasonable mix of skills, experience, and salary requirements.
(2) An employer who is interested in outsourcing and simply looking for excuses.
(3) An employer who is located in an area where an actual local skill shortage exists.
Which one is more likely depends on many factors. I've seen prime examples of all three over the past 18 years.
A certain percentage of humanity will always be stupid, distracted, or otherwise impaired when dealing with their own (or their employer's/clients') system's security, and that ensures that at least some systems will always be insecure... at least if secure configurations are dependent on actions taken by those people.
I stopped buying music in local stores for two reasons:
(1) Those local music stored stopped carrying what I wanted.
(2) The internet became a more convenient place for me to shop for almost everything... including music.
The RIAA's actions have been a factor as well, since I don't purchase as much new music now as I used to, but I'm also not into pirating or copying music for free. It's just that I've moved on to other legitimate sources for commercially-produced physical music media.
Slashdot Mirror
If they were bere in Cobb County, Georgia (USA), they'd probably be out setting up speed traps on hidden curves just below a hill. There are tons of those around here. :-)
Sure ... but without the best features, and with a lot of additional bloat thrown in for good measure. :-)
It's my understanding that CICS transaction processing on an IBM mainframe is roughly analogous to TIP/HVTIP transaction processing on a Unisys mainframe. The whole idea of each transaction (assuming a conversation is not being used) is to get in quickly, get out quickly, and leave no residuals when done. Typical actions are:
:-)
.025 seconds or something it's a lot harder to do that and still be able to perform multiple I/O's along the way...
* Display a fill-in entry mask (screen) for subsequent data entry and exit.
* Accept a filled-in entry mask containing data, validate and store it, and exit.
* Display a filled-in display mask containing the data I just saved and exit.
Kinda like the web on a green screen, but with fast (often 10 millisecond) response times.
The nice thing about intelligent terminals like 3270 and UTS terminals is that the entering/editing of the data on the screen is handled by the terminal, not the mainframe, and requires no network activity. Sophisticated HVTIP apps using DPS or other methods of generating UTS FCCs on the screen can enforce things like numeric/alpha and field justification automatically as part of that process, and the terminal can be configured to only send those parts of the screen that have changed since the last screen transmision (again saving LAN bandwidth).
I wish the UNIX world had a better analog. Most of the UNIX people I know seem to want to through relational databases at everything, but when one wants transaction latencies under
Record-setting profits are easy when the profit margin is 80%+, and selling quickly is easy when each new PC sold has a copy of your product bundled with it.
:-)
That removes things like production costs and consumer choice from the equation.
We already fought them in court, and won. It's hard to gain much ground, however, when some elements of the government seems to be in bed with the company which is violating anti-trust laws...
US$100k is a nice wage but not spectacular in New York or the Silican Valley due to the high cost of living in those areas. A similar position making US$70k someplace like Atlanta might result in more disposable income, however.
FWIW, I've worked in four shops where the slow-but-sure approach seemed to be the norm: Unisys (their Airline Development and Support Center), Northwest Airlines, a small window-making company called Viracon, and here at SITA (airline communications/solutions company).
:-(
I'm personally glad that such exceptions exist. The practices you refer to above might help to explain the poor level of software quality we often see on the desktop these days.
Heh. :-)
The team to bring up the application (obtained from another airline) and modify it to fit NWA's requirements at the start in 1988-1990 was around 35 people on the programming side and another dozen or two business analysts and subjet experts in the SOC. Those numbers were trimmed down when the Unisys programmers' contract expired after two years, and again when a wave of layoffs hit in late 1992.
Between 1993 and late 2001 we had 12-13 people supporting and modifying the software (roughly 2.5 million lines of Fortran code (~2000 programs, ~1500 subroutines used by the various programs, ~1000 individual transaction codes). That number is somewhat less now. Eight?
The "application" I'm talking about was actually a series of individual subapplications running in a common environment, and it did a number of things, including weight and balance and "gross weights" (optimal weight/flaps/thrust) calculations, flight plan generation (optimal flight path, climbs, engine burns, etc.), real-time flight info and weather delivery, ACARS (radio-to-ground) message processing, etc. It was heavily used by ground ops (the folks who handled the cargo/baggage loading), flight scheduling, flight dispatch, pilots, and folks at the gate who needed Flight info, Meteorology, Performance Engineering, etc.
Some areas changed quite a bit as the airline grew and added the ability to host other airlines (like Mesaba), needed more and/or different types of information stored and disseminated, etc., and some areas were completely rewritten when NWA obtained the code (some initially, other bits later on as we had time).
Some things were easily handled by the applications like the additional of new aircraft/engine combinations for performance purposes, the addition of new ULD (cargo container) types for cargo, etc.
Some areas changed as the result of outside mandates or changes -- the National Weather Service changed its basic weather format around the end of 1999, for example, requiring that we change the way we handled the basic data handling for all of the weather messages (METAR, TAF, NOTEMs, TWIP/Microburst alerts, etc.) that we processed, but most changes were driven by the pilots, flight dispatch, or ground ops.
The problems you cite above seem to be environment issues (a lack of discipline when choosing tools, and perhaps also a lack of high-quality project management) and are really not an inherent quality of "software development" per se, even when doing the development of complex systems.
Continuity is *IMPORTANT* if one expects to obtain a consistent result. Tell your management this -- it sounds like they need to know. Using "the latest tool" is not always the best way to be productive.
Sounds like some of these folks need to work in a serious enterprise shop where thousands of people can be adversely impacted in a few minutes (or when serious fines or losses occur) when something goes wrong.
Part of a good
Er... Rewriting the module *is* starting over.
:-)
Are we miscommunicating?
The whole point of modular system design is that you have a series of black boxes connected using a series of well-defined and well-documented interfaces. This is something Microsoft should consider using.
In such a system, any single box can be taken out and redesigned/reimplemented without having an impact on the rest of the system as long as it continues to correctly processes the defined inputs and outputs in the defined manner.
I've worked on production airline applications for most of the the past 18 years, mainly mainframe-based real-time transaction systems running on Unisys 1100- and 2200-series hardware, and some of those systems have been multiple decades old. The one I'm working now now has been running in production for only around ten years or so, but the flight ops I worked on at NWA had been running in production for over 30 years (portions of it -- other portions of the system had to change gradually over time as the airline's internal operational procedures changed).
While some degradation occured over time as an application changed, mainly the result of organic changes and the cruft that results from such patching (especially patching doen by folks who only partially understood the code), that cruft was eliminated locally in most cases by rewriting specific areas of the application.
This can do quite a bit (at least in my experience) to make the application more cohesive and stable in the long term. The UNIMATIC system ran at UAL for 40 years, and it's been running at NWA since we kickstarted it in 1988, so it has an almost 20-year history there now. And it isn't going anywhere soon.
There's no need to redo the whole thing if the software was written in a modular manner in the first place.
Even in older procedural code (the apps I work with are mostly Fortran 66 or F77), the tendency I've seen is to create a set of common library functions and to use sets of said functions to perform more complex tasks, not to write everything as monolithic mainlines. That makes a huge difference.
Until we know precisely what we can and cannot do with digital media (insofar as actions like media tranfer and other activities which are considered "fair use" for analog media), it's hard to know precisely what "attempted" copyright infringement really means.
Assuming the software is organized in a modular manner, a "patch" might often be a new module rewritten to include the fix. Not all patches are organic in nature.
Microsoft's behavior wasn't any better in the early 90's regarding OS/2 and Windows 3.1, either (WIN32S.DLL, anyone?), or in the mid-90's regarding OS/2 and Windows 95 (when MS strongarmed IBM into dropping OS/2 from its own machines!).
Things like ROTFL, IMHO, GD&R, etc., were all pretty common in the BBS days of the mid-to-late 1980's and early 1990's (Fido, RIME, and friends). FWIW. HTH. LOL. :-)
Sure. Strict HTML 4.01 Transitional here, no CSS, and alternative access testing for Lynx users and those who can't use frames directly.
Why do you assume that Linux is the only alternative OS which is relatively hassle-free? OS/2, FreeBSD, Solaris, and MacOS (X or otherwise) are all good examples of OSes which require far less maintenance than the currently available Windows variants.
Why take one when 1000+ will do? :-)
WebEx wasn't based on Mosaic. I loved IBM's Web Map mode, though. It was a very nice way to show a user's browsing history, especially for the time.
You can use Technology to create solutions, but technology by itself without intelligent application is basically a waste of money. It won't magically solve problems -- it's just a toolset like any other.
What if the same people who do for-profit development are also maintaining internal systems? The two groups are sometimes heavily-crosslinked in smaller companies.
Out of curiosity: What do you consider for-profit software development if it isn't Information Technology?
At home I back things up to my Buffalo LinkStation fileserver, but I also make secondary backups to other boxes and to the same box on which I work (different disk).
At work I tend to back the UNIX stuff I'm working on to my PC, my mainframe files to my PC, and my important PC stuff to either the UNIX box or to CD-R. The UNIX stuff is also in CVS.
I've invested a year or more in some of this software, and I don't want to lose it even if the entire data center fails.
If you're having problems finding people and you aren't publicizing those positions where Joe Experienced-But-Unemployed programmer can find them, could we have a little cause/effect situation going here?
Why make it hard for folks to learn about your openings? Make those openings known!
If American employers are so willing to cross international boundaries to obtain technical talent, why aren't they also willing to cross state lines to obtain the same level of talent (keeping those jobs inside the US)? After all, isn't telecommuting == telecommuting and relocating == relocating?
I suspect most shortages are due to one of the following:
(1) An employer who is looking for an unlikely/unreasonable mix of skills, experience, and salary requirements.
(2) An employer who is interested in outsourcing and simply looking for excuses.
(3) An employer who is located in an area where an actual local skill shortage exists.
Which one is more likely depends on many factors. I've seen prime examples of all three over the past 18 years.
A certain percentage of humanity will always be stupid, distracted, or otherwise impaired when dealing with their own (or their employer's/clients') system's security, and that ensures that at least some systems will always be insecure ... at least if secure configurations are dependent on actions taken by those people.
The folks I work with, my friends, etc., are all standard keyboard users as far as I know.
I stopped buying music in local stores for two reasons:
... including music.
(1) Those local music stored stopped carrying what I wanted.
(2) The internet became a more convenient place for me to shop for almost everything
The RIAA's actions have been a factor as well, since I don't purchase as much new music now as I used to, but I'm also not into pirating or copying music for free. It's just that I've moved on to other legitimate sources for commercially-produced physical music media.
Slashdot
Groklaw
Linux Today
OSNews
Yahoo News
Google News