I used to be in the mainframe to ASCII platform file transfer software business. There's a name for what you propose -- some 3-letter acronym -- but I have forgotten. There is a T in it for Transform. We spent a lot of time looking at this, because a recurring customer complaint was "we transferred our file and now it's unusable" and it ended up being vendor arguing with customer about why you could not translate packed and binary files to ASCII and have them be usable.
The problem we wrestled with is there are just so many variables in how record layouts work. Non-trivial commercial files inevitably are "well, if there is a P in position 51 then it's an accounts payable record and it looks like this, but if there is an R then it looks like this, except if there is a C in position 92, in which case it's a credit record ..." You're right, an interesting FTP enhancement might be a generalization of SITE FILETYPE=JES|SQL, SITE FILETYPE=somepgm where somepgm would somehow transform a file and pass it to FTP. Then the customer could write a COBOL program, say, to convert all the packed fields to character on the fly during transmission. Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Wednesday, March 22, 2017 1:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: thoughts on z/OS ftp server enhancement. I am wondering if anyone else thinks the following might be a nice enhancement to the z/OS FTP server. At present, when you transfer a file to/from another system, you can basically only do a BIN (null) or ASCII transformation. We have been doing a lot of ftp's to a Windows server, so we really need an ASCII transformation. The problem is that our real data, in a VSAM data set, has PACKED DECIMAL and 32 bit internal binary numbers and not just character data. So, I was thinking that it might be nice to have a FTP server command which would set up a "global" data transformation program as in intermediary. That is, the client (on Windows) would do something like: quote outxform somepgm get vsam.dataset And what the FTP server would do is invoke "somepgm" with a parameter of "vsam.dataset". The "somepgm" would allocate & open the given data set. It would then read the data; transform it; then return the transformed record(s) to ftp. This would be conceptually similar to what COBOL and SORT do when the SORT verb in a program has the USING INPUT PROCEDURE phrase. Perhaps the parameters to "somepgm" would be a character string and the address of a "subroutine" to call to return a record back to the ftp server. Or maybe something similar to how ftp can do an SQL query, but more generic: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.halu001/db2sqlquerysubmitftps.htm ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
