[Simh] Converting VMS BACKUP saveset file to SIMH tape file

[Larry Baker]

Jason,

The following DCL Command Procedure sets the record size of a VMS  
Backup SaveSet that has lost its RMS attributes, such as after it has  
been FTP'd (from http://lists.samba.org/archive/samba-vms/2002-February/000170.html) 
:

Below are the lines of a VMS command procedure (available on the VMS  
FreeWare CD) which converts FTP
received save sets to the correct RMS format for the VMS BACKUP utility.

$! RESET_BACKUP_SAVESET_ATTRIBUTES.COM
$!
$! P1  is the specification of the BACKUP saveset
$!
$! This procedure resets the record format and record
$! length attributes of a BACKUP saveset -- savesets
$! can get "broken" during certain sorts of file
$! transfers -- such as FTP.  This procedure reads the
$! (undocumented) saveset record attributes directly
$! out of the target file.
$!
$! First render the saveset readable, and implicitly
$! check that the file exists.
$!
$ Set File -
     /Attributes=(RFM:FIX,MRS:512,LRL=512,ORG=SEQ,RAT=NONE) -
     'p1'
$
$ Open/Error=whoops/Read BckSaveset 'p1'
$ Read/Error=whoops/End=whoops BckSaveset Record
$ Close/Nolog BckSaveset
$
$! Find the blocksize from within the record...
$
$ BlockSize = 0
$ BBH_L_BLOCKSIZE = %x28*8
$ BlockSize = F$CVUI(BBH_L_BLOCKSIZE, 32, Record)
$ If BlockSize .lt. 2048 .or. BlockSize .gt. 65535
$ Then
$   Write sys$output "Unexpected block size"
$   Goto whoops
$ Else
$   Set File /Attributes=(RFM:FIX,LRL='BlockSize', -
        MRS='BlockSize',RAT=none) -
        'p1'
$ endif
$ exit
$WHOOPS:
$ Write sys$output "Error"
$ exit

Execute this procedure with the name of your FTP received save set as  
the P1 parameter.

ex. @RESET_BACKUP_SAVESET_ATTRIBUTES my_save_set.bck

I found some other useful comments at http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1269972392060+28353475&threadId=1417205 
:

> Hi Dave,
>
> binary download creates files with fixed length (ok for BACKUP), but  
> 512 bytes record length (usually not what BACKUP expects).
>
> On a sufficiently new system, just add the /REPAIR qualifier to your  
> BACKUP command.
> On older systems, use
> $ SET FILE /ATTRIB=LRL=32256 saveset.bck
>
> The actual record length may vary and can be found out once BACKUP / 
> LIST gets sufficently far to display the savest block size, or you  
> DUMP the first block of the saveset and get the required record size  
> (in hex) at offset 28(hex).
>
> Hans.

You might be able to use this information to obtain the block size  
from within the Backup save sets you FTP'd to your PC.  This will be  
necessary to create the correct ANSI tape labels and file records on  
the SIMH virtual tape.  Columns 6-10 in the ANSI HDR2/EOF2 labels are  
the block length in ASCII (32768 in Edward Berry's example) and  
columns 11-15 are the record length (the same as the block length for  
Backup save sets).  The block size can be between 2048 and 65535 bytes  
(characters).  The default block size for save sets written to  
magnetic tape is 8192; the default for disk is 32256.  Backup may  
adjust the value it actually uses.  Edward's Fortran code fragment has  
the 32768 block/record length hard-coded, which is correct for his  
example, as shown by the EOF records he listed.  Your Backup save sets  
may not have the same block/record length.  (Most likely, they will  
not.)

I am not sure what you want to accomplish in the long run.  I have  
created throw away SIMH VAXes just to restore Backup save sets.  For  
example, I have created a MicroVAX, installed OpenVMS and DECnet and/ 
or TCP/IP.  Using that system I have transferred Backup save sets over  
the network to the SIMH disk.  I then created additional RA disks and  
restored an image Backup save set of an existing bootable system disk  
to the additional RA disk.  I then booted off the additional disk into  
the OpenVMS system I really wanted to use.  Once you have a SIMH  
OpenVMS system on any disk, you can use it to backup and restore any  
other Backup save sets using as many additional RA disk images as you  
like.  (Lots of VAX disk images will fit on a PC disk.)

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20100330/f5122ed4/attachment-0003.html>