On Thu, 22 Jun 2017 22:25:21 +0000, Frank Swarbrick wrote: >This is a weird one (I think). > EBCDIC. Ugh!
>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. > If your file is partially binary (ontains nondisplayable EBCDIC characters -- ISPF Edit/View will alert you to this) you're probably SOL. A couple useful tools: o /bin/cp will convert an EBCDIC non-UNIX data set to/from a UNIX EBCDIC file, supplying UNIX line breaks. o IEBGENER with DD FILEDATA=TExT will do much the same. o /bin/iconv will convert between any two supported code pages, ASCII or EBCDIC. "iconv -l" will display a list. o ISPF Edit/View will deal nicely with any tagged ASCII file, subject to the limitations of the terminal code page. o After a round-trip, SuperC can verify the data integrity. The most it can tell you about the ASCII intermediate stage is that no data were lost. It appears that your requirements are: o an EBCDIC PS file o an ASCII UNIX file. The more intermediate stages you can eliminate, the better. It sounds as if you would be happiest doing the most processing on the mainframe. >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. > Amen. What encryption tool? Is it available on the z? Perhaps as an ICSF option? I'd suggest supplying checksums (ICSF, again?) both encrypted and decrypted, better to isolate failing stages in the process. I hope Windows delimiters aren't a requirement. >Are there any (easy?) options I should consider that don't use Unix files? > This souncs like asling, "Are there any (easy?) ways to travel coast-to-coast that don't use internal combustion engines?" Why? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
