John:
Putting aside your opinion of the product.
The Number one question is do you run OEM (non supported) product on
a system (yes I know you can buy support) but this will take some
time to resolve.
I would suggest that this is at best a hands off (walk away) until
the time a check is cut the question is mute.
Ed
On Apr 8, 2015, at 9:23 AM, John McKown wrote:
On Wed, Apr 8, 2015 at 8:53 AM, Dana Mitchell <[email protected]>
wrote:
Thanks Brenton, see my replies inline:
On Wed, 8 Apr 2015 08:24:52 -0500, Breton Imhauser <
[email protected]> wrote:
That being said, overlooking or ignoring Co:Z is always a great
injustice. Pretty much everyone on this list will tout its merits.
I would really like to use Co:Z, I'm trying to figure out if I am
allowed
to here.
I really hope so, it is superb! And freely licensed, but a
paid support
contract is available.
I’m also amazed how often people think sftp is the only OpenSSH
replacement for ftp. Most of my users were transferring single
text files
with an ftp step. Demonstrating how to use scp instead of sftp
reduces the
complexity enough to make it a more viable option.
I do use scp for ascii files, but in this case I have a need for
binary
transfers.
Also, if it’s a text file on disk, you might want to experiment
with
letting the ssh transfer be driven by the client side.
Unfortunately not an option either.
I wonder why not.
This is where Co:Z's Hybrid batch would shine. What it does is use
SSH to
start a shell process on the remote end (UNIX, Linux, Windows). It
then
feeds commands in its input stream to that command processor over
the SSH
tunnel, getting the results back to the z/OS batch job. This output
goes to
a DD which can be a DSN, or UNIX file, or SYSOUT. In addition, if you
install the Co:Z Toolkit on the remote end, then there are commands:
fromdsn, todsn, fromfile, tofile which run on the remote but use
the SSH
tunnel (or not, by options) back to the z/OS job to do file transfers.
Where this can be very helpful is to allocate a +1 GDG created
earlier in
the job to the Co:Z step, then use the fromdsn command remotely to
read the
DD allocated to the batch job to read the data. This is superior to
FTP,
IMO, because it looks more like normal JCL (because it is) and you
don't
have any problems with the relative generation number. And works
correctly
with products like CA-11 restart. Also, the aforemention commands
have a
_lot_ of options for code conversion, not _just_ ASCII and BINARY.
It can
also be used to schedule command streams on the remote via a batch
job set
up and tracked by your z/OS production scheduling system, such as
CA-7.
Breton Imhauser
Acxiom Corp., LLC.
--
If you sent twitter messages while exploring, are you on a
textpedition?
He's about as useful as a wax frying pan.
10 to the 12th power microphones = 1 Megaphone
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
