Question on multiple Python users in one application

[Michael Torrie]

On 10/06/2016 06:03 PM, Loren Wilton wrote:
>> So I take it that currently users access the software running in the
>> virtual mainframe over telnet or some form of serial link and that they
>> interact with it in a text terminal?  This point is fairly important,
>> because if it's true, then you really don't have any in-band way of
>> clients talking to some Python process(es) running on the machine
>> hosting the virtual mainframe.
> 
> Um... Yes and no.
> 
> Consider a Linux web server environment that happens to have Python 
> installed.
> 
> A programmer in the organization that ownns the server can probably log on 
> with an SSH session and type Python and then have an interactive Python 
> session where does simple computations or database accesses, or where he 
> runs existing Python scripts.
> 
> But that isn't how the machine will normally run.

Please let us know how the machine normally runs and how your clients
interact with it.  We're still very much working in the dark here since
we can't even determine how users or clients interact with the mainframe
and the kinds of general tasks they do.  You mention a web interface.
How do you envision your clients invoking Python?

> Normally the web pages might have queries or other items that run bits of 
> Python code, or Python scripts, some of which might access or even update a 
> database. Normally there might be nightly cron jobs, some of which might be 
> Pyton scripts.

Well that last bit is comparatively easier and doesn't require any
threading or multi-user capability in python itself.  The script runs,
talks to the mainframe over some protocol you've apparently established,
retrieves some data and performs some sort of command.

> 
>> then you really don't have any in-band way of
>> clients talking to some Python process(es) running on the machine
>> hosting the virtual mainframe.
> 
> I'm not clear on what you mean by "in band way". If you mean that there is 
> something on the Windows side of the machine that might wake up and decide 
> it wants to talk to Python, then no, that can't happen.

I mean that if you client is talking to the mainframe over some kind of
protocol already, then you can't really add Python to the mix directly
since it does not run on the mainframe.  But like I said, we don't know
how your clients are using the mainframe and its program, so I can't say
what the "band" actually is precisely.

But in other terms of reference, if you have a web server that lets a
client do something with the mainframe, then using the browser would be
considered "in band" since command and control functions through the
same interface.  If you wanted to add some sort of python console, you'd
have to either add something to the protocol to allow this interaction,
or do it via some other out-of-band way, such as ssh-ing and running a
script.


> But mainframes these days are generally not interactive in the sense of a 
> Telent terminal. The programming machines have something like that, but the 
> production machines usualy don't. There may be terminals, but they are 
> probably automatic teller machines, or airline reservation terminals. These 
> don't interact with a shell in the Unix sense, they interact with a series 
> of predefined transaction commands that control program access, or maybe are 
> accessed by a single dedicated program. Even web pages, if well written, can 
> only access fixed assets.

How do the users interact with these predefined transaction commands?
There must be some protocol you've implemented to allow this over a
remote connection.

>> You'll just have to implement Python support for these frames of
>> reference. Python is not going to be running on the virtual hardware;
>> it's running on Windows.  All you need to do is provide a way for the
>> remote end users to talk to the Python server running on the windows
>> machine would define sessions for the users and manage the interaction
>> with the virtual mainframe.  No matter how you cut it, Python is
>> separate from the users and separate from the mainframe since you can't
>> run Python on the mainframe itself.  The only thing that makes sense is
>> to develop some kind of Python-based server architecture that clients
>> can talk to to do things via Python on behalf of the user.
> 
> If I need to write these sort of hooks, I'm new enough to Python to not have 
> much of a clue where to start, and would appreciate all the help I can get.

Well this is an advanced Python topic for sure.  But it's one you'll
have to delve into eventually it sounds like.  Google for information on
embedding Python.

> I've read that Python supports 'threads', and I'd assumed (maybe 
> incorrectly) that these were somewhat separate environments that could be 
> operating concurrently (modulo the GC lock). I assume that data can be 
> shared between the threads, and probably will share automatically if the 
> name of the item (or the reference) matches. But I'd also assumed that I 
> might be able to do something like start a thread and tell it that it is 
> working in "module user_42" or some such, so that by default it's data would 
> not be global.
> 
> Assuming that I'm not completely off-base about using threads, I don't 
> really understand how to create a thread or destroy it. I'm also not 
> completely clear on how much useful data there is that is thread local, and 
> how much in the way of Python objects goes in the gloabl heap.
> 
> Would using threads help me do what I want? Or am I completely off base? Or 
> is there some other approach that I've missed that might be better?

No idea as it's still not clear what you want to accomplish exactly.
You are providing a lot of details, just not concrete ones that show how
things are currently done and how you want to change that by adding
Python to the mix.