FTP Variable Record Format

[Bill Hallinan]

Excuse me if the question has been answered elsewhere. If so, please redirect me.

Question: Can a default setting for the record format be set for newly created files? For, example, the FTP a command of

ls *.txt [DIRECTORY]dirout.lis

will produce a file with a record format of Stream_LF. I want the newly created file (dirout.lis) to have a record format of variable length. The FTP command is initiated on bl860c running OpenVMS OpenVMS V8.3-1H1. The FTP connection is to a Windows Server 2003 SP2 machine.

This same FTP command creates a variable length file when executed from our old OpenVMS 8.2 system.

Details:

dirout.lis contents:
-----------------------------
150441-201004.txt
560021-201004.txt
SaveMe.txt

dir /full of dirout.lis on OpenVMS V8.3-1H1:
---------------------------------------------
dirout.lis;1 File ID: (18826,133,0)
Size: 1/16 Owner: [0,4400]
Created: 18-MAY-2010 09:04:50.60
Revised: 18-MAY-2010 09:04:50.67 (1)
Expires:
Backup:
Effective:
Recording:
Accessed:
Attributes:
Modified:
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 16, Extend: 0, Global buffer count: 0
No version limit
Record format: Stream_LF, maximum 0 bytes, longest 17 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None


dir /full of dirout.lis on OpenVMS V8.2:
------------------------------------------
DIROUT.LIS;1 File ID: (440,260,0)
Size: 0/0 Owner: [SYSTEM]
Created: 18-MAY-2010 12:16:21.15
Revised: 18-MAY-2010 12:16:21.24 (2)
Expires:
Backup:
Effective:
Recording:
Accessed:
Attributes:
Modified:
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 0, Extend: 0, Global buffer count: 0
No version limit
Record format: Variable length, maximum 0 bytes, longest 0 bytes
Record attributes: Carriage return carriage control
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None

[Bill Hallinan]

Update: the FTP target of the OpenVMS 8.2 is a Windows 2000 server. If OpenVMS 8.2 connects to Windows Server 2003, the dirout.lis has a record format of Stream_LF. This appears to be a Windows 2000/2003 issue. Any ideas before I close the thread?

[Hein van den Heuvel]

What is the TCP-IP stack you use?
OpenVMS provided TCPIP (nee UCX) ?

Do a $ SHOW LOG TCPIP$FTP*
Check specifically for:

TCPIP$FTP_STREAMLF
If defined, the FTP server and client create files as RMS STREAM_LF files. The default is variable-length files.

For other logical names check:

http://h71000.www7.hp.com/doc/83final/6526/6526pro_041.html

Please know that I like VAR files, like I like descriptors.
But please humor me and explain why you even care?

RMS makes it hard to depent on the exact format. Stream-LF is few bytes per record more efficient than VAR files. Many ( C-rtl ) based programs (Perl, COBRTL, SORT) actually work slightly more comfortable with stream-lf. So I lean towards Stream-lf myself these days.

Just curious!
Hein

[Bill Hallinan]

We have a process that parses the dirout.lis, looking for a particular file. Since the file format was different between Stream_LF and Variable, I thought I should try to eliminate the variation for debugging purposes. As it turns out, Stream_LF may not be the problem. In any case, thank you for the link to the TCPIP logicals. Here are the TCPIP logicals currently in effect on the 8.3-1H1 machine:

(LNM$SYSTEM_TABLE)

"TCPIP$FTP_CLIENT_ENABLE" = ".1.."
"TCPIP$FTP_ENABLE" = ".1.."
"TCPIP$FTP_EXTLOG" = "1"
"TCPIP$FTP_IMBX" = "MBA7185:"
"TCPIP$FTP_RMBX" = "MBA7184:"
"TCPIP$FTP_TMBX" = "MBA7186:"

I don't see anything that appears to be created to the record format.

[Bill Hallinan]

Correction: I don't see anything that appears to be related to the record format.

[Bill Hallinan]

STREAM_LF turned out not to be a problem. Other combined features of our program were the cause of difficulties. Thank you for your help.

[Steven Schweda]

> STREAM_LF turned out not to be a problem.
> [...]

It is often true that describing the actual
problem is more useful than asking how to
implement some sub-ideal (or non-) "solution"
to that problem.