Welcome to the real world, R.S. I gather that the environment or
industry in which you work hasn't been doing business data processing
for enough years for entrenchment of old technology to be an issue.
Over the next 20+ years you will perhaps understand some of the issues
I've been raising after you have to deal with them yourself.
Changing procedures within your own company when you have a large
application base CAN be a big deal, but do-able when those within your
company respect your expertise and you can make a valid case. But, we
are talking here about procedures for exchanging data with other
installations controlled by other entities. Time and time again over
the last 30+ years we have found cases where you have minimal influence
in forcing other companies to commit time and resources to making
changes, even when they are mutually beneficial! A companion problem is
that those companies using down-level technology for data exchange also
seem less likely to have in-house skills for implementing (or in some
cases even discussing) new technology.
Technologies used for corporate DR purposes or for internal use only are
a totally different game, and here the economics of high-speed,
high-density tape methods and tape stacking make excellent sense, and in
fact our initial investment in 3590E drives was justified totally by DR
requirements. The only other site capabilities that enter the picture
here are the capabilities of your DR vendor, but they have to stay
relatively current in order to compete.
Unless you are in an industry that requires very short DR recovery
times, DR techniques using remote DASD and high-speed remote data links
rather than off-site tape are still too expensive to justify
economically, even though they may be elegant from a technical
standpoint. If your company doesn't own a hot recovery site, remote
DASD is also impractical with many DR vendors in the U.S., where vendors
generally don't guarantee which of many recovery sites you might be
using in the event of a real disaster.
Data exchange electronically is no barrier to obsolescence. One of the
obsolete data exchange methods that persisted with some of our customers
l-o-n-g after its prime used BTAM protocol over 4800 and 9600 baud
modems! Whatever technique you are using for electronic data exchange
today will be obsolete in 10 years, but some sites will persist in
using/requiring it for years afterwards.
If a CART is lost or potentially stolen, one has to assume the worst and
that the data is compromised (unless, of course, all sensitive data is
encrypted); but the reality is that few individuals encountering such a
tape would know what it was, and even fewer would have access to the
sites with hardware able to read it. DVD media is readable on well over
100M private PCs world wide, and if a DVD with unencrypted data were to
fall into the wrong hands, the odds are high that sensitive data could
and would be exploited. One should use similar methods to secure data on
either media; but should you fail to do so and the media is lost, DVDs
have a much greater exposure.
R.S. wrote:
Joel C. Ewing wrote:
[...]
Yes, DVD capacity is greater than the compressed capacity of a 3490
cartridge and cheaper than a 3490 cartridge, but ...
few shops have the capability of writing or reading DVD data to or
from MVS without manual file transfer being done by someone, versus
tape availability to automated batch and long-established procedures
for physical security of tapes. Manual file transfer methods may be
acceptable when dealing with one or two transfers, but this is not a
reliable or practical technique for a large shop with many transfers.
Procedures can be changed. It's really no big deal. Insted of mounting
tape (MANUAL PROCEDURE!) a DVD is inserted into a drive. It can be even
better automated than with the tape. Imagine autorun.inf on the DVD
running ftp script - operator inserts DVD, sees "please wait" and "thank
you, now remove your DVD". Or without autorun, simply insert and click
the icon (or issue a command when in text mode). Or insert a DVD, and
run the very same job as it was last 20 years, ...but instead of
IEBGENER it runs FTP (a PC is running ftp server). Even computer
illiterate can manage such a process.
Having your data on a DVD media readily readable and writable by every
potential hacker with a PC also introduces additional security breach,
data corruption exposures that should first be considered and
addressed before using this for exchange of sensitive data.
A cart can be stolen (like DVD). A PC, properly configured and isolated
from Internet, etc. is pretty safe.
Many shops may have both 3490E and the newer 3590 capability, but it
doesn't make economic sense to use an expensive 3590 cartridge (also
more sensitive to mishandling) when a 3490 cartridge will more than
hold all the data (nor does it make economic sense to use dozens of
3490 cartridges when a few 3590 carts will do the job). With
relatively small files, the mount/unmount time may be more significant
than the actual data transfer rate, and the mount/unmount time of
3590's exceeds than that of 3490 drives.
I don't know real business need for such scenario, but I believe in such
cases tape writes should be simply avoided. THe data can reside on DASD,
until it's offloaded to a dense media. Inserting 3490E carts during the
day is simly waste of time. The data can safely wait on RAD-protected
DASD. Additionally it can be "flashcopied", "PRRC-ed", etc. Large
amounts of data should be moved to a dense tape, possibly in two copies,
possibly in two locations.
The bottom line, however, is you do what is necessary to support
required data transfers to customers or government agencies.
That's the case when third party forces you to use obsolete technology.
BTW: I don't know U.S. regulations, but in my country no agency requires
any media from private corporation. Data exchange is over the wire.
--
Joel C. Ewing, Fort Smith, AR [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
