From the other side of the world Arun said:
>Recently we received a request for enhancing FTP/iX to support
>database files. I am currently investigating the usefulness and
>possibilities of this enhancement request.
Yup, that was from me, on behalf of SIGIMAGE. :-)
>Enhancement proposal:
>The request was to have a FTP command called DBMGET
>to "copy all PRIV mode files with entries in the root file that
>are part of the given TurboIMAGE database".
The above is basically correct, but from my perspective it
does not quite convey the complete intent of the "DBMGET"
proposal that resulted from considerable discussion by the
SIGIMAGE Executive Committee (SIEC). The precise wording
the SIEC agreed on that was forwarded to Bangalore was:
"A DBMGET that guarantees a complete FTP copy of all
PRIV mode files with entries in the root file that are part
of a TurboIMAGE database".
Arun went on to ask if an alternative would be O.K.:
>The current version of FTP, which is in beta testing now and planning
>to be part of 5.5 Express 3, supports FTPing privileged files. So,
>the above can be achieved by the FTP command "MGET ZZZ@" for datasets
>and "MGET ./zzz@" for jumbo data sets.
Arun is of course correct: A complete copy of an Image/SQL
database can successfully be completed this way. If you do your
FTP MGET specs correctly, you can pick up "regular" datasets,
jumbos, coming-soon B-trees, and TPI files...... providing:
(1) FTP/iX will handle both FCODE= -400 for the root file and
FCODE= - 401 for the other non-HFS datasets when doing
"MGET ZZZ@" as per above example. I haven't seen the new
FTP specs, so don't know. But since Arun puts it this way
in his example, I assume that it does (which if so is good, BTW).
(2) Your job doesn't fail to complete for some reason between
"MGET ZZZ@" and "MGET ./zzz@", and you don't notice until
it is sweaty-palm time.. Of course if you carefully do proper
error status checking and reporting along the way, whatever
failures might occur should be detectable and reportable.
(3) You haven't done some kind of "narrow" selection of file
sets with multiple FTP MGET sequences, to get just the
database files while excluding other files that may start with
the same leading characters as the database.. And then you
add some new datasets with a database tool and forget to
update your job files and end up "silently" not getting all the
datasets in your FTP copy..... And / or etc., etc.....
So: Rationale behind the "DBMGET" extension was to make
it as simple and straightforward as possible to guarantee a
complete copy of the specified database, and if so desired
ONLY the database... Sort of a variation of the oath people
take on the witness stand: "The truth, the whole truth, and
nothing but the truth"... Well, "the database, the whole
database, and nothing but database"... (sorry; gave in to
temptation again; it's late. ;-) ).
That's why we thought the best way to FTP an Image
database would be to be able to just say:
DBMGET dbname
.... Nice, clean, and simple.
FTP would then check the root file and get the complete
list of *all* associated PRIV mode files as defined in the
database itself, and then do the FTP copy. If all of the
required files defined in the root file do not successfully
make the trip, then report an error condition.
So to answer Arun's last question:
>With MGET supporting privileged files, do you still require
>the DBMGET command?.
Well, for the above reasons I still think it is worth doing.
However, I will also note that with the implementation cycle
far along for the next release of FTP, if somehow doing a
DBMGET is a major effort then I could understand if HP
said it was not possible to get it in this release. But since
FTP/iX is already going to be able to handle PRIV mode
files, we were hoping that it would be a relatively small effort
to take just the database name as input, check the root file,
and complete the copy the user can already manually
specify (if said user is careful and everything completes).
>If so, why MGET is not sufficient?
See above. :-)
A couple quick comments on other replies to Arun's post:
The above proposal was not really targeted at trying to copy
an Image database to something other than an HP 3000. As
mentioned, it would be a little hard to run Image on another
platform.... And even if the idea was just to store an Image
database on another platform, I have a feeling you could get
some *real* strange results converting to a byte-stream file on
some UNIX machine or etc. on the other end that knows nothing
about MPE records and file types.
Paul's comment really got to the heart of the matter. He said:
>.... having a command that will transfer the entire database
> will minimize the possibility of transferring an incomplete
>database.
Getting an "incomplete database" as a backup copy and then
finding out it's all you have left could ruin your whole day.
Also, with disc space becoming less and less expensive I
suspect more sites might look at having a backup volume
set on which to make disc-to-disc copies of a production
database which can then be stored to tape more-or-less at
leisure; plus that keeps a backup copy on line. We have
found this to be a good practical solution (of course we don't
have hundreds of gigabytes to back up either).
SHORT SUMMARY: My vision of DBMGET is that it would
provide the FTP equivalent of DBSTORE... Actually, better
than DBSTORE, because it would handle the various HFS
files that can now be part of an Image database and would
be able to make disc-to-disc copies. Hmmm... One more
thought: If now or later we get a "DBMGET" in FTP, should
it set the "stored" bit in the root file like DBSTORE ???...
Off the top, I think so.... Someone else can answer that
question if they want to; right now I'm going home. :-)
BTW, let me say that just having FTP be able to copy a PRIV
mode file at all is a major advance... There is a big difference
between discussing the best way to do something, and not
being able to do it at all. Thank you to HP for providing this
very important basic feature in FTP/iX....
My $0.50 or so,
Ken Sletten
SIGIMAGE Chair
|
