× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi John

A sysplex is a way for z/OS and subsystems to "talk" to each other to
coordinate changes and access to resources. For example, RACF is the
security system on the z. I have a single database which contains all
users and all access definations for all systems. Every LPAR can safely
and directly do I/O to that database on DASD because they "talk" via
sysplex communications to "enqueue" access as needed for updating.

This sounds pretty similar to how IASPs can be made to behave. The IASP's
share the core OS things like spooling, host tables, devices, security etc.
but the DASD is allocated to different databases (ASP Groups). You can only
access one ASP group at a time, but you can switch between them via the
SETASPGRP command. Libraries can have the same name if they reside in an
IASP which makes creating test/live environments that behave the same pretty
simple.

I'm going to ASSuME that it is more like UNIX. The DASD is not shared,
but a program on one system can do a database call to read or maybe even
update a database on a different system. I will also assume that the
SPOOL is not sharable. Yes, we do that. Users on the development LPAR
can watch jobs on the Production system as they run and view their SPOOL
files both as the jobs run and after the fact.

Using IASP's all data and jobs are visible, but it is unix-like in that you
have to have the IASP mounted. A program can be run against any of the
databases simply by using a different job description with the appropriate
ASP group set or by issuing the SETASPGRP command before running the
program. Depends on what result you want to achieve.

Obviously you could easily create a mess by mixing and matching which
database you use but this is nothing new. An LPAR provides considerably more
protection against a test program inadvertently being run against production
data, but my view is that 20 years ago we routinely had test, dev and prod
environments on the same machine so it's simply a matter of discipline and
security.

Regards
Evan Harris



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.