Within the NonStop
community change has always occurred at a measured pace, but with NonStop X and
virtualized NonStop will that still be the case and can the NonStop team do it
all by themselves?
It has become a popular practice, fraught with danger and unintended consequences, changing lanes without signaling in the hope of jumping into a lane that is moving a lot faster! In some metros signaling that you are about to change lanes typically encourages the slower driver in that lane to accelerate; closing the door on any opportunity to capitalize on traffic that is moving more quickly. Indicating your intent, such obvious signs of being courteous, is taken to be signs of weakness; a passive driver unsure of their next move. However, the desire to get to a destination more quickly is inherent in every driver on America’s freeways (as it is in other countries I have visited) even if that means taking risks.
When it comes to technology, it has always been a race – an opportunity to outflank the competition with something new. The “unfair advantage” is as keenly sought after today as it has ever been and there is no mistaking the media coverage of a company that announces a breakthrough that propels it not only into the spotlight but onto the radar screens of every business in its market segment, no matter how big they happen to be at the time. Yet, there are unintended consequences more often than not. Signaling a lane change and then lifting off the gas, as I once witnessed on Southern California’s dreaded San Diego Freeway (the I405), resulted in the car behind slamming into the poor driver uncertain of their lane change. This collision then propelled both cars into another lane and as cars began spinning it became clear that a major multicar pileup was in progress. For the technology savvy within IT, aware that making a change and then hesitating, weighing the risks involved even as the first steps towards implementing something new oftentimes can be as detrimental to the business as not making a move at all (as time-sapping recovery steps are initiated)!
One hallmark of the NonStop community is that when it comes time to change, it has done so in a very measured manner. How often have we heard it described as similar to changing a tire while the vehicle is in motion or perhaps even more graphically, engineering a change of plane while the aircraft is at 35,000 feet! NonStop is deployed because of its fault tolerant attributes; it’s ability to run 24 X 7 and this means accommodating changes of systems, the OS and key middleware and the solution as well, without introducing any disruption to the NonStop supported solution. Over the years, this has seen the rise of numerous processes designed to aid the cutover to something new, be that an additional processor, an addition of a system and even an additional site.
When it comes to the network itself, however, there are even greater exposures to unintended consequences, so much so that more often than not it’s more practical to keep a line or a server or even a complete system connected using existing technology than running the risk of changing protocols at the same time as changing the rest of the system environment. Change is happening fast all around the data center, but sometimes it’s more prudent to work with what you have when it comes to the network.
This harks back to the days when IBM drove all networking decisions and where major networking architectures centered on IBM’s architecture de jour! For many enterprises dependent on the fault tolerant attributes of NonStop as they applied to supporting their networks 24 X 7, IBM’s System Network Architecture (SNA) drove the decision making so much so that all vendors seeking a presence inside the network had to support a basic set of protocols and services that came with SNA. First unveiled in 1974, the deployment of physical SNA networks comprising mixes of SDLC, Token Ring, etc. are no longer the mainstay of modern networks and yet, the applications and the devices with which they communicate are oftentimes still tied to 3270 display formats (LU2) as well as to Advanced Program-to-Program Communication (LU6.2) exchanges.
The networks have been updated and more often than not are based on IP, but the applications, that wealth of critical business logic, hasn’t been looked at for years. Mapping these APIs and supporting services on top of modern networking protocols has proved to be the least risky approach to embrace for many enterprises as they face major upgrades of their systems, so much so that with each successful upgrade there has been less and less enthusiasm to dig into the code to see what it’s doing – SNA networks are well and truly deceased; long live SNA applications! This has had ramifications for HPE and the NonStop team and even as it saw the turning signal begin to flash, the team wasn’t prepared to crash into the stalled traffic that was up front!
The move by HPE and the NonStop team to embrace the Intel x86 architecture brought with it a couple of challenges, not the least being what to do with SNA support. NonStop users had for quite some time the option to deploy the NonStop product, SNAX, or to choose between the third party products – ICE from ACI Worldwide and uLinga from Infrasoft. The resources (and money) that would be required to test and validate SNAX on x86 seemed disproportional to the number of NonStop users that required support of SNA applications so HPE, together with Infrasoft’s partner, comforte, began promoting uLinga as the preferred choice and Infrasoft, have been able to meet the needs of those NonStop users migrating to the new L-Series operating system.
As early as 2015 the NonStop team provided numerous updates on the future of SNAX on NonStop X including the L-Series Application Migration Guide (Published: November 2015) that advised the NonStop community in a chapter labelled What is Changing Differences between the H- and J-series and L-series development environments where it called out specifically that “communication protocols that are not CLIM-based are not supported on L-series RVUs. These include native SNAX, legacy IPv6, ATM, and X.25.” With the decision not to support SNAX on NonStop X (or virtualized NonStop) in L-Series releases, NonStop product management has steered the community to uLinga as it has been validated as capable of supporting SNA applications on NonStop X (and virtualized NonStop).
HPE is a vocal advocate for partnerships albeit partners prepared to sell HPE systems, peripherals and software in volume. NonStop differs from this model slightly in that NonStop partners support the HPE NonStop sales effort with products and services that otherwise might be missing from the NonStop product portfolio. Educating the NonStop sales force to the benefits of the uLinga products as a solution for NonStop X (and virtualised NonStop) fits well with the overall strategy of working with boutique specialty shops focused on just one aspect of NonStop. Turns out, if you want SNA protocols such as LU2 and LU6.2 (and many others) to run over IP then either uLinga EE or uLinga DLSw is the product to turn to – cool! Alternatively, if you have some other protocol that you need supported on NonStop X one of the other uLinga products may be suitable.
"Infrasoft and comForte have forged an incredible partnership together over the years, with Infrasoft focusing on development and support and comForte providing the sales and marketing" said Infrasoft Managing Director, Peter Shell. “The unique advantage that comes with uLinga is that the Infrasoft development team is well equipped to accommodate almost any enterprise-specific implementation of SNA applications that you could possibly describe – yes, they have seen it all through the years. “There is likely to be still configurations out there that might surprise us,” added Shell “but they are deployed in support of SNA applications and that’s not going to phase us.” Maybe a surprise for some members of the NonStop community, uLinga now runs on Linux as well as NonStop and this Open Platform version of uLinga is in production already at a major southern hemisphere bank.
Given the availability of uLinga with its support of the L-Series operating system, enterprises that have commitments to NonStop systems no longer need to worry about the network when it comes time to migrate to x86 systems (including virtual machines atop of x86). uLinga supports all the major APIs, including those familiar to many in the NonStop community such as HLS and APC. “Bringing in uLinga with the latest NonStop X system is a relatively easy if indeed a no-brainer option,” added Shell. “The upside of course is that enterprises can focus on the real value from migrating to NonStop X – better price performance along with a move to industry-standard hardware and open software.” There will be many more migrations to NonStop X in 2019 and having uLinga on hand to ease the system migration makes the decision to move equally as “no-brainer” as keeping the network whole.
Migrations undertaken by the NonStop community have always been approached a in a measured fashion, with steps taken to mitigate risk at every level. The HPE NonStop team has done a tremendous job in providing tools and even access to systems that dramatically simplify the process of moving to a new architecture. By promoting the use of uLinga to maintain support for existing network connectivity while remaining very focused on the system holds merit – the NonStop team knows NonStop systems. Working with partners like Infrasoft and comforte simply means that the NonStop Development team is focusing its own resources on what matters most for the NonStop user – avoidance at all costs of any potential crashes, no matter what signals might be given. And for this the NonStop community is being well served – so much will change in 2019 and NonStop X will be firmly in the mix; isn’t it good to know that even as change is happening, there are at least some constants beneficial to everyone in the NonStop community.
It has become a popular practice, fraught with danger and unintended consequences, changing lanes without signaling in the hope of jumping into a lane that is moving a lot faster! In some metros signaling that you are about to change lanes typically encourages the slower driver in that lane to accelerate; closing the door on any opportunity to capitalize on traffic that is moving more quickly. Indicating your intent, such obvious signs of being courteous, is taken to be signs of weakness; a passive driver unsure of their next move. However, the desire to get to a destination more quickly is inherent in every driver on America’s freeways (as it is in other countries I have visited) even if that means taking risks.
When it comes to technology, it has always been a race – an opportunity to outflank the competition with something new. The “unfair advantage” is as keenly sought after today as it has ever been and there is no mistaking the media coverage of a company that announces a breakthrough that propels it not only into the spotlight but onto the radar screens of every business in its market segment, no matter how big they happen to be at the time. Yet, there are unintended consequences more often than not. Signaling a lane change and then lifting off the gas, as I once witnessed on Southern California’s dreaded San Diego Freeway (the I405), resulted in the car behind slamming into the poor driver uncertain of their lane change. This collision then propelled both cars into another lane and as cars began spinning it became clear that a major multicar pileup was in progress. For the technology savvy within IT, aware that making a change and then hesitating, weighing the risks involved even as the first steps towards implementing something new oftentimes can be as detrimental to the business as not making a move at all (as time-sapping recovery steps are initiated)!
One hallmark of the NonStop community is that when it comes time to change, it has done so in a very measured manner. How often have we heard it described as similar to changing a tire while the vehicle is in motion or perhaps even more graphically, engineering a change of plane while the aircraft is at 35,000 feet! NonStop is deployed because of its fault tolerant attributes; it’s ability to run 24 X 7 and this means accommodating changes of systems, the OS and key middleware and the solution as well, without introducing any disruption to the NonStop supported solution. Over the years, this has seen the rise of numerous processes designed to aid the cutover to something new, be that an additional processor, an addition of a system and even an additional site.
When it comes to the network itself, however, there are even greater exposures to unintended consequences, so much so that more often than not it’s more practical to keep a line or a server or even a complete system connected using existing technology than running the risk of changing protocols at the same time as changing the rest of the system environment. Change is happening fast all around the data center, but sometimes it’s more prudent to work with what you have when it comes to the network.
This harks back to the days when IBM drove all networking decisions and where major networking architectures centered on IBM’s architecture de jour! For many enterprises dependent on the fault tolerant attributes of NonStop as they applied to supporting their networks 24 X 7, IBM’s System Network Architecture (SNA) drove the decision making so much so that all vendors seeking a presence inside the network had to support a basic set of protocols and services that came with SNA. First unveiled in 1974, the deployment of physical SNA networks comprising mixes of SDLC, Token Ring, etc. are no longer the mainstay of modern networks and yet, the applications and the devices with which they communicate are oftentimes still tied to 3270 display formats (LU2) as well as to Advanced Program-to-Program Communication (LU6.2) exchanges.
The networks have been updated and more often than not are based on IP, but the applications, that wealth of critical business logic, hasn’t been looked at for years. Mapping these APIs and supporting services on top of modern networking protocols has proved to be the least risky approach to embrace for many enterprises as they face major upgrades of their systems, so much so that with each successful upgrade there has been less and less enthusiasm to dig into the code to see what it’s doing – SNA networks are well and truly deceased; long live SNA applications! This has had ramifications for HPE and the NonStop team and even as it saw the turning signal begin to flash, the team wasn’t prepared to crash into the stalled traffic that was up front!
The move by HPE and the NonStop team to embrace the Intel x86 architecture brought with it a couple of challenges, not the least being what to do with SNA support. NonStop users had for quite some time the option to deploy the NonStop product, SNAX, or to choose between the third party products – ICE from ACI Worldwide and uLinga from Infrasoft. The resources (and money) that would be required to test and validate SNAX on x86 seemed disproportional to the number of NonStop users that required support of SNA applications so HPE, together with Infrasoft’s partner, comforte, began promoting uLinga as the preferred choice and Infrasoft, have been able to meet the needs of those NonStop users migrating to the new L-Series operating system.
As early as 2015 the NonStop team provided numerous updates on the future of SNAX on NonStop X including the L-Series Application Migration Guide (Published: November 2015) that advised the NonStop community in a chapter labelled What is Changing Differences between the H- and J-series and L-series development environments where it called out specifically that “communication protocols that are not CLIM-based are not supported on L-series RVUs. These include native SNAX, legacy IPv6, ATM, and X.25.” With the decision not to support SNAX on NonStop X (or virtualized NonStop) in L-Series releases, NonStop product management has steered the community to uLinga as it has been validated as capable of supporting SNA applications on NonStop X (and virtualized NonStop).
HPE is a vocal advocate for partnerships albeit partners prepared to sell HPE systems, peripherals and software in volume. NonStop differs from this model slightly in that NonStop partners support the HPE NonStop sales effort with products and services that otherwise might be missing from the NonStop product portfolio. Educating the NonStop sales force to the benefits of the uLinga products as a solution for NonStop X (and virtualised NonStop) fits well with the overall strategy of working with boutique specialty shops focused on just one aspect of NonStop. Turns out, if you want SNA protocols such as LU2 and LU6.2 (and many others) to run over IP then either uLinga EE or uLinga DLSw is the product to turn to – cool! Alternatively, if you have some other protocol that you need supported on NonStop X one of the other uLinga products may be suitable.
"Infrasoft and comForte have forged an incredible partnership together over the years, with Infrasoft focusing on development and support and comForte providing the sales and marketing" said Infrasoft Managing Director, Peter Shell. “The unique advantage that comes with uLinga is that the Infrasoft development team is well equipped to accommodate almost any enterprise-specific implementation of SNA applications that you could possibly describe – yes, they have seen it all through the years. “There is likely to be still configurations out there that might surprise us,” added Shell “but they are deployed in support of SNA applications and that’s not going to phase us.” Maybe a surprise for some members of the NonStop community, uLinga now runs on Linux as well as NonStop and this Open Platform version of uLinga is in production already at a major southern hemisphere bank.
Given the availability of uLinga with its support of the L-Series operating system, enterprises that have commitments to NonStop systems no longer need to worry about the network when it comes time to migrate to x86 systems (including virtual machines atop of x86). uLinga supports all the major APIs, including those familiar to many in the NonStop community such as HLS and APC. “Bringing in uLinga with the latest NonStop X system is a relatively easy if indeed a no-brainer option,” added Shell. “The upside of course is that enterprises can focus on the real value from migrating to NonStop X – better price performance along with a move to industry-standard hardware and open software.” There will be many more migrations to NonStop X in 2019 and having uLinga on hand to ease the system migration makes the decision to move equally as “no-brainer” as keeping the network whole.
Migrations undertaken by the NonStop community have always been approached a in a measured fashion, with steps taken to mitigate risk at every level. The HPE NonStop team has done a tremendous job in providing tools and even access to systems that dramatically simplify the process of moving to a new architecture. By promoting the use of uLinga to maintain support for existing network connectivity while remaining very focused on the system holds merit – the NonStop team knows NonStop systems. Working with partners like Infrasoft and comforte simply means that the NonStop Development team is focusing its own resources on what matters most for the NonStop user – avoidance at all costs of any potential crashes, no matter what signals might be given. And for this the NonStop community is being well served – so much will change in 2019 and NonStop X will be firmly in the mix; isn’t it good to know that even as change is happening, there are at least some constants beneficial to everyone in the NonStop community.
Comments