« Emulation Without Need For A Cradle | Main | River cruiser to ferry MPE exokernel mission »

April 01, 2015

File transfer tips flow to move databases

System managers in the 3000 community still want to know how to use FTP to ensure a safe backup of 3000 data. Of special interest is the KSAM XL database, but most managers don't know that FAK files are HP's special Keyed Sequential Access Method database files. What appears to be program files are moved over, but database files get left behind. There's a trick to getting such files over to a Windows server.

One rule of 3000 operations is that database files act differently than all others in transfers. So FTPing them to a Windows 2003 Server won't be a successful way to ensure a safe data recovery. Third party tools can help, but if a customer is stuck on an aging HP system running MPE/IX, it's probably going to have only the budget for the included HP STORE for file backups and transfers.

Donna Hofmeister, who's spent a career helping 3000 users via the community's newsgroup, suggests starting with creating a file called mystd to store the 3000 files to disk -- then transferring that Store To Disk file.

 "First try this little experiment," Hofmeister begins in her advice.

    file mystd;dev=disc
    store a@.pub.sys;*mystd;show

If it works, you just stored/archived all the files that begin with 'a' in the .pub group of the .sys account into a file called 'mystd' (my store-to-disc).  You can expand the number of files being stored into your STD file by modifying your store command to:
    @.pub.sys -- all files in .pub.sys
    @.@.sys   -- all files in .sys
    @.@.acct  -- all files in .acct (for example)
    @.@.@     -- all files on the system (and it's actually better to say '/' instead of '@.@.@')

Keep in mind that as you increase the scope of what you're storing, so does the size of your STD file. In other words, to store the whole system you need 50 percent or more free space , which you probably don't have. So, break what you're storing into chunks (do one account at a time) and things should go smoothly.

If STD doesn't work, you might be able to get tar to work. The same space precautions apply.  One advantage of using tar is you should be able to verify the tar file on the destination system -- something you can't do with STORE without a 3000 in the mix.

3K Associates' Chris Bartram, who operates the 3000 information treasure-house 3k.com, added explicit advice about FTP and the 3000's files.

If you package all the MPE files up in either a store-to-disk (aka std) or a tar "wrapper" (disc file) you can transport that file around at will -- as a BINARY file -- don't try to transfer it as ASCII or CR/LF translations will trash it.

Once you get it back on the 3000, a simple file equation directing your source (tape) to the new (std) file name (and add the ;DEV=DISC to the file equation) will allow you to restore the files onto the 3000 preserving all the MPE specific file attributes they started with. Tar will work similarly for almost all MPE files, but can't handle database/PRIV files and probably not MSG (message) files and a few other very MPE-specific files.

tar works the same way on MPE as on *nix boxes. But is much more "familiar" if you run it from the Posix shell (sh.hpbin.sys), though that's not necessary. Treat the tar file just like you would on a *nix box. 

For store-to-disc files, you use the same MPE syntax for storing files as you do normally; the only difference is that the output device is file-equated to ;dev=disc. As mentioned, be aware of the disc space required to store another copy of your backed-up files online. 

Likewise, when you restore instead of pointing to tape, you point to the disc file -- and don't forget to add ;dev=disc to that file equation as well. If the store-to-disc files are going to be very large (several gigabytes) you can use some additional syntax to break them into chunks - but hopefully you needn't worry about that for now. 

Treat a store-to-disc file just like a tar file. Record size and most other attributes aren't so critical, but if you move it around do NOT let FTP transfer it in ASCII mode or it will corrupt the file.

As for examples; I back up my primary HP 3000 to a disc file then transfer (FTP) it to a Linux server. Here's the gist of my JCL:

!FILE t=FULLB.PUB.BACKUP;DEV=disc
!CONTINUE
!STORE / - /BACKUP/ ;*T &
! ;SHOW=SHORT,dates,path;progress=5;directory;tree;&
! onvs=MPEXL_SYSTEM_VOLUME_SET,WORK;STATISTICS;
!COMPRESS=HIGH


!ftp.arpa.sys
open ftpserver
user userid password
del hp3000-full
binary
put FULLB.PUB.BACKUP hp3000-full
quit

05:59 PM in Hidden Value | Permalink

Bookmark and Share

Use our search engine to find 20 years
of HP 3000 news and articles

Comments

Comments

The comments to this entry are closed.