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.
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.
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.
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.
I don't think my main concern here is being able to call the CPython
interpreter routines, but instead it is to be able to provide separate
sandboxes for the various programs ("stacks", in B6500 terminology) that
might have their own Python sessions or programs.
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.
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?
Loren
--
https://mail.python.org/mailman/listinfo/python-list
