Copy a file with same format

[Andy Bustamante]

I don't want to cast any doubt on the qualifications and ability of anyone who's already posted a reply, but there is a network backup solution available for OpenVMS. Symantec NetBackup may provide the functionality you need. The application allows you to save and restore OpenVMS files. There is no "bare metal" restore option, you'll either need to maintain operating system tapes or be prepared to install a recovery operating system. You could attempt to deploy your own solution of course.

[Robert Gezelter]

rbhaqwat,

I agree with Hein and Hoff, among others. This is a complex project, and is definitely not a starting point.

As has been noted, BACKUP took quite a bit of care to get right, and had its share of issues along the way. Starting the climb to this level of functionality from nothing is definitely a challenge.

I would concur with getting some professional assistance from someone with significant experience in these areas.

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

> [...] Symantec NetBackup may provide the
> functionality you need. [...]

Do you think that they'll sell him the source
code? He wants to _sell_ some software, not
to _buy_ some software.

> [...] So we need to design a kind of format
> [...]

Because you've looked at the existing
Info-ZIP stuff, and it's all unsuitable?

> Is this the right direction ?

I doubt it, but if that's what you want to
do, ...

> [...] have a look at how zip and unzip
> preserve the metadata.

I could be biased, but it's just possible
that if you get the same piece of advice from
everyone who knows anything, then perhaps you
should spend a little time investigating that
suggestion. Just a thought. I don't want to
tell you how to do your job.

[Shriniketan Bhagwat]

Hi,

I agree with Hoff that BACKUP has taken these many years to be at this stage. It took quit some time for us to fix the backlink errors between VMS$COMMON.DIR and SYSCOMMON.DIR (BACKUP-I-BTCROUT) and also while adding /GPT qualifier. While designing the applications like BACKUP, it is required to know the disk structures, file system, RMS APIs, system services etc. Ultimately it is the question of data integrity. You may archive some critical data today and you do not want to see the restore errors after a year when you restore it. We had few such instances in the past. Luckily they did not lead to data loss.

Regards,
Ketan

[Jeremy Begg]

There is an alternative to processing the FAB and XAB structures yourself. You might find a solution using the FDL routines (see the "OpenVMS Utility Routines" manual).

Specifically, you can use FDL$GENERATE to create a textual representation of the file's RMS structure. You could then store this meta-data on the backup server, along with the file contents (read using block I/O rather than record I/O).

To restore the file you could use FDL$CREATE or FDL$PARSE and then write the file (again using block I/O).

Note that I have not tried this and there may be significant problems with this approach that have not occurred to me in the 2 minutes it took to type this response. But you might find it an instructive exercise nonetheless.

Regards,
Jeremy Begg

[rbhagwat]

Hi,

Thanks. I thought about it and saw the FDLs
generated. It did not generate all the
information that we wanted to backup and
restore.

Thanks,
Rahul

PS - This C RTL is not really useful at all.
I am moving towards using system services
almost for everything. (So this is like a new
code instead of porting). Specifically,
exec and vfork cannot simulate what fork() and
exec() does on UNIX fully.

[Hoff]

Most C applications don't use the full copy on write virtual memory management capabilities of the fork/exec processing; only a select few do. And VMS lacks copy on write.

There are hooks in the CRTL to allow some of the (other) capabilities of fork/exec to be replicated on VMS. See the decc$set_child_* calls for maintaining (some of) the context.

VMS is lacking the clone() call that you'll find in Linux.

Some low-level file system details are available here:

http://labs.hoffmanlabs.com/node/209
http://labs.hoffmanlabs.com/node/112
http://labs.hoffmanlabs.com/node/28

There are pointers to some of the specs from there.

You'll also be working in the XQP layer for some of what you need; that's where the metadata is most directly accessible. And for a full-disk bootable restoration, you will need to use logical I/O calls for some of the restoration processing.

There's an RMS-level C library here:

http://labs.hoffmanlabs.com/node/1260

That library will be nowhere near what you will need to have here, given what you're up to, too.