« Tool Time for Information Veterans | Main | On HP's Operating Systems, Future and Past »

April 28, 2011

File transfer backup tips flow off HP's forum

Relying on HP for 3000 support is becoming a gamble and a gambit. One of the spots to place a bet is on an open forum run by Hewlett-Packard's support team. A recent quest for FTP techniques reveals yet another place where independent experts share MPE/iX answers.

The question was how to use FTP to ensure a safe backup of 3000 data. In this case it was a KSAM XL database, 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?" This 3000 is running MPE/iX 6.0, so there's more than just management experience missing from this server, since 6.0 is more than 10 years old.

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. (There are tools like Orbit Software's Backup Plus to do this, updated and supported in a way that STORE or HP's TurboStore subsystems will never be supported again.) But if a machine is stuck on 6.0, it's probably going to have only the 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-L newsgroup archives, suggests starting with mystd to store the files to disk -- then transfer the STD file. The advice arrived from a source that won't see a forced shutdown, or a portal migration, like HP's. The answers came from your community.

"First try this little experiment," Hofmeister began in her answer.

    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 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

Bartram hoped his answer helped the manager handling a 6.0-vintage HP 3000. HP's now got few unique resources to solve these problems. Most of these answers can be found on the 3000-L list, where both Bartram and Hofmeister have been regular contributors. HP's said this week that its IT Resource Center forums will remain open to everyone, even after the migration to the new HP support portal is enforced on June 1. If the vendor changes its mind, it's comforting to know there's a community resource to surpass HP's answers.

02:05 PM in Hidden Value, Homesteading, Web Resources | Permalink

Bookmark and Share

No more trying to figure out what runs on
MPE/iX or where to find it. No more worrying
about availability! www.MPE-OpenSource.org
is all things MPE/iX: Open Source packages,
freeware, scripting, plus loads of tools
and information to keep your 3000 system
alive and thriving!

Comments

Comments

The comments to this entry are closed.