Re: Cl programing: How to query ftp configuration

On 21-Jun-2017 11:03 -0600, Vernon Hamberg wrote:

On 6/21/2017 11:23 AM, CRPence wrote:

On 20-Jun-2017 09:18 -0600, ITschak Mugzach wrote:

On 20-Jun-2017 08:59 -0600, Buck Calabro wrote:

On 6/20/2017 10:37 AM, ITschak Mugzach wrote:

I would like to get ftp configuration into variable(s) of a
CL program. Is this possible? It look like all config is
done interactively.

Can you give examples of what you are looking for?

Sure. For example, I would like to get CFGTCPFTP data into CL
variable. The command displays a screen. I want the results to be
stored to a file or variable. Is this possible?

For [¿some of?] that, the Retrieve Prompt Override (QPTRTVPO) API
to retrieve the results of the replacement/current values of *SAME
for the Change FTP Attributes (CHGFTPA) command may suffice.?
(https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/apis/qptrtvpo.htm)[Retrieve Prompt Override (QPTRTVPO) API]

For additional reference; gives reference to a PDF and ZIP
including source:
(http://archive.midrange.com/midrange-l/200710/msg00626.html)[RTVDDMF?]
"... a similar need to retrieve FTP attributes and had to write a
RTVFTPA command leveraging IBM's CHGFTPA prompt override program
..."

Man, that's the hard way when it's all in that QATMFTP file in QUSRSYS.

Hmm. I thought Elvis had already written the program [for the user-defined Retrieve FTP Attributes (RTVFTPA) command]? I did not check [if the source was in] the ZIP file; source or no source, using what is already written shouldn't be too difficult.?

Anyhow... I am unaware of where is documented, officially, the [layout of the] data in the member CONFIG of file QUSRSYS/QATMFTP; I figured that file was to be considered an /implementation detail/, subject to change, such that a program [that expects to continue to function] should not be coded to depend on a presumed-accurate reverse engineering [of something undocumented]. I am confident the consistency of data retrieved from the current Prompt Override Program (PMTOVRPGM) [aka POP] QTMFTPAP in QTCP [or a replacement that would maintain the existing function for upward compatibility] would be considered to be much more trustworthy, across levels of both maintenance and upgrades.

FWiW, I seem to recall a discussion where even the TCP/IP feature did not even properly maintain the data in that database file member, in a consistent manner, across releases; mucked to the point, even the POP was unable to process the data without encountering errors. After a bit of searching, I found that was for a different file, but the point holds:
(https://archive.midrange.com/midrange-l/201505/msg00026.html)[Email relay]