How to Transfer Data Files on a 3000
June 21, 2013
It's a Friday and perhaps time to do some deeper maintenance of your HP 3000. A weekend offers an opportunity to move data from an older system to a newer replacement for homesteaders. Here's some advice on using FTP to make a data migration.
You can use FTP to ensure a safe backup of 3000 data. In one case a manager said he needed to backup KSAM XL files, but the manager didn't know that his FAK files were HP's special Keyed Sequential Access Method database files. "What appears to be program files are moved over," he said, "but database files get left behind. How do I get these files over to our Windows server?"
Please note, IMAGE has priviledge protections which don't exist for KSAM. Purging is controlled, for example. KSAM XL files are really just files combining indexes and data, and can be purged without regard to priviledges. Nonetheless, this 3000 uses KSAM XL is running MPE/iX 6.0 -- so there's more than just some management experience missing from this server. 6.0 is more than 13 years old.
MPEX, Vladimir Volokh reminded us, performs more powerful operations to go beyond HP's security. For example, an SM user can do a COPY @.DATA.PROD, @.DATA.BACKUP. Copying only KSAM files: COPY @.DATA.PROD (CODE=""KSAM""). MPE cannot give you such ability to copy only KSAM files.
One rule of 3000 operations is that these data-containing files act differently than all others while being transfered. So FTPing them to a Windows 2003 server won't be a successful way to ensure a safe data recovery. (There are third-party tools to do this, updated and supported in a way that STORE or HP's TurboStore subsystems will never be supported again.) But if a 3000 is stuck on 6.0, it's probably going to have only enough budget to tap included HP software for file backups and transfers.
Donna Hofmeister, whose resume helping 3000 users occupies a vast chunk of the 3000 newsgroup archives, suggests starting with mystd to store the files to disk -- then transfer the STD file.
file mystd;dev=disc
store [email protected];*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
@[email protected] -- all files in .sys
@[email protected] -- 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 your 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.
Chris Bartram, who still operates an information treasure-house in 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 my primary HP 3000 up 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