Feature changed by: Scott Couston (zczc2311) Feature #305849, revision 4 Title: Provide the Ability to Natively Load More Than One Protocol Stack openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Scott Couston (zczc2311) Description: 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. __________________ Discussion: #1: Scott Couston (zczc2311) (2009-09-05 20:19:26) 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. + #2: Scott Couston (zczc2311) (2009-10-27 16:07:26) + 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. -- openSUSE Feature: https://features.opensuse.org/305849

Feature changed by: Scott Couston (zczc2311) Feature #305849, revision 6 Title: Provide the Ability to Natively Load More Than One Protocol Stack openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger) reject date: 2010-11-15 09:43:18 reject reason: Not done in time for openSUSE 11.3. Priority Requester: Important Requested by: Scott Couston (zczc2311) Partner organization: openSUSE.org Description: 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. __________________ Discussion: #1: Scott Couston (zczc2311) (2009-09-05 20:19:26) 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. #2: Scott Couston (zczc2311) (2009-10-27 16:07:26) 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. + #3: Scott Couston (zczc2311) (2011-04-14 07:51:31) + 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 -- openSUSE Feature: https://features.opensuse.org/305849