Это 2010-ый год. Я выделил интерeсные, касающиеся МФ места. Честно говоря я так и понял из этого текста зачем они, на Sabre, затеяли этот переход. Понимание приходит если только учитывать ментальность англосаксонскую:
http://www.sabreairlinesolutions.com/pd ... R_2010.pdf
Конечно на OS TPF были весьма спартанские условия, но ведь были уже и VM и Linux подтягивался на MF. В конце концов такая организация как Sabre могла позволить себе и zOS с CICS/DB2, и WebSphere в начале 2000-х уже имелся на МФ.Through the early 1990s, life in technical operations at Sabre Holdingswas relatively straightforward. In a world dominated by mainframe computing, there were few systems with which to worry. And, when a production issue occurred, one only had to search in a handful of places to identify a root cause.
The tools available to manage the mainframe environment were mature and robust, enabling rapid response time for troubleshooting and resolution. In addition, because all of the system resources in a mainframe environment are managed at an extremely granular level, the fix or removal of an offending piece of code could take place within minutes. On top of that, with 100 percent of capacity in a mainframe environment being shared, scale was easy to predict, and planning for additional capacity was a straightforward exercise.
Even with all the benefits of a mainframe environment, the reasons for our move to a service-oriented architecture, or SOA, on open systems were obvious. Certainly cost and the commoditization of the midrange hardware space were critical considerations, but it wasn’t just a matter of compute cost. In reality, for simple, high-volume, critical transactions in steady state, a mainframe environment cost when fully loaded with the cost of operations was not outrageously more expensive than those in a midrange environment (which will continue to be challenged by Moore’s Law). But, as more and more of the travel market moved online, look-to-book ratios skyrocketed consumers demanded much richer content and many more options within seconds of entering their search criteria. Further, the desire for personalized content required the ability to inspect and dynamically alter the information based on the needs of the consumer. For decision-support applications such as revenue management, flight scheduling, crew scheduling and movement control, open systems opened up a new world of options to support the need for flexibility and the importance of usability and the user interface. Combined with the introduction of extensible markup language, or XML, and rich open-systems development tools, building services on commodity hardware provided answers to both consumer demands and rising costs.
Today, we process more than 700 million requests per day, peaking at over 32,000 transactions per second. Every one of these transactions is either entirely or partially processed on open systems. More than 20 percent of our requests enter through our Web services environment, and traffic in this environment has more than doubled within a year and includes nearly 300 available services. Our largest open-systems environment, by number of servers, is our air shopping environment, consisting of hundreds of midrange servers, managing more than 8,000 messages per second and responding with hundreds of real-time flight options in a few seconds.
Our Software as a Service, or SaaS, environment, Sabre® eMergo® Web Access, has been under development for more than nine years and hosts 119 airline customers across 23 open-system applications.
On behalf of our air transportation customers, we leverage the latest and greatest in development tools. During the last several years, we have moved all our teams to an Agile development methodology, enabling us to build our solutions in smaller iterations and incorporate high-quality practices early in the lifecycle before a line of code is ever written. This focus has been for the sole purpose of improving the reliability of our delivery and product quality.
In addition, by building our products as small, discrete services, we are able to greatly increase service reuse and leverage our global development resources more effectively, building more of our components in parallel while reducing development bottlenecks. This approach has also enabled us to use our solutions for broader purposes by providing better separation of user interfaces and business functionality as well as enabling more flexibility with the use of rules engines, standard middleware components and service orchestration.
Having a sizable SOA environment doesn’t come without challenges. All of the system management benefits described in the mainframe environment do not inherently exist in the world of SOA. Proper monitoring, scale, redundancy and resiliency must all be engineered proactively into the environment. Failure to do so before a product is launched will only result in missed expectations. The amount of investment required to incorporate these engineering principles should not be underestimated.
In our effort called “Design for Failure,” an initiative intended to identify potential points of failure so they can be avoided, we have invested millions of dollars building engineering capabilities required to operate a resilient SOA environment. In addition to dedicated technical operations, we have engineering, capacity and performance teams focused almost exclusively on our open-systems environments. We have built test environments to support both individual product testing as well as end-to-end integration and performance testing. We have incorporated standard monitoring tools and developed minimum operating standards, or MOS, that include policy, training and audits to ensure products are built to meet operational expectations before they are ever released to our production environment. Any products that do not demonstrate compliance with MOS specifications will not be released. These best practices were built over time through many years of experience with open-systems and ....
В любом случае из этого текста я не увидел убедительных причин почему надо было рвать когти с МФ. Тем более что в 2010-ом еще оставалась нагрузка на МФ и они явно отставали от своих планов уйти с МФ за 3-4 года:
http://www.computerworld.com/article/25 ... ompaq.html
Еще несколько ссылок и цитаты из них:...Sabre said it will take three to four years to move to a server environment, which will be done in three phases. The first phase, involving 192 CPUs, has already begun, according to Sabre Chief Technology Officer Craig Murphy, and should be complete and running by the beginning of next year.
2002:
http://www.informationweek.com/sabre-bi ... id/1016472?
Sabre Bids Mainframe Adieu with Unix Move
2006:
http://www.itworldcanada.com/article/ma ... blems/5751
Mainframe code presents problems
Этого года job posting:“We’re bound by our software and its lack of portability,” Sabre vice-president Alan Walker said of the 40,000 programs still running on IBM Transaction Processing Facility (TPF), Agilent Modular Power System and other mainframe systems.”
“Applications fall into one of three groups based on scale, said Dale Vecchio, an analyst at Gartner Inc. Applications under 500 MIPS are migrating to distributed systems. “These guys, they want off,” Vecchio said. As organizations begin peeling away smaller applications, they may move to a packaged application; port the application to Unix, Linux or Windows; or, in some cases, rewrite the applications to run in a .Net or Java environment, he said.
In the 1,000-MIPS-and-up arena, the mainframe is still the preferred platform. Applications between 500 and 1,000 MIPS fall into a grey area where the best alternative is less clear. An increasingly common strategy for these applications is to leave the Cobol in place while using a service oriented architecture (SOA) to expose key interfaces that insulate developers from the code.”
“Sabre still has more than 10,000 MIPS of applications on mainframes, and Walker plans to migrate everything off over the next few years. The company’s TPF-based fare-searching application, used by Travelocity.com LP and travel agents, has been rewritten to run as a 64-bit Linux program on four-way Opteron servers.”
https://www.linkedin.com/jobs2/view/12891252
Если кто имеет информацию по Sabre и их переходу с МФ, пожалуйста, запостите здесь. На данный момент не ясно до конца совсем ли они ушли или еще есть что-то на МФ у них.Job description:
Sabre Hotels and Cars comprises both Mainframe and mid-range platforms. These systems process shopping and booking requests Sabre connected agencies. The hotel marketplace is growing and Sabre is prepared to grow with the industry to provide the technical solutions our customers need to be successful. In the Sabre Hotels and Cars teams you will work with team members on the Mainframe system as well as getting exposure to the mid-range systems. The Hotel shopping transactions are processed on both mainframe and mid-range servers. Working on this system will give you exposure to interfacing with systems off the mainframe, and insights to systems beyond the mainframe.”
