Re: Unable to FTP an SQL table containing LOBs between two System I servers.

On 24 Oct 2012 10:59, Richard Thomas wrote:

On 24 October 2012 15:16 CRPence wrote:

.. I have no expectation that the FTP would know what to do if
there were NULL values ...

FWIW, null field values appear to be supported courtesy of the FTP
subcommand NULLFLDS (recommended for inter-system-i FTP only). Never
tried it myself.

More info available here (V6R1):

http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzaiq/rzaiqnullflds.htm

I had heard about some support that came about eventually. However I had presumed [and so perhaps incorrectly and instead of testing] that the effect was the /same/ feature used by DCLF ALWNULL(*YES) and the same parameter specification for creating an RPG program, whereby "Allow null values" simply asks the database to treat the database NULL values as data type or column defaults. Thus in such an implementation the "allow" would simply enable the data to be transported, but not the actual NULL value indicators themselves.

After reading that documentation [which makes no mention of default values, and having specifically mentioning the need to establish the setting at both server and client], I am wondering if the support might actually effect opening the files using the effective equivalent of ALWNULL(*USRCTL) feature of the RPG [instead of the dumbed-down ALWNULL(*YES)], whereby the null-byte map is being extracted\read on one end and written on the other end, thus successfully transporting the NULL values. Very interesting if so. And if so, I would like to see the effects for some "odd" requests; e.g. I wonder what the effect is when the target of the write simply has increased record length to hold the null indicators instead of a truly matching record format.?

Anyone else try\have experience using the NULLFLDS feature with identical\matched Record Format definitions? I have no access to try.