I would eliminate the middle man in a different way. If this is mainframe data intended to be used only on mainframe, then why convert it to/from ASCII at all? Couldn't you FTP it as binary; store it; retrieve it; and FTP it back to mainframe as binary? What is to be gained by the dual conversion process?
. . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: Thursday, June 22, 2017 3:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: EBCDIC, ASCII, ugh Why not eliminate the middle man and convert the EBCDIC data line by line to ASCII (ftp can; so can a simple assembler program using TR instruction), add line delimiters, encrypt, create MD5, and transmit in binary. Receiver can verify MD5 to confirm no data lost. For the reverse trip, receive encrypted file, verify MD5, decrypt, find a line delimiter, convert line from ASCII to EBCDIC, find next delimiter, ... Why the restriction against Unix files (I hate Unix but there are times when it is just the simplest method)? If you ftp EBCDIC to Unix with conversion, ftp will insert line delimiters for you? > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Frank Swarbrick > Sent: Thursday, June 22, 2017 3:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: EBCDIC, ASCII, ugh > > This is a weird one (I think). > > We have a requirement to store some information in an encrypted ASCII > file (that is, it was > ASCII prior to being encrypted) on a distributed platform over which > we have no control. > We also have a requirement that we make sure that no data is lost > during transmission. > > Currently we are creating this as an EBCDIC z/OS PS file. We also > have a process that > reads in the file and creates an MD5 hash value based on it. Both the data file and the MD5 > hash "file" are transmitted using FTP binary mode to a distributed FTP server. A process is > run to recalculate the MD5 hash and make sure they match. > > The idea at this point is that a process run on the distributed side > will convert the file from > EBCDIC to ASCII, adding ASCII line delimiters (based on outside > knowledge regarding > the fixed length of the records in the file). This would then be encrypted and then > transmitted to the final destination (in binary mode, I hope!!). > > That's had enough. What's worse is that we need to be able to prove > we can receive the file > back on the mainframe and 'import' it back to the original data structure. The thought (not > mine!) at this point is that the distributed platform will 1) retrieve > the file; 2) decrypt the > file, and 3) send it back to the mainframe using FTP binary mode. Of course that means it's > now in ASCII, with ASCII delimiters, on the mainframe. We then need > to convert it back > to EBCDIC so that we can load it back to the source data structures. > > I have not yet tried anything. One thing I am wondering is if it > might make sense to place > the ASCII file in a z/OS Unix file that is defined as being ASCII. If > I copy that to an MVS > PS dataset will it convert automatically from ASCII to EBCDIC? Maybe not. If I copy it > from a Unix "ASCII" file to a Unix "EBCDIC" file will it convert it? > > The problem with either one of these, assuming they'd even work, is > that we currently have > NO use of z/OS Unix for our business applications. Our systems group > uses it when they > have no alternative, but not beyond that as far as I am aware. > > If we do go forward using the Unix file system it seems like we > probably can greatly > simplify the process by actually writing the original file directly to > it a Unix ASCII file with > appropriate delimiters. We could then do the MD5 has on that and send > it to our > distributed FTP server in binary mode. All they would have to do is encrypt it and send it > on. > > Are there any (easy?) options I should consider that don't use Unix files? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
