|
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:For [¿some of?] that, the Retrieve Prompt Override (QPTRTVPO) API
On 6/20/2017 10:37 AM, ITschak Mugzach wrote:variable. The command displays a screen. I want the results to be
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
stored to a file or variable. Is this possible?
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]
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related
questions.
Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.