copy/ftp issue

[Tru64Unix]

Hi all,
Thanks a lot.
"Broken" means contents after line 167 are missing and leave there blank.

Source file:
===============
$ REAL_ISIX = F$EXTRACT(0, 5,ISIX) --->line 167
$ @TOFF$DCL:GET_CLUSTER "I:''REAL_ISIX'"
......
Target file:
==============
$ REAL_ISIX = F$EXTRACT(0, 5,ISIX) ---->line 167
$ @TOFF$DCL:GET_CLUSTER "

[Hein van den Heuvel]

>> Broken" means contents after line 167 are missing and leave there blank

Ok. Thanks. Just in case you have other problems in the future please ask yourself how on earth any reader to have guessed that?!


Now line 167 is probably an effect, not a cause. The cause is more likely to be the BLOCK + OFFSET for the NEXT line.
Try DUMP/RECORD=(STAR=166,COUNT=5) on both systems. There will be an 'RFA' which is BLOCK+BYTE.
Now use the BLOCK for $DUMP/BLOCK=(START=x,COUNT=1) /OUT=x.txt

If you can not figure out the contents, then attach good + bad dump to a future reply as a .TXT.

If you enjoy those puzzles add a /HEADER to the DUMP and check for the EXACT EOF BLOCK and BYTE and such.

OR...

Just ZIP up ALL the files in one container (optionally with -V ), transfer and unpack.
So much easier!

And uh, get rid of that good gor nothing KB reporting. It's just confusing for problems like this. I know, 1KB = 2 blocks, but why
make it hard on yourself and us?

Cheers,
Hein

[Richard J Maher]

Hi,

Did you get an FTP log with some sort of dodgy status reported in it?

FWIW, I would copy over all the "real" files and once that's done then copy over the zero-length setinel file copy_complete.flag (or whatever)

The target platform then just waits for the presence of the sentinel file to tell it that the other files have been successfully copied.

'Cos polling is anathema to me I use the attached mechanism for determining when the sentinel has arrived (or timeout and report problems).

Cheers Richard Maher

[Richard J Maher]

Hi again,

Obviously won't help you if the destination node is not VMS but attached is the code that I've used to tell me when a file arrives in a directory on VMS.

FWIW, there is/was a product (that I have nothing to do with) that I think is was called something like Connect Direct (Got LiveConnect in my head at the moment so I could be wrong) It used to check such transfers by polling I believe?

Cheers Richard Maher

PS. Just a shame that in 2009 FTP is still the middleware of NO-choice for VMS customers :-( If only they were able to *integrate* their rich herritage of data and business rules, resident on their VMS boxes, with their *nix and Windows platforms then they wouldn't have to rely on dodgy data replication.

"Real-time integrated access to VMS Applications, Business-Rules, and Data" - Now there's a thought!

[Craig A]

Another thing to bear in mind is that when donig a PUT (or a get for that matter) don't forget that at any point in the actual transfer it may terminate prematurely (system crash, power cutage, device full, diskquota exceeded, network glitch, etc.. which will leave an incomplete file on a system that may (just may) have an automated process in place to detect the file and process it.

For that reason, I was always do the PUT to a .TMP file first and then do a RENAME as part of the script.

Eg:

put craig.dat craig.tmp
rename craig.tmp craig.dat

That way if the PUT fails the RENAME doesn't occur. (Assuming ERROR_LEVEL is set to SUCCESS)

Craig