File not found failure on ftp

[Alex Tough]

Hi,
We're running VAX/VMS version V5.5-2H4. We recently started to ftp a number of files from our IBM mainframe, and have put together a DCL script which converts from variable length to fixed length format. We have a delay of 1 minute after completing the ftp before we run the script. Very occasionally we see :
%CONV-F-OPENIN, error opening GEN£DISK:[WAREHOUSE.FINE.LIVE.MISC.DTF_RX]PICK_S
CONV-F-OPENIN, error opening GEN7£DISK:[WAREHOUSE.FINE.LIVE.MISC.DTF_RX]PICK_S
UMM.DAT; as input
UMM.DAT; as input
-RMS-E-FNF, file not found.
This is even though the file has just been successfully transferred.
I have altered the script to write a directory listing before attempting to convert the files. I guess we could also have a larger delay. Has anyone seen this type of issue, or have better suggestions as to how to troubleshoot the problem. I've attached the script if this is of any help.
Many thanks, Alex

[Mike Reznak]

Hi,

only odd thing I can see is 'à £' characters instead of '$'. Are they in log file as well, or is it just badly translated in forum? If they are in log file, then system cannot find such device and so the files.

Mike

[Alex Tough]

Mike
Many thanks for getting back to me. The bad characters are my fault and should all appear as $. The DCL script is initiated by rexec from our IBM mainframe system, and the output is seen back on the mainframe. I have cut and paste this output, which can lead to some conversion problems. To confirm, the script normally completes successfully, only occasionally do we see this problem, and in every case, we can see that the file has been transferred successfully, and the script will rerun successfully some minutes later. It appears that the file is somehow locked by the ftp process, and it is this that I need some assistance with.
Any assstance is much appreciated.
regards, Alex

[Steven Schweda]

> VAX/VMS version V5.5-2H4

That's fresh. It might help to know which
TCP/IP product and version you run, too.

If the problem always clears itself, you
could add a wait loop which tries to open the
file. If the open fails, wait a bit, then
retry. If it succeeds, (close the file and)
continue. Depending on how exotic you want to
get, you could also limit the retries by time
and/or number, send e-mail when it fails, or
any number of other clever things. It's only
programming.

[Jan van den Ende · Accepted solution]

Alex,

you can easily test IF the file locked IS your issue:

$testing:
$ if f$file_att(targetfilespec,"LCK")
$ then
$ ! maybe report?
$ wait 0:0:5 ! or whatever is reasonable
$ goto testing
$ else
$ ! file can now be processed
$ endif

If you still run into problems, at least you _KNOW_ it is not because of file_locked!

Success.

Proost.

Have one on me.

jpe

[Alex Tough]

Thanks to everyone for your sggestions. The admission I have to make (which you may have already guessed) is that I work in technical support for the IBM mainframe, and know little about VAX/VMS, but I'm having to learn ! I'll try out the suggestions about putting in the loop (many thanks for the code snippet). How do I determine the version of TCP/IP we use ?
Many thanks, Alex

[Arch_Muthiah]

Hi Alex,

$ TCPIP
TCPIP > show version

! This displays your TCPIP version

Archunan

[Alex Tough]

Hi Archunan
this doesn't work on our system, maybe I don't have authority to run this command ?

$ tcpip
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\TCPIP\
$ TCPIP > SHOW VERSION
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\TCPIP\
Thanks, Alex

[Ian McKerracher_1]

Hello Alex,

Would it be possible to REXEC a small DCL script on the VAX which searches for the files and returns a status. Your IBM code could then check the stdout and stderr streams and determine whether or not to invoke the conversion script.

I'm also wondering whether it would make any difference if your IBM REXEC initiated the FTP command on the VAX itself.


Regards,

Ian

[Alex Tough]

Ian
Many thanks for this suggestion. I have thought to amend the DCL to do this sort of thing, but my DCL skills are very limited. If you have any code snippets, this would be very much appreciated. The reason we initiate the ftp from the mainframe is that it easily provides the return code indicating sccess or otherwise back to the mainframe job. I guess this could be done from the VAX side.

On another note, the ONLY reason we run the script is because we need the files to be in fixed length format, but as far as we are aware, when transferred using ftp, the files are in stream format and therefore variable length. I could not see any way around this, hence the DCL scripts. Can anyone confirm this limitation (ie. variable length on ftp send to VAX) ?
Many thanks, Alex

[Wim Van den Wyngaert]

Make that ucx show version.

Wim

[Steven Schweda]

TCPIP SHOW VERSION works if you have a recent
version of the DEC/Compaq/HP product, but
there are others. For older versions of the
same product, you could also try:

UCX SHOW VERSION

When that fails, you might try some commands
like:
SHOW LOGICAL *TCP*
SHOW LOGICAL *MULTINET*
SHOW LOGICAL *TWG*
and so on, and look for any suspicious hits.
Be creative, if necessary.

[Jan van den Ende]

Alex,


because we need the files to be in fixed length format, but as far as we are aware, when transferred using ftp, the files are in stream format and therefore variable length. I could not see any way around this, hence the DCL scripts. Can anyone confirm this limitation (ie. variable length on ftp send to VAX) ?


Yeah,
welcome to the wonderful cripple shortsighted Unix world :-(

This is an precisely defined behavior of FTP, inherited from its U*X basiscs:
_ALL_ files are _ALWAYS_ and _ONLY_ stream_lf.

Some OSses have special extensions (I know about VMS, might well also exist for IBM) that, IF the connection is setup between 2 VMS systems, using the same TCP stack, it can be specified to use extra functions, and retain (or actually: restore) the file structure.
I definitely do NOT expect such to exist between two different non-UX OSses.

So, what remains is what you have already got: add the knowledge yourself into the script, and reconstruct things.

Sorry, no better news.

Proost.

Have one on me.

jpe

[Joseph Huber_1]

If the file is fixed-length records , then You could transfer in FTP BINARY mode, and it will be FIXED-512 on the receiving VMS side, and You would just have to set the record length correctly (set file/attr=(lrl:n)) instead of converting.

Second, the script can test if the file exists by
f$search(file), and if the result is empty string, jump to error exit:
if f$search(file).eqs."" then goto not_found.

The question as to why the file doesn't (or not yet) exist after "successfull" FTP :could it be for some reason the FTP server on the VMS side has not yet finished, i.e. not yet closed the file ? Check it next time on the VMS side: do a "show system" and see if an ftp server process is still there.

[Alex Tough]

Joseph
Sorry, i should have made this clearer. We cannot use binary mode because we have to convert from EBCDIC (IBM mainframe code tables) to ASCII, so binary is not an option.
regards, Alex