Not magic, but also not STK/Sun/Oracle.
STK tape world is significantly different from IBM tapes.
There are also other players (EMC DLM, etc.) which follow way similar to
IBM, but all of them are defined as MTL (Manual Tape Library).
Few differences between STK and IBM:
IBM provide all necessary software components in z/OS base. No need to
add/buy/install anything else. STK require its own software suite, many
components are in the suite. Some of them depend on configuration.
Communication host-ATL. Control path for IBM is embedded in data path
(FICON). For STK ATL the control path is over IP. For older STK ATL
there was coax connection required (big pain nowadays!) which meant it
was like coax-attached terminal.
However communication to VSM (STK virtual tape) is over FICON.
Virtual tapes. Data are stored on some disk array, however VTS emulate
whole library, so theoretically you can move your VTS and attach it to
installed from sratch host and you can access data. In STK world data
are still on disk (SVAA), but virtual volume definitions are kept on the
host. So, you need working STK software *and* proper control data set to
access data.
Because of differences DFSMS recognize IBM ATL and that is important for
ACS routines, storage classes, etc. Everything is in DFSMS. For STK most
definitions are in SMC/HSC software components configuration. From
system point of view usually you define some esoterics in IODF.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 27.05.2020 o 03:32, Ken Smith pisze:
*totally different technology...*
Magic?
On Tue, May 26, 2020 at 5:11 PM Jesse 1 Robinson <jesse1.robin...@sce.com>
wrote:
I'm not advocating this practice. Just saying that we did it for 25 years
without a failure. We're now moving to totally different technology where
such action is not even in the picture.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf
Of R.S.
Sent: Monday, May 25, 2020 5:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Opinions/experience on sharing catalogs outside
plex
CAUTION EXTERNAL EMAIL
Skip,
In the past I implemented STK tapes, the largest tape system in Poland at
the time. Interesting job. :-) It seems, you shared control datasets
between datacenters. Assuming your second datacenter is for disaster
recovery, you had single point of failure. Catalog is not important there,
but availability of datasets is. How could you work with tapes in case the
datasets are lost due to catastrophe of primary DC?
IMHO the only way was to have remote copy of control datasets. Last, but
not least, as far as I remember the datasets were very specific - they have
(had?) hardcoded both volume labels and device numbers. While remote copy
replicate volume label, the dev num is IODF dependend. There was a method
for that, I forgot details. Other method could be a trick with duplicate
device numbers.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 24.05.2020 o 21:29, Jesse 1 Robinson pisze:
Until recently, we shared a catalog not only across sysplexes but
between data centers. All because of tape. We had STK virtual tape (in
both data centers) supported by MIA (Multi Image Allocation). These
products require control data sets shared among all exploiting
systems. We could have managed with uncataloged data sets, but that
was deemed riskier in the long run than a shared catalog. The only
entries in the catalog were for tape management data sets. We never
had a catastrophe. 😉
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
Behalf Of R.S.
Sent: Monday, April 20, 2020 7:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Opinions/experience on sharing catalogs
outside plex
CAUTION EXTERNAL EMAIL
Well, it is not good idea, but sometimes even such idea is better than
nothing.
What's important the risk covers THIS catalog only, not whole world.
And yes, this catalog and shared datasets should be shared without
"sysplex features" like changes is serialization. RESERVE should be used
here or CA-MIM should be used, but the last one is add-on tool.
BTW: BCS can be defined with SHR(3 4) or SHR(3 3). For this case it has
to be SHR(3 4). AFAIK it is alterable.
Again: small activity is your friend here. Small number of datasets
cataloged in the BCS is good here. Potential problems with the BCS will not
affect other BCSes.
I use it for years (with limited activity). Mostly PS files and some
VSAM. No problems observed.
Caution: PDSE *will* break despite of way how catalog is shared. No help
from CA-MIM, AFAIK. Observed many times educated many guys who used PDSE
for sharing.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 20.04.2020 o 14:45, Allan Staller pisze:
Yes, it can be done. I reiterate, IMO, this is most likely not a good
idea.
In order to accomplish this safely, you also need to regress GRS to
pre-GRS functionality.
Everything affecting this catalog must be handled w/Reserve/Release,
and not normal processing VSAM Sharoptions for the catalog need to be
changed. IIRC when I "undid" this the catalog hand Shareoptions (2,3) (or
was it 4,3?).
This option tells z/OS that the user is responsible for Catalog
seriailization.
SYSDSN, SYSIGGV2, SYSVTOC, SYSZVSAM (?) and the SPF* queues need to be
excluded from GRS processing.
In my case that led to various deadly embraces that usually led to
manual intervention.
My $0.02 USD on this is: Why point the shotgun at your foot?
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On
Behalf Of R.S.
Sent: Monday, April 20, 2020 3:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Opinions/experience on sharing catalogs outside plex
[CAUTION: This Email is from outside the Organization. Do not click
links or open attachments unless you trust the sender.]
W dniu 09.04.2020 o 02:11, Rob Schramm pisze:
I am considering sharing some usercats outside of a sysplex. What I
can find is that sysiggv2 must be kept as a reserve to do so.
Looking for others that have had to do this.
One question I had was, what happens on a ispf 3.4 when the data set
is part of the catalog but exists in another system? Ief238d?
My €0.02
1. You can share catalogs between sysplexes. Note: we mean BCS, which
is usually called catalog.
2. The less activity on the BCS the better.
3. The above means:
3.1. Avoid keeping non-shared datasets in the BCS. Use another BCS for
that.
3.2. It is not bad idea to have multiple "small" shared BCSes.
4. You cannot use any sophisticated catalog sharing features like RLS
or ECS.
Regarding you last question: I understand it as you have entry in the
BCS, but the dataset reside on volume which is not share, that mean it is
unavailable for one system. It's nothing exotic. It's like orphan catalog
entry, which sometimes may happen even without BCS sharing (usually as
result of human error).
However that also means the sharing is not done correctly. The best
scenario is when all datasets cataloged in shared BCS reside on volumes
which are also shared. Preferably the BCS is also on the volume from that
group.
Keep it simple.
--
Radoslaw Skorupka
Lodz, Poland
======================================================================
Jeśli nie jesteś adresatem tej wiadomości:
- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza)
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać
karze.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st.
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237,
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
01.01.2020 r. wynosi 169.401.468 złotych.
If you are not the addressee of this message:
- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have
printed out or saved).
This message may contain legally protected information, which may be used
exclusively by the addressee.Please be reminded that anyone who disseminates
(copies, distributes) this message or takes any similar action, violates the
law and may be penalised.
mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital
City of Warsaw, 12th Commercial Division of the National Court Register, KRS
0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN
169.401.468 as at 1 January 2020.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
