Home_greyopenFATE - openSUSE feature tracking > #305849
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Provide the Ability to Natively Load More Than One Protocol Stack

Feature state

Rejected Information


Currently we natively support only an IP protocol stack, however I would hazard a guess that SLES has the ability to load IPX as well even as we have moved away from IPX.
The Other Misgiving is that natively we cannot support more than an IP Protocol Stack and the lack of very good open/proprietary 3270 type Terminal Emulation shipped by default.
I would be much happier if opensuse OR SLED could cope with another Protocol Stack - In Australia there is an enormous market we currently offer no solution to in only providing an IP Protocol Stack.
In my home Country Australia
All Federal Government- Health-Social Security- etc./All Banking Sectors/Most all Military Sectors/All State and Federal Law enforcement/Others (Thats a big Market Place)
need to support a 3270 type Terminal Emulator and directly address SNA or X.25 or STLC comms.
To compete we must at least be equal in the market place!
The other mass market world wide particularly in the US are PC's that all Travel Agents use to make their bookings.
World Wide They would use either Saber or Apollo or Galileo or Amadeus or Abacus - that about covers the whole World now. The issue all user face with M.S is that they most likely have a dedicated comms server as M.S cannot even load the required Protocol Stack.
Depending on which Global System is used they mostly stick to their preferred stack and this could vary from ALC/STLC/X.25/IP/IPX/MATIP/etc.....
Enough said - I think we all understand how we can better appeal to other huge markets if we invest in the functional ability to load more than just IPV4/6.
I think we need to look far and wide at ALL Industry comms and we CAN do what MS cannot - We could easily bundle off a very very good 3270 type emulator and support SNA AND IP directly without the possible need for a comms servers packet stacking and promiscuous translation to IP.
So we have 2 huge untaped Markets we cannot help right now and these are
Australian - .GOV/.MIL and internal Banks and credit unions
Global - The travel Industry is their varying, but constant use of say STLC/MATIP
If we need to pull apart IP coms in the future for IPV6 this would be golden to support more than an IP Protocol only.


icons/user_comment.png S. C. wrote: (9 years ago)

Every Australian Bank and Government agency still use SNA for secure comms. If SLED could carry both an SNA and IP protocol stack I am sure it would take very little convincing to change every PC as above into Linux - To offer no Viris or Malware and offer both SNA/TCP Protocol stacks at a branch level on every 3270 type emulator before it gets convernted back to pure SNA for secure transport would win hands down.

We are speakong about tens of thousands of PC's here.

icons/user_comment.png S. C. wrote: (9 years ago)

The extension of this is offcourse to add the ability to run multiple adapters such as token ring. Without offering both dual protocol stacks and dual adapters AND a 3270 screen emulator Novell is not going to get a sales interview for Suse Linux on an IBM/Z Series.

Novell already offer a SNAGateway product, or they use to so if we provide the ability to manage multiple adapters, multiple protocol stacks and a 3270 type terminal emiulator you could sell
thens of thousands units of SLED and SLES to every Government, Financial sector in Australia.

icons/user_comment.png S. C. wrote: (7 years ago)

I see result is Rejected in 11.3!
The relevance of having the ability to run multiple protocol stacks and with that,various client terminals; all running together over the same UTP cable: limited in geographical importance.
Indeed few market places exist where multiple protocol stacks and multiple client emulates run side by side; as geographically limiting.
Whilst we keep to the notion that the answer to the worlds comms is TCP/IP, IPX and Ethernet this feature request can probably not be justified on expense!
This actual feature request that has already been part of M.S Windows 2000 and continues today, will continue to be the sole solution for any organisation that require multiple protocol stacks and multiple clients.
As such, with a globally small market place, its expense in both Enterprise and open source project will make this request rejected outright.

QA - If there is a closed status after rejection please make this change

Last change: 7 years ago
Score: 2
  • Negative: 0
  • Neutral: 1
  • Positive: 2
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint