Ah, I found that problem too with the MPEX Audit file (and the
Security/3000 log too) as well as Image log files.
I simply made an online backup, (using whatever backup program will do
that) restored the files to a different group, then file transferred the
restored files instead. (Since the restored file wasn't being dicked
with by the system.)
On 8/28/19 6:39 AM, Roy Brown wrote:
> Reliability of FTP
>
> We transfer files weekly with FTP. We have the added complication that we appear to be sending them to a certain place, but the wonders of MFT mean that they aren’t going there at all (when it works) but to the place where we want them to go.
>
> We’ve had all sorts of problems along the way, but think we have it sussed now.
>
> Firstly, we were sending before the files were complete. I thought that on MPE, you didn’t get the file until it was complete, but I think we found an exception (MPEX VEAudit File).
>
> Solved by having the transfer job streamed by the file generating job if/when it finished, instead of running it independently at a certain (now found to be premature) time.
>
> Next, the destination location filled up, so no files were actually being transferred. But no errors were being reported. Even ExitOnError didn’t help here, as the destination location, or MFT, or whatever, was lying to us that the transfer had gone OK.
>
> Solved by reading back a couple of the files from the transfer location, and comparing them with what we sent. All automatically, in the transfer jobstream.
>
> The most recent error was a doozy. MFT, which normally send the files to the true target location, suddenly started keeping the files in the notional location we were sending them to (and as we thought, through). Everything above still worked. But, it only kept the files for a few days, and they never went where they should.
>
> Solved by manually creating a marker file in the true destination location, and reading for that as the first step in the FTP transfer. If the job doesn’t see it, it knows it isn’t looking at the true target destination.
>
> The files we are sending are a selection from files we hold on the HP3000 on 180-day retention, so we have a few months to recover if the process finds yet another way to try to deceive us. But we think it’s pretty solid now.
>
> FTP versus Reflection File Transfer
>
> We have a lot of data retention requirements in our industry, and we have a second ‘production’ HP3000 doing nothing but holding old data in case somebody wants to look at it. And even the main one has gigabytes of data from applications that are no longer used.
>
> My ongoing project, in between my day-to-day tasks, is to deal with this. The idea is to get the gigabytes of unused data off the main machine into long-term storage, along with the truly unused data from the second server, and then consolidate the ‘just in case’ data onto the main server. Then we can decommission the second server.
>
> But the unused data needs to be able to be brought back onto the main server, at least application by application, as nobody is going to let me archive it without demonstrating true retention - for at least as long as we retain any HP3000 at all.
>
> So I thought, OK, leave the accounts in place, make a store to disc of the data in each one, transfer that with Reflection as a Reflection Labels file to my archive store (I have access to up to a terabyte of Windows storage, which I can pack this lot in one small corner of, it being less than 100GB all told).
>
> But a test showed this was way too slow, and anyway, Reflection does not support PRIV files, though you may not have this concern. I think my laptop is the bottleneck here, as everything has to go through it, even on the fast network in the office.
>
> So I decided FTP was the way to go, and it was fast enough. I had to use MPEX’s ALTFILE to change the filecodes to the same but without the minus before FTP would take them, and on the return journey use build parms on the FTP GETs to get the files back how I wanted them.
>
> None of which will be a concern for you if you are moving simple ASCII or BINARY files, especially if you won’t be trying to bring them back.
>
> And Reflection may still be feasible if these are small files you are transferring, MBs rather than GBs; but it doesn’t scale well.
>
>
>
>
>
>
>
>
>
>
>
> Sent from my iPad
>
>> On 27 Aug 2019, at 20:35, English, Jim <[log in to unmask]> wrote:
>>
>> I use MPEX and put the "RUN FTP" into a WHILE loop, checking the CIERROR and FTPLASTERR. It pauses 30 seconds if there are errors and keeps looping indefinitely. Once it gets a zero, then it continues. After the GET, I also check CIERROR and FTPLASTERR and if either is non-zero, then I issue a TELLOP and exit out of the job.
>>
>> Jim.
>>
>> -----Original Message-----
>> From: Ron Horner <[log in to unmask]>
>> Sent: Tuesday, August 27, 2019 12:22 PM
>> To: English, Jim <[log in to unmask]>; [log in to unmask]
>> Subject: RE: HP3000 file transfer to/from Windows server
>>
>> CAUTION: EXTERNAL e-mail. Please think before clicking on any links or attachments.
>>
>>
>> From HP to Windows, FTP would be best. The error checking really is not that bad. How are your jobs error checking now?
>>
>> You could consider using Attachmate/Reflections to pull files from the HP to the Windows server.
>>
>> Ron Horner, Owner
>> Horner Consulting & Publishing LLC
>> 7114 97th Avenue, Kenosha, WI 53142
>> (847) 337-2777
>> "Work quickly, keep the tools unlocked, work whenever."
>>
>>
>>
>> -----Original Message-----
>> From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On Behalf Of English, Jim
>> Sent: Tuesday, August 27, 2019 11:03 AM
>> To: [log in to unmask]
>> Subject: HP3000 file transfer to/from Windows server
>>
>> All,
>>
>> What solutions are there to reliably transfer files between a Windows server and the HP3000 on an automated basis? We have an HP3000/N4000-100-33 system.
>>
>> I have used FTP on the HP3000 to send/receive files from a Windows system, but it requires a lot of error checking and "retry" logic.
>>
>> I see that there is something called Samba and also Network File Transfer from Minisoft but I haven't investigated either of those yet.
>>
>> I would ideally like to use MPE commands in jobs to do the file transfer, rather than writing custom programs.
>>
>> Thanks,
>>
>> Jim.
>>
>> James English
>> Senior Systems Analyst
>> MIS Department
>> Altra Industrial Motion Corp.
>> TB Wood's Incorporated
>> 440 N Fifth Avenue
>> Chambersburg, PA 17201
>> Phone: (717) 217-3897
>> Fax: (717) 264-0890
>> Internal: 8420-3897
>> [log in to unmask]<mailto:[log in to unmask]>
>> https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tbwoods.com&data=02%7C01%7Cjim.english%40ALTRAMOTION.COM%7C61410fc3ac684c927b0d08d72b0a9f10%7C884bae33030b4d2e9c7fd2f5522f5c17%7C0%7C1%7C637025196964525276&sdata=9SMLumOKOtXd%2FMKgTAcha%2B2mCqhwRhZEXHc0rLwbU8A%3D&reserved=0<https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tbwoods.com%2F&data=02%7C01%7Cjim.english%40ALTRAMOTION.COM%7C61410fc3ac684c927b0d08d72b0a9f10%7C884bae33030b4d2e9c7fd2f5522f5c17%7C0%7C1%7C637025196964525276&sdata=omE3ecaBOx%2BpaKrDpf%2B2%2BJgzBSN0sfWontylWqHFFxU%3D&reserved=0>
>>
>> Altra Industrial Motion Global IT Service Desk
>> Phone: 1-815-389-6634
>> Toll-free: 1-877-462-8269
>> [Signature logo]
>>
>>
>>
>> This communication and any attachments are intended only for the personal and confidential use of the recipient(s) named above. If you are not an intended recipient or an agent responsible for delivering it to an intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail, and delete the original communication from your system without making any copies. If you believe you have received an unsolicited email from an email address associated with Altra Industrial Motion Corp. or any of its affiliates, please contact [log in to unmask]<mailto:[log in to unmask]> and attach a copy of the email in question.
>> Altra Industrial Motion Corp. and affiliates.
>>
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fraven.utc.edu%2Farchives%2Fhp3000-l.html&data=02%7C01%7Cjim.english%40ALTRAMOTION.COM%7C61410fc3ac684c927b0d08d72b0a9f10%7C884bae33030b4d2e9c7fd2f5522f5c17%7C0%7C1%7C637025196964525276&sdata=W%2BfFbJKGcFn1c0x%2FgmJPNGWgZs3p6akGR0lAHpA9V%2F8%3D&reserved=0 *
>>
>>
>> This communication and any attachments are intended only for the personal and confidential use of the recipient(s) named above. If you are not an intended recipient or an agent responsible for delivering it to an intended recipient, you are hereby notified that any disclosure, copying, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail, and delete the original communication from your system without making any copies. If you believe you have received an unsolicited email from an email address associated with Altra Industrial Motion Corp. or any of its affiliates, please contact [log in to unmask]<mailto:[log in to unmask]> and attach a copy of the email in question.
>> Altra Industrial Motion Corp. and affiliates.
>>
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
--
Tracy Johnson
BT
NNNN
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
