03-30-2011 10:04 AM
This is an HP3000 box running HP ARPA File Transfer . Here is the commands I am using.
BINARY --- set to a binary file transfer
MPUT @ ----send all files to destination
So, here is what happens. What appears to be program files are moved over, but database files are left behind.
I tried using MPUT for a file that did not transfer VENDMASL. I get an error FTPERR 13 which says check the other error message. There is no other error message. I think this could be a permissions error, but I am not sure.
The file does not transfer. When I do a LISTF VEND@,2 the file shows as a type FAK. This seems to be the common thread on the files that do not get moved over.
I changed from BINARY to ASCII, tried the MPUT VEND@ again with the same result.
Thinking it might be a lock condition, I made sure everyone was logged off. Tried the command again, got the same result.
How do I get these files to FTP over to the Windows server 2003?
If I have left some information out, please let me know what I can provide, and maybe how to get it for you (remember I am a novice on this OS).
After I get this working, I am trying to create a script or bat file to schedule it for a nightly run. I have the script for that but I think its problem is the login portion. However, if it doesn't copy the whole set of files, I can't use it anyway. The manuals have been helpful, but of course, they assume a basic understanding of the platform. I'm sure someone out there would be able to identify the coding errors on sight. I'll post the script for review if I can get the ftp to work for all files.
Thank you in advance for your help.
Solved! Go to Solution.
03-31-2011 04:48 AM
A file on the HP3000 with the label of FAK is a Fixed Ascii Ksamxl file. If you just want the data that is contained in VENDMASL FTP'd to the Windows system and not caring about it being a KSAMXL file.
:PURGE JUNKFILE (or whatever scratch file name you want)
:FCOPY FROM=VENDMASL; TO=JUNKFILE; NEW (This will use VENDMASL as the source file and create a new FIXED ASCII file that is not Keyed or KSAMXL and is not Keyed).
If you want the FTP'd file to still be called VENDMASL, then you could rename it.
:RENAME VENDMASL, VENDMASX
:RENAME JUNKFILE, VENDMASL
03-31-2011 05:46 AM
These files worry me in that I would want an exact copy that could be restored back to the HP3000. Using your technique of copy to a 'junkfile' might leave attributes off that are needed during the restore. Again, I am a novice on this system, so feel free to set me straight on how Ksamxl files work.
On other systems I have worked on, sometime you use a command to build the keys. Is that the way this woud work.
Ideally, I want to just create a backup set that could easily be restored.
03-31-2011 07:03 AM
First try this little experiment:
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. iow, to store the whole system you need 50% or better free space (which you probably don't have ;-) iow2, 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).
04-02-2011 01:27 AM
Yes, you could record the key info but Donna's solution works for all types of files and lot of them.
04-05-2011 08:34 AM
04-07-2011 01:19 PM
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.
04-12-2011 07:48 AM
04-12-2011 12:28 PM
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 3000 up to a disc file then transfer (ftp) it to a Linux server. Here's the gist of the JCL:
!STORE / - /BACKUP/ ;*T &
user userid password
put FULLB.PUB.BACKUP hp3000-full
Hope that helps.