Thinking yet a bit further, I think one of the originally stated goals was to present the sign on screen in the appropriate language for that specific user. How can the exit program assist in presenting the appropriate panel in the correct language when the user profile/IP address is presented to the exit BEFORE it runs? Where did it get that information?
Presuming that the concept of a named device (generic naming for instance "FR*", "US*, "EE*" for France, USA, and Estonia) is reasonable then just set the dang terminal emulations up, put them in a shared folder, and let the user choose the one that's right for them.
Why fuddle around with it more than that. Complicated = broken more than you want.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of DrFranken
Sent: Tuesday, May 12, 2020 8:35 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Telnet server multiple instances?
On 5/12/2020 5:05 AM, Patrik Schindler wrote:
Hello Jim, Paul & Larry,
thanks for your valuable input!
So, the switch to another SBS is done *after* signon? Maybe I wasn't > clear enough, but I wish to have a different signon-screen (language, > appearance) showed prior to signon. So, the differentiating point is > not the user profile, but the connection itself. But I don't know > which attributes of a connection can be "extracted" and used for > routing even the signon request to a separate SBS.
First, yes.
Here's the thing about signon screens. If you read the section in the manual that describes which subsystem will provide the signon screen it
states: "If there is a matching workstation entry with *SIGNON in multiple subsystems, the subsystem that provides the Sign On screen cannot be predicted." Some may argue the one that started first will do so, some will argue the one with the closest match in the workstation entry, some will argue it's the one with the least workstations currently. All of those arguments are incorrect and both Jim and I have played with this a lot over the years and proven the manual correct!
Now as Kevin mentions in another response your choice then becomes the QIBM_QTG_DEVINIT exit program.
In such an exit program you get, among others, the user profile and the source IP address. Using this information you can react in a way that the user ends up in the subsystem of your choice. It's not quite as straight forward as you might wish unfortunately. To accomplish this you would have subsystems with assigned workstation entries based for example on language. Examples might be workstation entries like "USEN*"
to one subsystem and "MXSP*" to another subsystem. When a user who needs Spanish language is detected you would create a device for them named
MXSP0001 for example (Starts with MSXP) then return that device name to the Exit Program. The user would then be connected to that device and with the described workstation entries that device would be routed to the subsystem with the Spanish sign on screen.
Of course the decision tree is up to you! In fact, you COULD:
Decide that the IP address range doesn't deserve a signon screen at all!
Decide that at a particular TIME you don't want to give them a signon screen.
And you could also combine some of this logic with the software Jim brought up if that works for you.
- Larry "DrFranken" Bolhuis
www.Frankeni.com
www.iDevCloud.com - Personal Development IBM i timeshare service.
www.iInTheCloud.com - Commercial IBM i Cloud Hosting.
On 5/12/2020 5:05 AM, Patrik Schindler wrote:
Hello Jim, Paul & Larry,
thanks for your valuable input!
Am 12.05.2020 um 02:22 schrieb Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>:
Yes, you can achieve your goal with a routing program and multiple subsystems. I don’t believe you can run multiple telnet servers but you really don’t need to. Even at V4R5.
I have samples that both Larry and I ( and another fellow named Paul Weyer) used at Common conferences called Advanced Work Management.
You will need to identify the user somehow, and we usually used the accounting code in the user profile for that purpose.
So, the switch to another SBS is done *after* signon? Maybe I wasn't clear enough, but I wish to have a different signon-screen (language, appearance) showed prior to signon. So, the differentiating point is not the user profile, but the connection itself. But I don't know which attributes of a connection can be "extracted" and used for routing even the signon request to a separate SBS.
If I get time tomorrow I’ll post it in the wiki, or if you have a COMMON membership you might find it in one of the session lists, although it’s been awhile since either of us taught that class.
Thank you!
Contact me privately and I can send you all the code which will compile at V4.
Thanks again. I'll do after clarification of the remaining open
questions. :-)
:wq! PoC
PGP-Key: DDD3 4ABF 6413 38DE - https://www.pocnet.net/poc-key.asc
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
https://amazon.midrange.com
midrange.com
