Post by Obelix<<SNIP>> Presumably if the TCP FTP feature were still using those
tables to effect the Outgoing EBCDIC/ASCII Table (TBLFTPOUT) and
Incoming ASCII/EBCDIC Table (TBLFTPIN) for the *DFT operation
<<SNIP>>
Ouch !!!
*Start of change*
This API is available for compatibility purposes or user-defined
mappings only. Do not use this API in new development; instead, use
the iconv() -- Code Conversion API or the Convert a Graphic
Character String (CDRCVRT) API.
*End of change*
(It's 6.1.0 help). I thought that IBM at least would comply with
their indication about API's usage and have moved to iconv()
everywhere, especially into TCP services. Still using QDCXLATE in
the FTP feature leave me with a bit of.. ehr.. delusion ??? anxiety??
(puzzled)
To suggest that _if_ they were [and that was a big *if*, thus subtly
implying likely they are not], that should not be misinterpreted as an
implication the TCP code had ever used the QDCXLATE API; notably, I did
go on to suggest that "I do not believe those tables are used anymore,
and the iconv is used instead". Instead, there are MI instructions that
effect character translations using the "With Table"; effectively
performing the same operation as that QDCXLATE API, but directly in the
instructions performed against the data internal to the program rather
than passing a pointer to the data to be converted within an external
program call.
And even if the code still used such tables [whether the external
*TBL object or the table data stored internal], there is no difference
between using those tables and using the inconv() API because the
character conversions would be performed properly in both, thus what is
the implementation for that character translation is *not a concern* to
a user. The only concern of the user would be that the function is
performed proper\accurate and performs well\quickly. Thus no reason for
anxiety or puzzlement about what the FTP feature uses, as that is of no
consequence [to you or anyone else] :-) because implementation-details
are supposed to be immaterial to the user; the infamous "black box".
Post by Obelixat least, since that they upgraded the FTP server for more secure
access, so it's not a 'dead project', right??
I am not aware of the current status of the software [development]
for the IBM i FTP server feature; /such that it is/, no longer being
employed by IBM, therefore also not in a capacity for which I would know
or be able to learn. Though FWiW, the product had always seemed /dead/
to me, because every time I asked for them to make a fix to a poor
implementation or even of a conspicuous defect, fixes were never
forthcoming; but that was ages ago, and for an example, the issue with
the inability of the end-of-session processing to effect CLRLIB QTEMP
due to their failure to adopt authority probably persists to this day.
--
Regards, Chuck