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
midrange.com
