Natasa,
If I understand correctly, you have data -- let's call them "files" --
residing on distributed Windows, UNIX, and/or Linux servers. You also have
mainframe-attached tape drives with WORM tape cartridges available, for
example IBM TS1120 tape drives with 3592 WORM cartridges. It's likely your
mainframe operations staff do a great job cost-effectively managing tapes
and protecting your company's most precious asset, its data. They may also
have implemented encryption and good key management, so that the data are
well protected. And they have prepared for disasters, so that your company
can stay in business if there's an emergency. These are all important
capabilities that require initial investments -- they are not free -- and
it's not surprising that you'd want to take advantage of them for more of
your company's data, to share the costs and benefits.
And you are presently using a major tape management product for z/OS, for
example IBM DFSMSrmm. You do not want to buy IBM Tivoli Storage Manager
(TSM) software for some reason -- I guess on why below. Lastly, you want
to keep the solution "as simple as possible."
Presumably you need this WORM capability because Croatian government
banking regulators require that your company retain certain records for a
period of time on media that cannot be modified. Perhaps a government
inspector or auditor told you you need to do this as soon as possible if
you don't want to go to jail. :-) This is a common requirement in many
countries, to prove to the regulators that you did not change certain
records past a certain date.
Did I get all that information correct?
If so, here are some ideas:
1(a). As a general architectural pattern, if you can relocate those files
-- databases, for example -- directly onto your mainframe they will then
come into your mainframe's tape management domain. For example, if the
distributed data are currently located in Oracle, DB2, or another
relational database, you could move those database tables to DB2 for z/OS.
Your applications, whether they remain on distributed servers or also move
to the mainframe, can then access DB2 for z/OS using standard protocols
such as JDBC or ODBC over TCP/IP, the same as they do today. (zIIPs can be
quite helpful for this.) According to a Gartner Group study from a couple
years ago this "data recentralization" activity, moving enterprise data
back into z/OS (and to centralized Linux databases), is a common trend for
the business reasons you have and many other reasons. There are occasional
application-related issues to switching databases, but these issues are
becoming less and less significant with each new DB2 for z/OS release. It
is a lot easier to move to DB2 9 for z/OS than to DB2 V6, for example.
1(b). If these are files rather than databases -- Microsoft Office
documents, for example -- then you can configure z/OS to act as a file
server using either NFS or CIFS/SMB file sharing protocols. These file
sharing capabilities are part of z/OS itself, so if you have z/OS you
already have these capabilities. A designated part of your z/OS file
storage (on one or more designed volumes) then appears to your Windows or
UNIX servers and clients as another file server, much like a Windows file
server ("Drive Z"!) or a UNIX NFS file server. You can configure
authentication via the z/OS Security Server (RACF) or another SAF-enabled
security system on your mainframe, as you do for securing other services,
so you can bring file sharing access into your same mainframe security
domain quickly and easily. And then, since the files always reside on your
mainframe, they are now part of your standard tape management domain, too.
This approach would work well for situations where your clients and servers
have good network access ("bandwidth") to your mainframe and for
medium-intensity or low-intensity file access. Office suite documents
would be a good example. It works best when the distributed server or
client records a point-in-time consistent copy to the network drive as
standard practice with every save. (The typical office suite is again a
good example.) A few applications and middleware products don't behave
this way -- most database servers, for example -- so you may need to
"quiesce" the applications just before you copy their files to WORM tapes.
2(a). If the above methods don't work, you might be able to use the file
sharing technique in 1(b) and have your distributed server (or client)
perform periodic (scheduled) copies of files or databases to the file
sharing area on the mainframe, quiescing applications if necessary.
However, there are some drawbacks with this approach. The first major
drawback is that it is less "simple": your distributed servers and clients
will have to copy files reliably, on schedule, to your mainframe. That can
become an administrative challenge and require you to buy and implement
enterprise scheduling software. (At that point, why not just buy TSM?)
Also, you are more likely to lose more data in the event there is a
distributed server failure, because there will be a greater time gap
between your last copy (copied to WORM) and the data residing on your
distributed server's own hard disk compared to the "live access" approaches
in 1(a) and 1(b).
2(b). Similar to 2(a), you can transfer files to the mainframe using
scheduled FTP. (z/OS includes an FTP server.) SFTP and SSH are other
possibilities. The drawbacks are similar.
3(a). I assume you are referring to TSM for z/OS and expressing some
reluctance about that particular product. And I'm guessing that it's a
reflexive "price" reaction to that product, as in, your boss told you to
solve this problem without spending any money. ("I want to date a
supermodel, but I don't want to pay for dinner." :-)) Let's explore that
for a moment.
If you plan to use TSM for z/OS exclusively for purposes of backing up
distributed server files or databases to WORM tapes, you may wish to review
the IBM zNALC announcement, complete a zNALC questionnaire, and send that
questionnaire to IBM. I can make no promises at all here, but you may be
able to create a zNALC z/OS LPAR -- probably a very small one, as little as
3 MSUs -- exclusively for TSM for z/OS and then run your backups through
that LPAR from TSM clients installed on your distributed servers. Ask your
favorite IBM representative to see if that path works for you and if IBM
will approve it. (As a reminder, I do not speak for IBM, at least not
today.)
3(b). A slight modification to 3(a) is to choose TSM for Linux on z and
implement Linux on z. This is probably getting less "simple" if you don't
already have Linux on z (and do have z/OS) since it would be the first time
you would implement Linux on z, but that's another possible option. I
believe you have to dedicate at least one particular physical tape drive to
TSM for Linux on z's exclusive use, so sharing the tape drives between
Linux and z/OS from hour to hour becomes a little more interesting (and
less "simple"). But TSM EE for Linux on z does support most
mainframe-attached tape drives.
There are probably other solution options, but these are the 6 major
options that come to mind immediately, if my assumptions are correct about
your requirements.
I hope this information is helpful. Please keep us all updated on your
progress.
- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
