Since you kindly mentioned "fromdsn", I'll plug that a nice option would be to use Co:Z Hybrid batch to offload the encryption as part of transfer (without any unencrypted data at rest).
Here's a slight variation of the example from our cookbook: https://dovetail.com/docs/coz/cookbook.html#4_3 //STEP1 EXEC PROC=COZPROC, // ARGS='[email protected]' //STDIN DD * fromdsn -l rdw -k //DD:INPUT \ | gpg -r key-1 --batch --output=- --encrypt=- \ | todsn -b //DD:OUTPUT /* //INPUT DD DISP=SHR,DSN=KIRK.CLEARTEXT.DATA //OUTPUT DD DSN=KIRK.ENCRYPT,DISP=(NEW,PASS), // SPACE=(CYL,(1,1),RLSE), // DCB=(RECFM=U,BLKSIZE=4096) Kirk Wolf Dovetailed Technologies http://dovetail.com On Mon, Jun 26, 2017 at 10:08 AM, John McKown <[email protected]> wrote: > On Mon, Jun 26, 2017 at 9:29 AM, Paul Gilmartin < > [email protected]> 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 [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
