On 7/31/2012 10:56 AM, Paul Gilmartin wrote:
What about TSO?
On Jul 31, 2012, at 10:17, Steve Comstock wrote:
We're both familiar with UNIX, which classically runs each process in
a separate address space. How much simpler or more effective
could it be? Likewise z/VM.
Yes, well, each batch job runs in a separate address space, too.
Isn't that the same approach?
...
But for basic applications (batch and TSO, most CICS and IMS), the
application programmer has his/her storage protected from meddling by
other applications automatically by address space isolation.
Not really. You're ignoring the convolutions TSO performs to
execute an authorized program such as IEBCOPY (well, prior
to 1.13). Why can't TSO just launch IEBCOPY in a separate
address space where it would be perfectly safe?
Hmmm. Well, it sounds like you're talking about an
exec running a series of programs. In this case,
things are serial anyway, so perfectly safe. Even
if you are talking about running a program that
then invokes IEBCOPY, what is the need for a separate
address space?
Why are
programmers compelled to invent "magic" SVCs and back doors?
Are they? I don't think so. Again, referencing batch and TSO
environments (including ISPF).
Yes, there are people inventing magic SVCs and back doors, but
these are generally for authorized programs, not written by
your typical application programmer.
Remember, my focus is always on the application developer,
not the systems support functions.
Application coders don't code (nor need to code) these
facilities and should not be using them. Using standard
provided interfaces that vast majority of application
code gets its work done in a secure-from-meddling way
just fine.
The application coder need not even be concerned (although
I'll admit there should be some examination for possible
holes at design and walk-through time, just to be totally
safe; at least you can prevent / avoid messing yourself up
with S0C7's and S0C4's and S0C1's - the most common programmer
errors in my experience / observation).
Why can't TSO CLISTs and EXECs run commands in background
as I can with POSIX shell "&", and let me use my terminal
in the meantime?
I agree with you on this point.
Submitting to a batch queue is a stopgap.
Wait. A stopgap for what?
There's no simple
and standard way to get completion status from a program
submitted to a batch queue, or even to tell when it completes.
Umm. Using JCL batch, you have condition code processing.
Admittedly not elegant.
With POSIX shell, it's as simple as:
( command1; command2 ) &
PID=$!
# ... Do other stuff with terminal session
wait $PID
echo $? # display status from "command2"
command1 and command2 are completely isolated from the terminal
session and, if _BPX_SHAREAS=NO, from each other. In z/OS,
I can't even run an authorized program from an EXEC except with
severe constraints:
o It must be under TSO, not USS or IRXJCL
o It must be invoked with CALL, not ATTCHMVS or LINKMVS.
Running authorized programs probably should have some constraints.
I mean, they require authorization, right? Now there is room for
some good discussion of which programs / commands should be
authorized and which ones need not be. Some could probably be
re-written to relax some constraints so you might have non-authorized
versions with less power than the authorized versions.
UNIX provides isolation for interactive commands similar
to that z/OS provides for batch jobs.
Yes.
-- gil
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-355-2752
http://www.trainersfriend.com
* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment
* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
