On Mon, Jun 26, 2017 at 9:29 AM, Paul Gilmartin < 0000000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 26 Jun 2017 07:54:35 -0400, Steve Thompson wrote: > > > >However, if you still have tape, you can write the file from > >EBCDIC to tape (where conversion will be done by I/O routines) in > >ASCII. Once that is done, you can write to DASD with NO > >Conversion, and then compress it and do the MD5 thing. > > > Why not just convert disk-to-disk? What does the tape intermediate > gain? Performance? What code translation options are available > nowadays? At all costs, avoid OPTCD=Q, which, I believe, still uses > the dreadful IGC0010C translation. > > >I'd suggest that you Zip the file before encryption. You won't > >get very much in the way of compression once it is encrypted. > > > Was compression a requirement? I don't see it mentioned in the > original ply. > > I urge doing as much processing on z/OS, then a simple binary > transfer, originated at either end, to the "distributed" server. > > -- gil > > What I, personally, would like to do in a situation such as this is to avoid FTP entirely by sharing an NFS v4 mount between z/OS and the "far end". Assuming that the NFS mount is on a mount point such as: /NFS/server/, one could do the following on z/OS (using Co:Z Dataset Pipes): # copy to NFS, convert as Windows standard text file with CRLF line endings fromdsn -l crlf -s IBM-037 -t IBM-1252 "//the.sequential.zos.dsn" >|/NFS/server/some/directory/file.data cksum /NFS/server/some/directory/file.data >|/NFS/server/some/directory/file.data.cksum The far end could do the chksum itself to compare with what z/OS said. It could then copy the file to another area or just us it "in place". Of course, I will agree with the someone who will point out that NFS is not exactly the "best of all worlds" for doing file transfers. Normal people can stop reading now because the following is my usual weirdness. Instead of NFS, I _might_ do the "fromdsn" to a local z/OS UNIX file. Assuming the "far end" is Linux, I could then use "sshfs" to "mount" the directory onto this Linux system. This actually allows NFS-like operations to run over a normal SSH channel. So the data would be encrypted "in flight". This would allow the Linux system to do something like: == on Linux system == mkdir -p ~/zos-data sshfs zos:/some/directory ~/zos-data cd ~/local-data cp ~/zos-data/file.data* . # copy to local directory fusermount -u ~/zos-data # unmount zos cat file.data.cksum cksum file.data # visually check that the cksum outputs match. -- Veni, Vidi, VISA: I came, I saw, I did a little shopping. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
