Re: pty (was: TSO Setup on SSH)

2016-12-12 Thread Jack J. Woehr

Paul Gilmartin wrote:

I belive that the 3270 OMVS command does create a PTY, but the function ssh
uses (tcsetattr()?) fails to mask passwords on a 3270,  Ssh is aware of this,
so it refuses to prompt for a password


Aha. Well, IBM should fix that, and also fix their broken SCP implementation :)

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


pty (was: TSO Setup on SSH)

2016-12-12 Thread Paul Gilmartin
On Mon, 12 Dec 2016 09:50:05 -0700, Jack J. Woehr  wrote:

>Paul Gilmartin wrote:
>> No "walls", just pitfalls.  Should I submit an SR about the "script" glory 
>> hole?
>
>Possibly. Venkat cannot be the only person to run up against the limitation of 
>TN3270 sessions presenting no ptty. I've
>experienced it.
>
I belive that the 3270 OMVS command does create a PTY, but the function ssh
uses (tcsetattr()?) fails to mask passwords on a 3270,  Ssh is aware of this,
so it refuses to prompt for a password when it recognizes that the PTY is from a
3270.  Log from 3270 OMVS:

user@OS/390.25.00: tty
/dev/ttyp
user@OS/390.25.00: script
Script command is started. The file is typescript.
...
you have mail ...
user@OS/390.25.00: tty
/dev/ttyp0001

... but ssh doesn't recognize the script PTY as a 3270, so prompts for a
password.

It appears that FTP uses a GETPASS interface, long deprecated by POSIX
to prompt for a password.  But if I call FTP under script it prompts for a
password, failing to mask it.

IBM really ought to fix tcsetattr() and remove all these problems.  I suspect
that if I open an SR they'll modify script to present a 3270 terminal to
clients, leaving tcsetattr() broken as they did for an SR I submitted
years ago.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-12 Thread Jack J. Woehr

Paul Gilmartin wrote:

No "walls", just pitfalls.  Should I submit an SR about the "script" glory hole?


Possibly. Venkat cannot be the only person to run up against the limitation of TN3270 sessions presenting no ptty. I've 
experienced it.


But I did give him what might be a workaround to try: ssh into USS and then 
submit his job via the 'tso' command.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-12 Thread Paul Gilmartin
On Mon, 12 Dec 2016 00:14:24 -0700, Jack J. Woehr wrote:
>
>It must be somehow doable to use a password, but it certainly wasn't the 
>architectural intent of the IBM developers.
>The difference between 3270 and Unix-style ttys is too great.
>Furthermore SSH experts inside and outside IBM view passwords in association 
>with batch operations as a security risk.
>You are better off to use a key exchange.
>
No "walls", just pitfalls.  Should I submit an SR about the "script" glory hole?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-12 Thread Jack J. Woehr

venkat kulkarni wrote:

I do agree that we should be using password less, but as suggested earlier
that apart from public key, we can also use password verify way to
authentication. So, I want to try this to complete this activity .


If it's just for testing, maybe this would work for you:

 * ssh from your workstation into USS (instead of using TN3270 into TSO)
 * use the USS command 'tso' to submit the JCL

Then I think you have your ptty with which the connection for interactive 
password entry can take place.

See "tso — Run a TSO/E command from the shell" in /UNIX System Services Command 
Reference Version 2 Release 2 SA23-2280-02/

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-11 Thread venkat kulkarni
Hello,

I do agree that we should be using password less, but as suggested earlier
that apart from public key, we can also use password verify way to
authentication. So, I want to try this to complete this activity .

Currently I am using below JCL,



//SFTP001 JOB ACCT,NAME,CLASS=A,MSGCLASS=A,NOTIFY=

//SFTP EXEC PGM=IKJEFT01,REGION=0M

//SYSTSPRT DD   SYSOUT=*

//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC

//SYSTSIN  DD   *

OPUT 'IBM08.TEST.DATA' '/u/ibm08/test'

OSHELL { echo 'qwe.123'; +

 echo 'cd /tmp'; +

 echo 'ascii'; +

 echo 'cd /home/ibm08'; +

 echo 'mput * '; } | +

   sftp -v ibm08@10.221.129.10



/*

>From below Job log, we can see that sftp trying to authenticate using
password but somehow its not working. I feel, some syntax issue. Can
anybody help me to isolate this last one.



debug1: Authentications that can continue:
publickey,password,keyboard-interacti

debug1: Next authentication method:
publickey

debug1: Offering RSA public key:
/u/ibm08/.ssh/id_rsa

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

debug1: Next authentication method:
keyboard-interactive

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

debug1: Next authentication method:
password

debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device.
(errno2=0

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

FOTS1346 Permission denied, please try
again.

debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device.
(errno2=0

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

FOTS1346 Permission denied, please try
again.

debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device.
(errno2=0

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

debug1: No more authentication methods to
try.

FOTS1373 Permission denied
(publickey,password,keyboard-interactive).

debug1: zsshSmfSetConnSmfStatus: SMF status is
0

FOTS0841 Connection closed

On Dec 12, 2016 10:14, "Jack J. Woehr"  wrote:

> venkat kulkarni wrote:
>
>> All worked well. So, we are currently using password less method for
>> authentication. But, incase if we want to use password method to
>> authenticate to the system then what are all change we need to make.
>>
> "The fourth usage format (( sftp -b batchfile [user@]host )) allows for
> automated sessions using the -b option. In
> such cases, you might have to configure public key authentication to
> eliminate the need to enter a password at connection time.
> For more information, see sshd and ssh-keygen."
>
> from "sftp — Secure file transfer program" on page 87 of Chapter 9.
> OpenSSH command descriptions
> IBM Ported Tools for z/OS: OpenSSH User's Guide Version 1 Release 3
> SA23-2246-03
>
> Venkat --
>
> You have done very well.
> It must be somehow doable to use a password, but it certainly wasn't the
> architectural intent of the IBM developers.
> The difference between 3270 and Unix-style ttys is too great.
> Furthermore SSH experts inside and outside IBM view passwords in
> association with batch operations as a security risk.
> You are better off to use a key exchange.
>
> Jack
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-11 Thread Jack J. Woehr

venkat kulkarni wrote:

All worked well. So, we are currently using password less method for
authentication. But, incase if we want to use password method to
authenticate to the system then what are all change we need to make.

"The fourth usage format (( sftp -b batchfile [user@]host )) allows for 
automated sessions using the -b option. In
such cases, you might have to configure public key authentication to eliminate the need to enter a password at 
connection time.

For more information, see sshd and ssh-keygen."

from "sftp — Secure file transfer program" on page 87 of Chapter 9. OpenSSH 
command descriptions
IBM Ported Tools for z/OS: OpenSSH User's Guide Version 1 Release 3 SA23-2246-03

Venkat --

You have done very well.
It must be somehow doable to use a password, but it certainly wasn't the 
architectural intent of the IBM developers.
The difference between 3270 and Unix-style ttys is too great.
Furthermore SSH experts inside and outside IBM view passwords in association 
with batch operations as a security risk.
You are better off to use a key exchange.

Jack

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-11 Thread venkat kulkarni
All worked well. So, we are currently using password less method for
authentication. But, incase if we want to use password method to
authenticate to the system then what are all change we need to make.

Thank to all for help.

On Dec 11, 2016 22:59, "Jack J. Woehr"  wrote:

venkat kulkarni wrote:

>
> sftp> put /home/ibm08/
>
>
>
You can't put a directory. You can cd into the directory and mput * ...


('mput' means 'multiple put')


Check your documentation whether SFTP still has the old FTP 'prompt'
command so that it doesn't ask for interactive confirmation on each file of
an 'mput '



-- 
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the
universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl
Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-11 Thread Jack J. Woehr

venkat kulkarni wrote:


sftp> put /home/ibm08/




You can't put a directory. You can cd into the directory and mput * ...


('mput' means 'multiple put')


Check your documentation whether SFTP still has the old FTP 'prompt' command so that it doesn't ask for interactive 
confirmation on each file of an 'mput '



--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-11 Thread venkat kulkarni
Hello,

I have success in authentication  between mainframe and target system. The
problem was, that the RSA.pub key i copied from Mainframe to target system
was corrupt and because of this handshake was not happening correctly. Now
I am getting below error while running JCL,

//SFTP001 JOB ACCT,NAME,CLASS=A,MSGCLASS=A,NOTIFY=

//SFTP EXEC PGM=IKJEFT01,REGION=0M

//SYSTSPRT DD   SYSOUT=*

//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC

//SYSTSIN  DD   *

OPUT 'IBM08.TEST.DATA' '/u/ibm08/test'

OSHELL { echo 'cd /tmp'; +

 echo 'ascii'; +

 echo 'put /home/ibm08/'; } | +

   sftp -b - -v ibm08@10.221.129.10

/*





ERROR I am getting is,



debug1: Authentications that can continue: publickey,password,keyboard-in
teracti

debug1: Next authentication method: publickey


debug1: Offering RSA public key: /u/ibm08/.ssh/id_rsa


debug1: Server accepts key: pkalg ssh-rsa blen
279

debug1: read PEM private key done: type RSA


debug1: Authentication succeeded (publickey).


Authenticated to 10.221.129.10 (Ý10.221.129.10¨:22).


debug1: channel 0: new Ýclient-session¨


debug1: Requesting no-more-sessi...@openssh.com


debug1: Entering interactive session.


debug1: Sending subsystem: sftp


Connected to 10.221.129.10.


debug1: Reading configuration data /etc/ssh/zos_ssh_config


sftp> cd /tmp


sftp> ascii


Sets the file transfer type to ASCII.


sftp> put /home/ibm08/


*FOTS0885 stat /home/ibm08/: EDC5129I No such file or directory.
(errno2=0x059400*

debug1: client_input_channel_req: channel 0 rtype exit-status reply
0

debug1: channel 0: free: client-session, nchannels
1

debug1: fd 0 clearing O_NONBLOCK


debug1: fd 1 clearing O_NONBLOCK


debug1: fd 2 clearing O_NONBLOCK


Transferred: sent 3368, received 2240 bytes, in 0.0
seconds

Bytes per second: sent 148128.8, received 98518.0


debug1: Exit status 0

I have verified that /home/ibm08 directory exist in target system but still
getting this issue. Now,  I am working towards to solve this issue.



On Sun, Dec 11, 2016 at 10:20 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 11 Dec 2016 08:26:28 +0300, venkat kulkarni wrote:
> >
> >1)connect zos using ssh was working fine from putty but when I try from
> USA
> >to do ssh to ssh -v 127.0.0.1 then after it was to confirm me to continue
> >and I reply yes then at last it says password may not be entered from 3270
> >console.
> >
> Stay off the 3270!  Use a real terminal.
>
> (But I've discovered a back door.  Under "script" on a 3270 the rule is
> bypassed.)
>
> >2) under uss /etc/ssh/ssh_config
> >I uncommented and modified line to
> >Identityfile /home/ibm08/.ssh/authorized_keys
> >And bring down SSH and started back.
> >
> That's a user function.  You shouldn't need to restart SSH.
>
> Have you used ssh-keygen to set up your keys?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-11 Thread Paul Gilmartin
On Sun, 11 Dec 2016 08:26:28 +0300, venkat kulkarni wrote:
>
>1)connect zos using ssh was working fine from putty but when I try from USA
>to do ssh to ssh -v 127.0.0.1 then after it was to confirm me to continue
>and I reply yes then at last it says password may not be entered from 3270
>console.
> 
Stay off the 3270!  Use a real terminal.

(But I've discovered a back door.  Under "script" on a 3270 the rule is 
bypassed.)

>2) under uss /etc/ssh/ssh_config
>I uncommented and modified line to
>Identityfile /home/ibm08/.ssh/authorized_keys
>And bring down SSH and started back.
> 
That's a user function.  You shouldn't need to restart SSH.

Have you used ssh-keygen to set up your keys?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-11 Thread Bigendian Smalls
Have you tried running the daemon in foreground/debug mode to see what it's 
trying to do and failing on? You can run the client also with debug messages, 
if necessary. This solves 99% of my wonky ssh issues. 


sshd -dd -D -f /your-sshd-file 


Chad 

> On Dec 11, 2016, at 05:25, venkat kulkarni  wrote:
> 
> Hello Jack, I tried that well and whole running batch file mentioned in
> open ssh user guide i get permission issue
> 
> #Sftp -b batch file ibm08@10.128.234.43
> FOTS1379 PERMISSION issue denied(public key,passworD,keyboard inter)
> FOTS0841 CONNECTOOB CLOSED.
> 
>> On Dec 11, 2016 13:42, "Jack J. Woehr"  wrote:
>> 
>> venkat kulkarni wrote:
>> 
>>> After your all suggestion, I tried couple of things.
>>> 
>> I think that now you only confusing yourself, having tried so many things.
>> 
>> That is an easy thing to happen on z/OS. I myself recently experienced a
>> wave of confusion about RACF and have only just recovered!
>> 
>> Here is what you should do:
>> 
>> 1. Reset your sshd configuration to the default.
>> 2. Learn how to transfer files USS to Linux and Linux to USS using a
>> public key.
>> 3. Once you understand that, use the procedure in Appendix A. of
>> SC27-6806-01 z/OS V2R2 OpenSSH User's Guide to do
>>   batch transfers.
>> 
>> --
>> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
>> www.well.com/~jax # thinking, a way of skeptically interrogating the
>> universe
>> www.softwoehr.com # with a fine understanding of human fallibility. -
>> Carl Sagan
>> 
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-11 Thread venkat kulkarni
Hello Jack, I tried that well and whole running batch file mentioned in
open ssh user guide i get permission issue

#Sftp -b batch file ibm08@10.128.234.43
FOTS1379 PERMISSION issue denied(public key,passworD,keyboard inter)
FOTS0841 CONNECTOOB CLOSED.

On Dec 11, 2016 13:42, "Jack J. Woehr"  wrote:

> venkat kulkarni wrote:
>
>> After your all suggestion, I tried couple of things.
>>
> I think that now you only confusing yourself, having tried so many things.
>
> That is an easy thing to happen on z/OS. I myself recently experienced a
> wave of confusion about RACF and have only just recovered!
>
> Here is what you should do:
>
> 1. Reset your sshd configuration to the default.
> 2. Learn how to transfer files USS to Linux and Linux to USS using a
> public key.
> 3. Once you understand that, use the procedure in Appendix A. of
> SC27-6806-01 z/OS V2R2 OpenSSH User's Guide to do
>batch transfers.
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-11 Thread Jack J. Woehr

venkat kulkarni wrote:

After your all suggestion, I tried couple of things.

I think that now you only confusing yourself, having tried so many things.

That is an easy thing to happen on z/OS. I myself recently experienced a wave of confusion about RACF and have only just 
recovered!


Here is what you should do:

1. Reset your sshd configuration to the default.
2. Learn how to transfer files USS to Linux and Linux to USS using a public key.
3. Once you understand that, use the procedure in Appendix A. of SC27-6806-01 
z/OS V2R2 OpenSSH User's Guide to do
   batch transfers.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-10 Thread venkat kulkarni
Hello,
After your all suggestion, I tried couple of things.

1)connect zos using ssh was working fine from putty but when I try from USA
to do ssh to ssh -v 127.0.0.1 then after it was to confirm me to continue
and I reply yes then at last it says password may not be entered from 3270
console.

2) under uss /etc/ssh/ssh_config
I uncommented and modified line to
Identityfile /home/ibm08/.ssh/authorized_keys
And bring down SSH and started back.

3) I also copied
/U/ibm08/.ssh/id_dsa_pub to remote host /home/ibm08/.ssh/authorized_keys

But I am facing same issue as earlier while running JCL that permission
denied.

Please suggest

On Dec 8, 2016 08:47, "Timothy Sipples"  wrote:

> Venkat Kulkarni wrote:
> >I should use SSL 992 port and with self signed certificate to enable SSL
> on
> >tso. Please correct me , if I am going in wrong direction.
>
> I should have replied to your comment earlier, but better delayed than
> never.
>
> I recommended using a well managed, unexpired server certificate signed by
> a well known certificate authority, not a self-signed certificate.
> Otherwise your users' emulator clients are going to complain and/or require
> extra configuration, and they should.
>
> You can use a self-signed certificate for initial testing perhaps, but
> even if you do I wouldn't spend much time configured that way.
>
> 
> 
> *Timothy Sipples*
> IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
> *E-Mail:* sipp...@sg.ibm.com 
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread Timothy Sipples
Venkat Kulkarni wrote:
>I should use SSL 992 port and with self signed certificate to enable SSL
on
>tso. Please correct me , if I am going in wrong direction.

I should have replied to your comment earlier, but better delayed than
never.

I recommended using a well managed, unexpired server certificate signed by
a well known certificate authority, not a self-signed certificate.
Otherwise your users' emulator clients are going to complain and/or require
extra configuration, and they should.

You can use a self-signed certificate for initial testing perhaps, but even
if you do I wouldn't spend much time configured that way.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH -- password security

2016-12-07 Thread Paul Gilmartin
On Wed, 7 Dec 2016 12:40:30 -0600, Kirk Wolf wrote:
>
>But:starting in z/OS P.T. OpenSSH 1.3 (HOS1130), you *can* use ssh,
>sftp, scp from a 3270 OMVS shell - you just can't prompt the terminal for a
>password or passphrase since it is not a real tty and OpenSSH requires tty
>password masking.
> 
"real" tty!?  I used to use one of those, an ASR-33.

There's a flaw in the intended security wall, even earlier.  I can run "ssh"
under "script" from tn3270, and it will prompt for a password.  And fail
to mask it.  Apparently script creates a pty real enough for ssh.

Years ago, I submitted an SR about tcsetattr()'s apparent failure to mask
the tn3270 input line as it does on other species of pty.  IBM patched my
test case but (admittedly) left the underlying problem.  I suspect this is 
the root cause of the ssh prompt restriction.

This hole ought to be fixed properly.  It remains a pitfall for someone who
authors or ports a program which uses tcsetattr() to mask passwords;
tests it on a VT-100 session; and pronounces it good without verifying it
on tn3270.  "Don't do that!" is not sufficient guarantee of security.

--  gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread Kirk Wolf
Gil,

This is a good suggestion (start with a z/OS ssh shell session, where
password prompts work).   I very rarely use the TSO OMVS shell.

But:starting in z/OS P.T. OpenSSH 1.3 (HOS1130), you *can* use ssh,
sftp, scp from a 3270 OMVS shell - you just can't prompt the terminal for a
password or passphrase since it is not a real tty and OpenSSH requires tty
password masking.

For example, with a public key from a 3270 "TSO OMVS" shell:

==> ssh -v 127.0.0.1
...
debug1: Next authentication method: publickey

debug1: Offering RSA public key: /u/kirk/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279

debug1: read PEM private key done: type RSA

debug1: Authentication succeeded (publickey).

Authenticated to 127.0.0.1 ([127.0.0.1]:22).

debug1: channel 0: new [client-session]

debug1: Requesting no-more-sessi...@openssh.com

debug1: Entering interactive session.

you have mail in /usr/mail/KIRK.



Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> Here's an old SHARE presentation on z/OS Ported Tools OpenSSH 1.3 new
features:
https://dovetail.com/docs/coz/SHARE_OpenSSH_Seattle_2015.pdf

On Wed, Dec 7, 2016 at 10:41 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 7 Dec 2016 10:58:02 +0530, venkat kulkarni wrote:
>
> >Hello John,
> >Sorry for delay in response and I tried the JCL you suggest for sftp
> >transfer but getting below issue on job output
> >
> >debug1: Authentications that can continue:
> >publickey,password,keyboard-interacti
> >
> First, partition the problem.  Put the JCL aside and get the process
> working
> with keys using a real terminal (3270 absolutely won't work).
>
> Then try wraping the process in a batch job.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread Paul Gilmartin
On Wed, 7 Dec 2016 10:58:02 +0530, venkat kulkarni wrote:

>Hello John,
>Sorry for delay in response and I tried the JCL you suggest for sftp
>transfer but getting below issue on job output
>
>debug1: Authentications that can continue:
>publickey,password,keyboard-interacti
> 
First, partition the problem.  Put the JCL aside and get the process working
with keys using a real terminal (3270 absolutely won't work).

Then try wraping the process in a batch job.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread Kirk Wolf
FWIW, a very interesting way to authenticate z/OS OpenSSH sessions is using
Kerberos (perhaps with Windows Active Directory).

z/OS provides Kerberos as part of its free feature " z/OS Network
Authentication Service", and this is compatible with a Windows Active
Directory domain and MIT Kerberos on Unix/Linux.

The learning curve for setting this up is steep, but here is a SHARE
session and a white paper to kick start things:

*The Three Headed Dog Ate My SSH Keys! - Using OpenSSH in a Single Sign-on
Corporate Environment with z/OS, Windows and Linux*


http://s23.a2zinc.net/clients/SHARE/Winter2016/Public/SessionDetails.aspx?SessionID=103=4

*Using OpenSSH in a Single Sign-On Corporate Environment with z/OS, Windows
and Linux*
https://dovetail.com/docs/ssh/kerberos_sso.pdf

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread Kirk Wolf
On Wed, Dec 7, 2016 at 9:41 AM, John McKown 
wrote:

> On Wed, Dec 7, 2016 at 9:37 AM, Kirk Wolf  wrote:
>
> > With openssh ssh or sftp commands, a password (or pass phrase) has to
> > either be read from a tty or you can use an SSH_ASKPASS program.   You
> > can't pipe it in as suggested earlier in this script.
> >
>
> ​Do you have an example of using SSH_ASKPASS? I tried, on z/OS 1.12, and
> failed.​
>
>
> Yes:

>
> >
> > PS> examples of using passwords in batch / jcl scripts can be found in
> the
> > Co:Z sample JCL, which is available free to use.
> >
> >
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread John McKown
On Wed, Dec 7, 2016 at 9:37 AM, Kirk Wolf  wrote:

> With openssh ssh or sftp commands, a password (or pass phrase) has to
> either be read from a tty or you can use an SSH_ASKPASS program.   You
> can't pipe it in as suggested earlier in this script.
>

​Do you have an example of using SSH_ASKPASS? I tried, on z/OS 1.12, and
failed.​



>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> PS> examples of using passwords in batch / jcl scripts can be found in the
> Co:Z sample JCL, which is available free to use.
>
>

-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread Kirk Wolf
With openssh ssh or sftp commands, a password (or pass phrase) has to
either be read from a tty or you can use an SSH_ASKPASS program.   You
can't pipe it in as suggested earlier in this script.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

PS> examples of using passwords in batch / jcl scripts can be found in the
Co:Z sample JCL, which is available free to use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread Jack J. Woehr

John McKown wrote:

My apologies. I had forgotten that I had everything set up properly to do a
"password-less" ssh connection to my test Linux box.


Venkat should also pull the password line out of the JCL if he's going to use 
public key.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread Jack J. Woehr

venkat kulkarni wrote:

Then I also run below command



sftp -v -b -op117@10.221.129.10



from USS  and got similar error,


If you're doing it interactively, do NOT use the "-b -" switch.

Just sftp -v op117@10.221.129.10

Also, do you have a target host you can ssh to? Are you successful performing a 
regular ssh to that host?

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread John McKown
OK, I made a mistake in my testing. On my z/OS system, I have the file:
~/.ssh/id_rsa . This file contains the SSH key for my test Linux system,
which I was using in my testing. I had overlooked this when I was testing
my script. This SSH file was created _without_ a passphrase; specifically
so that I could use the ssh transport without the need to supply any
password or passphrase. You will need to do the same. That is, generate an
SSH key (if you haven't already). Make it _without_ a passphrase. Transfer
the "pub" file to the remote server. Put the "pub" file into the remote
user's ~/.ssh/authorized_keys2 (or whatever the correct file is - it can
vary depending on the configuration). You must also create / update the
~/.ssh/config file to have an entry which tells SSH which SSH file key file
to use (if it's not id_rsa). Something like:

HOST remote-ip-or-dns
IdentityFile /u//.ssh/
User 

My apologies. I had forgotten that I had everything set up properly to do a
"password-less" ssh connection to my test Linux box.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread venkat kulkarni
I have cross verified about all directory and files permission you
suggested earlier.



z/OS USS side

drwx--   2 MEAS OMVSGRP 8192 Dec  6 01:47 .ssh

-rw---   1 MEAS OMVSGRP  668 Dec  6 01:47 id_dsa

-rw-r--r--   1 MEAS OMVSGRP  603 Dec  6 01:47 id_dsa.pub

-rw-r--r--   1 MEAS OMVSGRP  175 Dec  6 01:08 known_hosts





and in the target host, I have



drwx--2 ibm08staff   256 Dec 07 07:58 .ssh

-rw---1 ibm08staff   603 Dec 07 07:58 authorized_keys

-rw-r--r--1 ibm08staff   176 Dec 06 11:57 known_hosts







Then I also run below command



sftp -v -b - op117@10.221.129.10



from USS  and got similar error,

Hide quoted text



debug1: identity file /u/ibm08/.ssh/id_rsa-cert type
-1

debug1: identity file /u/ibm08/.ssh/id_dsa type
2

debug1: identity file /u/ibm08/.ssh/id_dsa-cert type -1


debug1: identity file /u/ibm08/.ssh/id_ecdsa type
-1

debug1: identity file /u/ibm08/.ssh/id_ecdsa-cert type
-1

debug1: Enabling compatibility mode for protocol
2.0

debug1: Local version string
SSH-2.0-OpenSSH_6.4

debug1: Remote protocol version 2.0, remote software version
OpenSSH_6.0

debug1: match: OpenSSH_6.0 pat
OpenSSH*

debug1: SSH2_MSG_KEXINIT
sent

debug1: SSH2_MSG_KEXINIT
received

debug1: mac_setup_by_alg: hmac-sha1 from source
OpenSSL

debug1: kex: server->client aes128-ctr hmac-sha1
none

debug1: mac_setup_by_alg: hmac-sha1 from source
OpenSSL

debug1: kex: client->server aes128-ctr hmac-sha1
none

debug1: sending
SSH2_MSG_KEX_ECDH_INIT

debug1: expecting
SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host key: ECDSA
3a:49:46:72:a2:3b:60:9d:84:86:9c:ec:d4:01:77:90

debug1: Host '10.221.129.10' is known and matches the ECDSA host
key.

debug1: Found key in
/u/ibm08/.ssh/known_hosts:1

debug1: ssh_ecdsa_verify: signature correct


debug1: cipher_init: aes128-ctr from source
OpenSSL

debug1: SSH2_MSG_NEWKEYS
sent

debug1: expecting
SSH2_MSG_NEWKEYS

debug1: cipher_init: aes128-ctr from source
OpenSSL

debug1: SSH2_MSG_NEWKEYS
received

debug1: SSH2_MSG_SERVICE_REQUEST
sent

debug1: SSH2_MSG_SERVICE_ACCEPT
received

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

debug1: Next authentication method:
publickey

debug1: Trying private key:
/u/ibm08/.ssh/id_rsa

debug1: Offering DSA public key:
/u/ibm08/.ssh/id_dsa

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

debug1: Trying private key:
/u/ibm08/.ssh/id_ecdsa

debug1: No more authentication methods to
try.

FOTS1373 Permission denied
(publickey,password,keyboard-interactive).

debug1: zsshSmfSetConnSmfStatus: SMF status is
0

FOTS0841 Connection
closed

So, I think even now connection to the target host is not getting
established. Do we have any more direction into this issue.

On Dec 7, 2016 11:39, "Jack J. Woehr"  wrote:

> venkat kulkarni wrote:
>
> To provide you move detail, I earlier copied id_dsa.pub key from mainframe
>> to target host authorized_keys file.
>>
>> So, in place of id_dsa.pub key, will it make difference, if we copy id_dsa
>> key to target host.
>>
>
> No, that wouldn't help. The public key is what is needed in the remote
> server's authorized_keys file.
>
> your .ssh directory : 700
> your id_dsa : 600
> your id_dsa.pub: 644
> remote server .ssh directory : 700
> remote server authorized_keys : 600
>
> If key negotiation does indeed work, you will need to remove the " -b -"
> and also the sending of the password.
>
> You should try the command line which is embedded in the JCL from inside
> USS itself without the JCL.
>
> All that the JCL is doing is sending USS a command line.
>
> Try it interactively in USS if you have not already done so. Make a shell
> file in USS that says something like
>
> # myxfer.sh
> cat << END password
> cd /tmp
> ascii
> put /tmp/SOME.FILE.NAME some.file.name
> END |  sftp -v -b - use...@remote.ssh.server
>
> and see if you can execute that successfully right in USS, using the
> 'bash' command if you have it, e.g.,
>
> bash ./myxfer.sh
>
> It's 01:40 here in Colorado ... I'm going to bed. Good-night and good
> luck, Venkat!
>
> Jack
>
>
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread Jack J. Woehr

venkat kulkarni wrote:


To provide you move detail, I earlier copied id_dsa.pub key from mainframe
to target host authorized_keys file.

So, in place of id_dsa.pub key, will it make difference, if we copy id_dsa
key to target host.


No, that wouldn't help. The public key is what is needed in the remote server's 
authorized_keys file.

your .ssh directory : 700
your id_dsa : 600
your id_dsa.pub: 644
remote server .ssh directory : 700
remote server authorized_keys : 600

If key negotiation does indeed work, you will need to remove the " -b -" and 
also the sending of the password.

You should try the command line which is embedded in the JCL from inside USS 
itself without the JCL.

All that the JCL is doing is sending USS a command line.

Try it interactively in USS if you have not already done so. Make a shell file 
in USS that says something like

# myxfer.sh
cat << END password
cd /tmp
ascii
put /tmp/SOME.FILE.NAME some.file.name
END |  sftp -v -b - use...@remote.ssh.server

and see if you can execute that successfully right in USS, using the 'bash' 
command if you have it, e.g.,

bash ./myxfer.sh

It's 01:40 here in Colorado ... I'm going to bed. Good-night and good luck, 
Venkat!

Jack



--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread venkat kulkarni
No, didn't work. Same issue as earlier.

I don't know why it's not accepting password mentioned in JCL for login to
target host.

To provide you move detail, I earlier copied id_dsa.pub key from mainframe
to target host authorized_keys file.

So, in place of id_dsa.pub key, will it make difference, if we copy id_dsa
key to target host.

Or any other suggestion from your side.

On Dec 7, 2016 11:22, "Jack J. Woehr"  wrote:

> venkat kulkarni wrote:
>
>> This time I run with -b - -v option and error are as below.
>>
>
> Try reversing the options. I think -v has to be earlier. Do:
>
> -v -b -
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread Jack J. Woehr

venkat kulkarni wrote:

This time I run with -b - -v option and error are as below.


Try reversing the options. I think -v has to be earlier. Do:

-v -b -

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread venkat kulkarni
This time I run with -b - -v option and error are as below.

debug1: identity file /u/ibm08/.ssh/id_rsa-cert type
-1

debug1: identity file /u/ibm08/.ssh/id_dsa type
2

debug1: identity file /u/ibm08/.ssh/id_dsa-cert type
-1

debug1: identity file /u/ibm08/.ssh/id_ecdsa type
-1

debug1: identity file /u/ibm08/.ssh/id_ecdsa-cert type
-1

debug1: Enabling compatibility mode for protocol
2.0

debug1: Local version string
SSH-2.0-OpenSSH_6.4

debug1: Remote protocol version 2.0, remote software version
OpenSSH_6.0

debug1: match: OpenSSH_6.0 pat
OpenSSH*

debug1: SSH2_MSG_KEXINIT
sent

debug1: SSH2_MSG_KEXINIT
received

debug1: mac_setup_by_alg: hmac-sha1 from source
OpenSSL

debug1: kex: server->client aes128-ctr hmac-sha1
none

debug1: mac_setup_by_alg: hmac-sha1 from source
OpenSSL

debug1: kex: client->server aes128-ctr hmac-sha1 none


debug1: sending
SSH2_MSG_KEX_ECDH_INIT

debug1: expecting
SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host key: ECDSA
3a:49:46:72:a2:3b:60:9d:84:86:9c:ec:d4:01:77:90

debug1: Host '10.221.129.10' is known and matches the ECDSA host
key.

debug1: Found key in
/u/ibm08/.ssh/known_hosts:1

debug1: ssh_ecdsa_verify: signature
correct

debug1: cipher_init: aes128-ctr from source
OpenSSL

debug1: SSH2_MSG_NEWKEYS
sent

debug1: expecting
SSH2_MSG_NEWKEYS

debug1: cipher_init: aes128-ctr from source
OpenSSL

debug1: SSH2_MSG_NEWKEYS
received

debug1: SSH2_MSG_SERVICE_REQUEST
sent

debug1: SSH2_MSG_SERVICE_ACCEPT
received

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

debug1: Next authentication method:
publickey

debug1: Trying private key:
/u/ibm08/.ssh/id_rsa

debug1: Offering DSA public key:
/u/ibm08/.ssh/id_dsa

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

debug1: Trying private key:
/u/ibm08/.ssh/id_ecdsa

debug1: No more authentication methods to
try.

FOTS1373 Permission denied
(publickey,password,keyboard-interactive).

debug1: zsshSmfSetConnSmfStatus: SMF status is
0

FOTS0841 Connection closed

On Dec 7, 2016 11:07, "Jack J. Woehr"  wrote:

> venkat kulkarni wrote:
>
>>
>> FOTS0806 EDC5129I No such file or directory. (errno2=0x05620062) (-v)
>>
>>
> Yes, not:
>
>sftp -b -v ..
>
> but rather
>
>sftp -b - -v ..
>
> I pointed out my mistake typing the first message
>
> The flag is "-b -".
>
> -b expects a file argument. The extra dash "-" means "the file for batch
> mode is instead Standard Input".
>
>>
>> Jack J. Woehr wrote:
>>>
>>> OOPS mistake should be this:
>>>
>>>
>>>  sftp -b - -v use...@remote.ssh.server
>>>
>>> Note the "-" after the "-b" before the "-v"
>>>
>>> I did it right below \/\/\/\/\/\/
>>>
>>> The "-b - " tells sftp to read in batch mode from standard in. That might
 work.



 --
>>> Jack J. Woehr # Science is more than a body of knowledge. It's a way
>>> of
>>> www.well.com/~jax # thinking, a way of skeptically interrogating the
>>> universe
>>> www.softwoehr.com # with a fine understanding of human fallibility. -
>>> Carl Sagan
>>>
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread Jack J. Woehr

venkat kulkarni wrote:


FOTS0806 EDC5129I No such file or directory. (errno2=0x05620062) (-v)



Yes, not:

   sftp -b -v ..

but rather

   sftp -b - -v ..

I pointed out my mistake typing the first message

The flag is "-b -".

-b expects a file argument. The extra dash "-" means "the file for batch mode is 
instead Standard Input".



Jack J. Woehr wrote:

OOPS mistake should be this:


 sftp -b - -v use...@remote.ssh.server

Note the "-" after the "-b" before the "-v"

I did it right below \/\/\/\/\/\/


The "-b - " tells sftp to read in batch mode from standard in. That might
work.




--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the
universe
www.softwoehr.com # with a fine understanding of human fallibility. -
Carl Sagan


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-07 Thread venkat kulkarni
Hello Jack,
I run JCL with your suggestion and this time I am getting below error.

/SFTP001 JOB ACCT,NAME,CLASS=A,MSGCLASS=A,NOTIFY=

//SFTP EXEC PGM=IKJEFT01,REGION=0M

//SYSTSPRT DD   SYSOUT=*

//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC

//SYSTSIN  DD   *

OPUT 'IBM08.TEST.DATA' '/u/ibm08/test'

OSHELL { echo 'passwd'; +

 echo 'cd /tmp'; +

 echo 'ascii'; +

 echo 'put /home/ibm08'; } | +

   sftp -b -v ibm08@10.221.129.10







Error is



FOTS0806 EDC5129I No such file or directory. (errno2=0x05620062) (-v)

I have checked all required file and directories are present to run this JCL

Please suggest.

On Dec 7, 2016 10:50, "Jack J. Woehr"  wrote:

> Jack J. Woehr wrote:
>
> OOPS mistake should be this:
>
>
> sftp -b - -v use...@remote.ssh.server
>
> Note the "-" after the "-b" before the "-v"
>
> I did it right below \/\/\/\/\/\/
>
>>
>> The "-b - " tells sftp to read in batch mode from standard in. That might
>> work.
>>
>>
>>
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-06 Thread Jack J. Woehr

Jack J. Woehr wrote:

OOPS mistake should be this:


sftp -b - -v use...@remote.ssh.server

Note the "-" after the "-b" before the "-v"

I did it right below \/\/\/\/\/\/


The "-b - " tells sftp to read in batch mode from standard in. That might work.





--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-06 Thread Jack J. Woehr

venkat kulkarni wrote:

Venkat ... in this part of the JCL:

OSHELL { echo 'password'; +
>  echo 'cd /tmp'; +
>  echo 'ascii'; +
>  echo 'put/tmp/SOME.FILE.NAME '; } | +
>sftp -vuse...@remote.ssh.server


Try changing the last line to this:

   sftp -b -v use...@remote.ssh.server

The "-b - " tells sftp to read in batch mode from standard in. That might work.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-06 Thread venkat kulkarni
Hello Jack, thanks for reply.

John, can you please help in answering query raised by back on the JCL you
provided for this sftp.

On Dec 7, 2016 10:42, "Jack J. Woehr"  wrote:

> venkat kulkarni wrote:
>
>> Yes but if you look at Job output and it's tries to authenticate using
>> public key , password , interactive but all failing. I sent you job out in
>> earlier response.
>>
>
> That's always the way an ssh connection is established (unless you use
> args to prevent it).
>
> ssh and scp and sftp ... they're all almost the same program
>
> They will try key negotiation first, then finally password. The failures
> in key negotiation you are seeing are not really errors.
>
> The error is here:
>
> debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device.
> (errno2=0
>
> debug1: Authentications that can continue:
> publickey,password,keyboard-interacti
>
> FOTS1346 Permission denied, please try
> again.
>
> debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device.
> (errno2=0
>
> debug1: Authentications that can continue:
> publickey,password,keyboard-interacti
>
> FOTS1346 Permission denied, please try
> again.
>
> debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device.
> (errno2=0
>
>
> SFTP is trying three (3) times to open the tty device to read a password.
> It's not succeeding.
>
> I don't understand how z/OS SFTP and the JCL you have been given are
> supposed to interact, but it's not working.
>
> This part of the JCL:
>
> OSHELL { echo 'password'; +
>  echo 'cd /tmp'; +
>  echo 'ascii'; +
>  echo 'put/tmp/SOME.FILE.NAME '; } | +
>sftp -vuse...@remote.ssh.server
>
> Is not successfully putting the password to the server.
>
>
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-06 Thread Jack J. Woehr

venkat kulkarni wrote:

Yes but if you look at Job output and it's tries to authenticate using
public key , password , interactive but all failing. I sent you job out in
earlier response.


That's always the way an ssh connection is established (unless you use args to 
prevent it).

ssh and scp and sftp ... they're all almost the same program

They will try key negotiation first, then finally password. The failures in key negotiation you are seeing are not 
really errors.


The error is here:

debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device.
(errno2=0

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

FOTS1346 Permission denied, please try
again.

debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device.
(errno2=0

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

FOTS1346 Permission denied, please try
again.

debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device.
(errno2=0


SFTP is trying three (3) times to open the tty device to read a password. It's 
not succeeding.

I don't understand how z/OS SFTP and the JCL you have been given are supposed 
to interact, but it's not working.

This part of the JCL:

OSHELL { echo 'password'; +
 echo 'cd /tmp'; +
 echo 'ascii'; +
 echo 'put/tmp/SOME.FILE.NAME '; } | +
   sftp -vuse...@remote.ssh.server

Is not successfully putting the password to the server.



--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-06 Thread venkat kulkarni
Yes but if you look at Job output and it's tries to authenticate using
public key , password , interactive but all failing. I sent you job out in
earlier response.

Regards

On Dec 7, 2016 09:14, "Jack J. Woehr"  wrote:

> venkat kulkarni wrote:
>
>> ... I tried to solve this key issue but no success so far. Please suggest.
>>
>
> Excuse my previous response, looks like you're trying to authenticate with
> password instead of keys.
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-06 Thread venkat kulkarni
Hello,

Yes .ssh Dir on target host is 700 and authorized_keys file is 600
permission .

To give you more detail in created authorized _keys file in target system
by copying id_dsa.pub file from z/os side of .ssh directory under my user
name home directory.

But I am still getting same issue

On Dec 7, 2016 09:10, "Jack J. Woehr"  wrote:

> venkat kulkarni wrote:
>
>> Sorry for delay in response and I tried the JCL you suggest for sftp
>> transfer but getting below issue on job output
>>
>
> Make sure the target .ssh directory (where the authorized_keys file is) is
> chmod 700 and the authorized_keys file itself is chmod 600.
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-06 Thread Jack J. Woehr

venkat kulkarni wrote:

... I tried to solve this key issue but no success so far. Please suggest.


Excuse my previous response, looks like you're trying to authenticate with 
password instead of keys.

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-06 Thread Jack J. Woehr

venkat kulkarni wrote:

Sorry for delay in response and I tried the JCL you suggest for sftp
transfer but getting below issue on job output


Make sure the target .ssh directory (where the authorized_keys file is) is chmod 700 and the authorized_keys file itself 
is chmod 600.


--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-06 Thread venkat kulkarni
Hello John,
Sorry for delay in response and I tried the JCL you suggest for sftp
transfer but getting below issue on job output

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

debug1: Next authentication method:
publickey

debug1: Trying private key:
/u/ibm08/.ssh/id_rsa

debug1: Offering DSA public key:
/u/ibm08/.ssh/id_dsa

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

debug1: Trying private key:
/u/ibm08/.ssh/id_ecdsa

debug1: Next authentication method: keyboard-interactive


debug1: Authentications that can continue:
publickey,password,keyboard-interacti

debug1: Next authentication method:
password

debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device.
(errno2=0

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

FOTS1346 Permission denied, please try
again.

debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device.
(errno2=0

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

FOTS1346 Permission denied, please try
again.

debug1: read_passphrase: can't open /dev/tty: EDC5128I No such device.
(errno2=0

debug1: Authentications that can continue:
publickey,password,keyboard-interacti

debug1: No more authentication methods to
try.

FOTS1373 Permission denied
(publickey,password,keyboard-interactive).

debug1: zsshSmfSetConnSmfStatus: SMF status is
0

FOTS0841 Connection closed

... I tried to solve this key issue but no success so far. Please suggest.

On Dec 1, 2016 19:17, "John McKown"  wrote:

> Damn it, forgot to make one change in the command stream.
>
> //JOBNAME JOB ACCT,NAME,CLASS=A,MSGCLASS=H,
> // NOTIFY=
> //SFTP EXEC PGM=IKJEFT01,REGION=0M
> //SYSTSPRT DD   SYSOUT=*
> //SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC (MAY BE DIFFERENT)
> //SYSTSIN  DD   *
> OPUT 'SOME.DATA.SET.NAME ' '/tmp/
> SOME.FILE.NAME
> '
> OSHELL { echo 'password'; +
>  echo 'cd /tmp'; +
>  echo 'ascii'; +
>  echo 'put /tmp/SOME.FILE.NAME '; } | +
>sftp -v use...@remote.ssh.server
> /*
> //* CHANGE password TO ACTUAL PASSWORD
> //* CHANGE cd COMMAND TO ACTUAL REMOTE DIRECTORY
> //* REMOVE ascii LINE FOR BINARY TRANSFER
> //* CHANGE userid TO REMOTE USER'S ID
> //* CHANGE remote.ssh.server TO ACTUAL DNS NAME/IP ADDR
> //SCP  EXEC PGM=IKJEFT01,REGION=0M
> //SYSTSPRT DD   SYSOUT=*
> //SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC (MAY BE DIFFERENT)
> //SYSTSIN  DD   *
> OPUT 'SOME.DATA.SET.NAME ' '/tmp/
> SOME.FILE.NAME
> '
> OSHELL echo 'password' | +
>scp /tmp/SOME.FILE.NAME  +
>use...@remote.ssh.server:-
> /tmp/SOME.UNIXFILE.NAME 
> /*
> //* CHANGE password TO ACTUAL PASSWORD
> //* CHANGE userid TO ACTUAL REMOTE USER ID
> //* CHANGE remote.ssh.server TO ACTUAL DNS NAME/IP ADDR
> //*  CRITICAL 
> //* Note that scp command is spread over 3 lines due to
> //* length of SYSTSIN input line. TSO will concatenate
> //* them together into one logical line. IT IS CRITICAL
> //* that you notice that I put the output file name
> //* (/tmp/SOME.UNIXFILE.NAME ) on its own line
> //* IT IS CRITICAL that this start in column 1.
> //* IT IS ALSO CRITICAL that the previous line
> //* end in a dash instead of a plus and that the dash
> //* is _IMMEDIATELY_ after the colon. This is to
> //* force TSO to concatenate all these characters together
> //* without any spaces, which would destroy the UNIX
> //* command line.
> //
> ​
>
>
> --
> Heisenberg may have been here.
>
> Unicode: http://xkcd.com/1726/
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-02 Thread David Crayford

On 1/12/2016 10:49 PM, Mullen, Patrick wrote:

Venkat,

Go to https://dovetail.com/solutions.html and get yourself a copy of their 
utterly fine product Co:Z SFTP, which will enable you to do exactly what you 
want. The installation doc has examples which will have you sftp-ing sequential 
and PDS datasets in no time. And best of all, you may use the product free of 
charge under their community license.


I second that!





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of venkat kulkarni
Sent: Thursday, December 01, 2016 12:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO Setup on SSH

Hello David, yes I am aware that sftp process only Unix files but I heard that 
we have other of transferring traditional mvs dataset like we can first 
transfer mvs dataset to omvs and then do sftp.

But I never did this before, so I am requesting to help on sample JCL.

On Dec 1, 2016 09:13, "David Crayford" <dcrayf...@gmail.com> wrote:


On 1/12/2016 1:14 PM, venkat kulkarni wrote:


Do anybody have sample batch job to transfer data using sftp.

Currently we using FTP in batch job PGM but not sure what program we
should use for sftp and format of JCL to transfer  sequential and PDs
datasets.


sftp only supports UNIX files so you're out of luck if you want to
process traditional MVS data sets (as mentioned in a previous thread).

Thnaks

On Nov 29, 2016 09:51, "Jack J. Woehr" <j...@well.com> wrote:

David Crayford wrote:

Yep. It's part of Rockets ported tools http://www.rocketsoftware.com/

ported-tools.

Very cool, had no idea they were there.




--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-01 Thread Paul Gilmartin
On Thu, 1 Dec 2016 10:16:10 -0600, John McKown  wrote:

>Damn it, forgot to make one change in the command stream.
>
I wonder, did the OP get secure tn3270 working.  Then, much
as I hate to recommend it to anyone, would IND$FILE provide a
solution?  Is IND$FILE UNIX-file-savvy?

Here's my approach, using a POSIX pipe rather than a temp file,
with thanks to Peter Farley for suggestions about dealing with
PARMDD.  (I hate MVS, for reasons that go even beyond EBCDIC.):

//*
//SET4  SET OPTS=''   or '-B'
//SET5  SET FILTER='' or 'iconv -f ISO8859-1 -t IBM-1047 |'
//SET6  SET LCLFILE='//''SYS1.MACLIB(SPLEVEL)'''
//SET7  SET SYMS='SYMBOLS=(JCLONLY,LOGDD)'
//*
//FIXPARM  EXEC  PGM=IEBGENER
//SYSPRINT  DD  SYSOUT=(,)
//SYSIN DD  *
//SYSUT2DD  DISP=(,PASS),UNIT=SYSALLDA,SPACE=(1,(1,1))
//LOGDD DD  SYSOUT=(,)
//SYSUT1DD  *,  Copy LCLFILE to stdout
SH set -x; cp  ""  /dev/fd/1 |
//*
//  DD *,   Undo EBCDIC-ASCII translation.
  
//*
//  DD *,   Pipe into ssh.
  ssh ''@
//*
//  DD *,   Copy remote stdout to RMTFILE.
  "set -x; date; cat >"
//*
//STEP  EXEC  PGM=BPXBATCH,PARMDD=CMDS
//STDIN   DD  PATH='/dev/null'
//STDOUT  DD  SYSOUT=(,)
//STDERR  DD  SYSOUT=(,)
//CMDSDD  DISP=OLD,DSN=*.FIXPARM.SYSUT2

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-01 Thread John McKown
Damn it, forgot to make one change in the command stream.

//JOBNAME JOB ACCT,NAME,CLASS=A,MSGCLASS=H,
// NOTIFY=
//SFTP EXEC PGM=IKJEFT01,REGION=0M
//SYSTSPRT DD   SYSOUT=*
//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC (MAY BE DIFFERENT)
//SYSTSIN  DD   *
OPUT 'SOME.DATA.SET.NAME ' '/tmp/SOME.FILE.NAME
'
OSHELL { echo 'password'; +
 echo 'cd /tmp'; +
 echo 'ascii'; +
 echo 'put /tmp/SOME.FILE.NAME '; } | +
   sftp -v use...@remote.ssh.server
/*
//* CHANGE password TO ACTUAL PASSWORD
//* CHANGE cd COMMAND TO ACTUAL REMOTE DIRECTORY
//* REMOVE ascii LINE FOR BINARY TRANSFER
//* CHANGE userid TO REMOTE USER'S ID
//* CHANGE remote.ssh.server TO ACTUAL DNS NAME/IP ADDR
//SCP  EXEC PGM=IKJEFT01,REGION=0M
//SYSTSPRT DD   SYSOUT=*
//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC (MAY BE DIFFERENT)
//SYSTSIN  DD   *
OPUT 'SOME.DATA.SET.NAME ' '/tmp/SOME.FILE.NAME
'
OSHELL echo 'password' | +
   scp /tmp/SOME.FILE.NAME  +
   use...@remote.ssh.server:-
/tmp/SOME.UNIXFILE.NAME 
/*
//* CHANGE password TO ACTUAL PASSWORD
//* CHANGE userid TO ACTUAL REMOTE USER ID
//* CHANGE remote.ssh.server TO ACTUAL DNS NAME/IP ADDR
//*  CRITICAL 
//* Note that scp command is spread over 3 lines due to
//* length of SYSTSIN input line. TSO will concatenate
//* them together into one logical line. IT IS CRITICAL
//* that you notice that I put the output file name
//* (/tmp/SOME.UNIXFILE.NAME ) on its own line
//* IT IS CRITICAL that this start in column 1.
//* IT IS ALSO CRITICAL that the previous line
//* end in a dash instead of a plus and that the dash
//* is _IMMEDIATELY_ after the colon. This is to
//* force TSO to concatenate all these characters together
//* without any spaces, which would destroy the UNIX
//* command line.
//
​


-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-01 Thread Mullen, Patrick
Venkat,

Go to https://dovetail.com/solutions.html and get yourself a copy of their 
utterly fine product Co:Z SFTP, which will enable you to do exactly what you 
want. The installation doc has examples which will have you sftp-ing sequential 
and PDS datasets in no time. And best of all, you may use the product free of 
charge under their community license.




-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of venkat kulkarni
Sent: Thursday, December 01, 2016 12:19 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO Setup on SSH

Hello David, yes I am aware that sftp process only Unix files but I heard that 
we have other of transferring traditional mvs dataset like we can first 
transfer mvs dataset to omvs and then do sftp.

But I never did this before, so I am requesting to help on sample JCL.

On Dec 1, 2016 09:13, "David Crayford" <dcrayf...@gmail.com> wrote:

> On 1/12/2016 1:14 PM, venkat kulkarni wrote:
>
>> Do anybody have sample batch job to transfer data using sftp.
>>
>> Currently we using FTP in batch job PGM but not sure what program we 
>> should use for sftp and format of JCL to transfer  sequential and PDs 
>> datasets.
>>
>
> sftp only supports UNIX files so you're out of luck if you want to 
> process traditional MVS data sets (as mentioned in a previous thread).
>
> Thnaks
>>
>> On Nov 29, 2016 09:51, "Jack J. Woehr" <j...@well.com> wrote:
>>
>> David Crayford wrote:
>>
>> Yep. It's part of Rockets ported tools http://www.rocketsoftware.com/
>>> ported-tools.
>>>
>>> Very cool, had no idea they were there.
>>
>>
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-12-01 Thread John McKown
On Wed, Nov 30, 2016 at 11:14 PM, venkat kulkarni <
venkatkulkarn...@gmail.com> wrote:

> Do anybody have sample batch job to transfer data using sftp.
>
> Currently we using FTP in batch job PGM but not sure what program we should
> use for sftp and format of JCL to transfer  sequential and PDs datasets.
>
> Thnaks
>
>
​I'll avoid all the advice that you've been given about Co:Z from
Dovetailed Technologies (although I totally agree with it). I will assume
that you only have "normal" IBM supplied software and that the remote end
has a regular SSH server running. What I am unsure of is whether you
actually want to use "sftp" or if "scp" would be acceptable. So I will give
examples of both to allow you to choose which you prefer. The JCL will be
identical. In fact, I will show how I would do both transfers, first using
"sftp" and secondly using "scp"

//JOBNAME JOB ACCT,NAME,CLASS=A,MSGCLASS=H,
// NOTIFY=
//SFTP EXEC PGM=IKJEFT01,REGION=0M
//SYSTSPRT DD   SYSOUT=*
//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC (MAY BE DIFFERENT)
//SYSTSIN  DD   *
OPUT 'SOME.DATA.SET.NAME' '/tmp/SOME.FILE.NAME'
OSHELL { echo 'password'; +
 echo 'cd /tmp'; +
 echo 'ascii'; +
 echo 'put /tmp/SOME.FILE.NAME'; } | +
   sftp -v use...@remote.ssh.server
/*
//* CHANGE password TO ACTUAL PASSWORD
//* CHANGE cd COMMAND TO ACTUAL REMOTE DIRECTORY
//* REMOVE ascii LINE FOR BINARY TRANSFER
//* CHANGE userid TO REMOTE USER'S ID
//* CHANGE remote.ssh.server TO ACTUAL DNS NAME/IP ADDR
//SFTP EXEC PGM=IKJEFT01,REGION=0M
//SYSTSPRT DD   SYSOUT=*
//SYSEXEC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC (MAY BE DIFFERENT)
//SYSTSIN  DD   *
OPUT 'SOME.DATA.SET.NAME' '/tmp/SOME.FILE.NAME'
OSHELL echo 'password'; +
   scp /tmp/SOME.FILE.NAME +
   use...@remote.ssh.server:-
/tmp/SOME.UNIXFILE.NAME
/*
//* CHANGE password TO ACTUAL PASSWORD
//* CHANGE userid TO ACTUAL REMOTE USER ID
//* CHANGE remote.ssh.server TO ACTUAL DNS NAME/IP ADDR
//*  CRITICAL 
//* Note that scp command is spread over 3 lines due to
//* length of SYSTSIN input line. TSO will concatenate
//* them together into one logical line. IT IS CRITICAL
//* that you notice that I put the output file name
//* (/tmp/SOME.UNIXFILE.NAME) on its own line
//* IT IS CRITICAL that this start in column 1.
//* IT IS ALSO CRITICAL that the previous line
//* end in a dash instead of a plus and that the dash
//* is _IMMEDIATELY_ after the colon. This is to
//* force TSO to concatenate all these characters together
//* without any spaces, which would destroy the UNIX
//* command line.
//
​







-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-30 Thread Paul Gilmartin
On Thu, 1 Dec 2016 12:19:53 +0530, venkat kulkarni wrote:
>
>So, we have requirement of sending and receiving files of mainframe and
>windows as well as Unix systems.
>So, we need to setup JCL in z/os system in such a way the one JCL will be
>used for sending data can be sequential or PDs datasets to Windows
>mainframe or receiving file from Windows system using sftp rather then ftp.
> 
It appears that you want the driving system (client) to be z/OS
and the passive system (server) to be Windows.  What sort of
server do you have available on Windows?  (I used to be able to
do this sort of thing with a Cygin server on Windows.  The
ability vanished a few weeks ago.  I suspect the Powers That
Be spread a security blanket and my desktop Windows system
can no longer open any ports.  I'm not asking any questions
that might draw attention.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-30 Thread Paul Gilmartin
On Wed, 30 Nov 2016 23:37:24 -0700, Jack J. Woehr wrote:

>Paul Gilmartin wrote:
>> But must it be JCL?  Why not a UNIX shell script or Rexx, putting you a
>> couple interface layers closer to what you need to do.
>
>CMS/TSO Pipelines?
> 
How prevalent is CMS/TSO Pipelines in z/OS?

Does it have an SFTP stage

Does it have a z/OS UNIX command stage?  (And has it a CMS
OpenExtensions command stage?)

Does it have drivers for POSIX pipes?

Does it have a separate Users Guide for TSO or does a
single manual serve for both CMS and TSO?

I've sometimes used POSIX pipes for IEBGENER input/output.

Is the OP seeking a production quality utility or a personal tool?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-30 Thread venkat kulkarni
Thanks for reply.

So, we have requirement of sending and receiving files of mainframe and
windows as well as Unix systems.
So, we need to setup JCL in z/os system in such a way the one JCL will be
used for sending data can be sequential or PDs datasets to Windows
mainframe or receiving file from Windows system using sftp rather then ftp.

On Dec 1, 2016 09:29, "Paul Gilmartin" <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

On Thu, 1 Dec 2016 10:44:42 +0530, venkat kulkarni wrote:

>Do anybody have sample batch job to transfer data using sftp.
>
>Currently we using FTP in batch job PGM but not sure what program we should
>use for sftp and format of JCL to transfer  sequential and PDs datasets.
>
SFTP won't deal with PS and PDS data sets.  For that, you'd need
Dovetailed's
Co:Z, free to use, $ for support.

At times, I have kludged a pipeline of:

cp "//'PDS.NAME(MEMBER)'" /dev/fd/1 |
ssh user@remote-host "
cat >target-file"
(Authentication via ~/.sh)

What sorts of systems have you
o At the controlling end?
o At the passive end?

JCL?  Look into BPXWUNIX.  (Can BPXWUNIX be executed from a JCL step
or is a Rexx layer needed?)

But must it be JCL?  Why not a UNIX shell script or Rexx, putting you a
couple interface layers closer to what you need to do.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-30 Thread Jack J. Woehr

Paul Gilmartin wrote:

But must it be JCL?  Why not a UNIX shell script or Rexx, putting you a
couple interface layers closer to what you need to do.


CMS/TSO Pipelines?

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-30 Thread Paul Gilmartin
On Thu, 1 Dec 2016 10:44:42 +0530, venkat kulkarni wrote:

>Do anybody have sample batch job to transfer data using sftp.
>
>Currently we using FTP in batch job PGM but not sure what program we should
>use for sftp and format of JCL to transfer  sequential and PDs datasets.
> 
SFTP won't deal with PS and PDS data sets.  For that, you'd need Dovetailed's
Co:Z, free to use, $ for support.

At times, I have kludged a pipeline of:

cp "//'PDS.NAME(MEMBER)'" /dev/fd/1 |
ssh user@remote-host "
cat >target-file"
(Authentication via ~/.sh)

What sorts of systems have you
o At the controlling end?
o At the passive end?

JCL?  Look into BPXWUNIX.  (Can BPXWUNIX be executed from a JCL step
or is a Rexx layer needed?)

But must it be JCL?  Why not a UNIX shell script or Rexx, putting you a
couple interface layers closer to what you need to do.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-30 Thread venkat kulkarni
Hello David, yes I am aware that sftp process only Unix files but I heard
that we have other of transferring traditional mvs dataset like we can
first transfer mvs dataset to omvs and then do sftp.

But I never did this before, so I am requesting to help on sample JCL.

On Dec 1, 2016 09:13, "David Crayford"  wrote:

> On 1/12/2016 1:14 PM, venkat kulkarni wrote:
>
>> Do anybody have sample batch job to transfer data using sftp.
>>
>> Currently we using FTP in batch job PGM but not sure what program we
>> should
>> use for sftp and format of JCL to transfer  sequential and PDs datasets.
>>
>
> sftp only supports UNIX files so you're out of luck if you want to process
> traditional MVS data sets (as mentioned in a previous thread).
>
> Thnaks
>>
>> On Nov 29, 2016 09:51, "Jack J. Woehr"  wrote:
>>
>> David Crayford wrote:
>>
>> Yep. It's part of Rockets ported tools http://www.rocketsoftware.com/
>>> ported-tools.
>>>
>>> Very cool, had no idea they were there.
>>
>>
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-30 Thread David Crayford

On 1/12/2016 1:14 PM, venkat kulkarni wrote:

Do anybody have sample batch job to transfer data using sftp.

Currently we using FTP in batch job PGM but not sure what program we should
use for sftp and format of JCL to transfer  sequential and PDs datasets.


sftp only supports UNIX files so you're out of luck if you want to 
process traditional MVS data sets (as mentioned in a previous thread).



Thnaks

On Nov 29, 2016 09:51, "Jack J. Woehr"  wrote:

David Crayford wrote:


Yep. It's part of Rockets ported tools http://www.rocketsoftware.com/
ported-tools.


Very cool, had no idea they were there.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-30 Thread venkat kulkarni
Do anybody have sample batch job to transfer data using sftp.

Currently we using FTP in batch job PGM but not sure what program we should
use for sftp and format of JCL to transfer  sequential and PDs datasets.

Thnaks

On Nov 29, 2016 09:51, "Jack J. Woehr"  wrote:

David Crayford wrote:

> Yep. It's part of Rockets ported tools http://www.rocketsoftware.com/
> ported-tools.
>

Very cool, had no idea they were there.


-- 
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the
universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl
Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-28 Thread David Crayford

On 29/11/2016 11:57 AM, Jack J. Woehr wrote:

David Crayford wrote:
the midnight command port which has weird key bindings. 


On *nix I live in Midnight Commander ... there's a port for z/OS?



Yep. It's part of Rockets ported tools 
http://www.rocketsoftware.com/ported-tools.



Do you run it from OMVS or just when you ssh in?



ssh of course. The TSO interface is dumb, literally!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-28 Thread Edward Gould
> On Nov 28, 2016, at 8:16 AM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Sun, 27 Nov 2016 17:10:17 -0600, Edward Gould wrote:
>> 
>> If you don’t like EBCDIC go play in the ASCII world.
>> 
> Oh, I do!  this forum is conducted in ASCII, isn't it?
Yes however I assume your full time job is an IBM mainframe which is EBCDIC.
Email is not a full time job unless we count you whining about JCL or TSO or ……
Last time I looked  dump was in EBCDIC.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-28 Thread Jack J. Woehr

David Crayford wrote:
the midnight command port which has weird key bindings. 


On *nix I live in Midnight Commander ... there's a port for z/OS?

Do you run it from OMVS or just when you ssh in?

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-28 Thread David Crayford

On 29/11/2016 9:18 AM, Paul Gilmartin wrote:

On Mon, 28 Nov 2016 19:40:11 +0800, David Crayford wrote:

ISPF does surprisingly well with UNIX files tagged UTF-8.


Agreed. IMO, ISPF has very good support for z/OS UNIX now. I spend most 
of my time in a shell  but ISPF sure beats

using the midnight command port which has weird key bindings.


It displays
characters in the terminal's particular code page and considers others
"nondisplayable".  (But I still need to submit an SR on how badly
"FIND P'.'" performs on such characters.)


I also wish the ISPF editor supported syntax highlighting for UTF-8 
files and browse also supported ASCII.


FWIW, Rocket have a z/OS git port which is in pre-release beta 
http://forum.rocketsoftware.com/t/git-for-z-os-is-now-available-in-pre-release-beta/408. 
It uses
enhanced ASCII and file tags to very good effect. IMO it's one of the 
most useful open source software ports for many years. I'm currently 
working on a project which
has z/OS compenents written in HLASM, C++ and Java and the browser based 
UI code written in Javascript (Angular.js, HTML5 etc). We use a private 
repo on github
and it's just fantastic to be able to use the same SCM for all our 
development. When you clone a repo from github z/OS git tags the files 
as ISO8859-1. Enhanced ASCII is working very well so far.



I haven't tried UTF-8 with a MBCS 3270.  Are there such?  I don't
believe I have access to one.

UTF-8 is the modal text representation for desktop systems and WWW.
There ought to be little need to use other character sets.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-28 Thread Paul Gilmartin
On Mon, 28 Nov 2016 22:32:08 +0530, venkat kulkarni wrote:

>Thanks for reply. I am looking for free tool for making this setup work .Do
>we have any solution.
>
Cygwin is free (= very attractive price).  But the setup is tedious although
the benefits are enormous (you can almost pretend you don't have Windows).

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-28 Thread venkat kulkarni
Thanks for reply. I am looking for free tool for making this setup work .Do
we have any solution.

On Mon, Nov 28, 2016 at 9:47 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 28 Nov 2016 21:24:24 +0530, venkat kulkarni wrote:
> >
> >I think, we still need solution of the this issue that how do we transfer
> >MVS sequential or PDS dataset using SFTP.
> >
> I can do it with Cygwin and ssh rather than SFTP.  Are Cygwin and
> ssh available to you?  The price is very attractive.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-28 Thread Paul Gilmartin
On Mon, 28 Nov 2016 21:24:24 +0530, venkat kulkarni wrote:
>
>I think, we still need solution of the this issue that how do we transfer
>MVS sequential or PDS dataset using SFTP.
> 
I can do it with Cygwin and ssh rather than SFTP.  Are Cygwin and
ssh available to you?  The price is very attractive.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-28 Thread John McKown
On Mon, Nov 28, 2016 at 9:09 AM, Jack J. Woehr  wrote:

> Paul Gilmartin wrote:
>
>> Wordpad is 50% better.  It understands UNIX files on input but always
>> saves as DOS.
>>
>> Notepad++ accepts DOS, UNiX and Classic Mac files and saves by default
>> in the input format.  Or the user can select the output format.
>>
>
> Any  Windows user who interacts with Unix, z/OS, z/VM, z/VSE, IBM i,
> and/or AIX should have Cygwin installed and be using JEdit and Vim as their
> editors anyway.
>

​_IF_ company policy allows it. The Windows desktops here are locked down
hard. And the Windows people _despise_ anything which is not MS blessed.
Which, I guess, is a reason to like the fact that Windows 10 has a Linux
subsystem. Of course, we just finished the upgrade to Windows 7. I've seen
one Windows 10 system in the operations area.



>
> https://www.*cygwin*.com/ (contains vim)
> www.*jedit*.org/
>
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-28 Thread Jack J. Woehr

Paul Gilmartin wrote:

Wordpad is 50% better.  It understands UNIX files on input but always
saves as DOS.

Notepad++ accepts DOS, UNiX and Classic Mac files and saves by default
in the input format.  Or the user can select the output format.


Any  Windows user who interacts with Unix, z/OS, z/VM, z/VSE, IBM i, and/or AIX should have Cygwin installed and be 
using JEdit and Vim as their editors anyway.


https://www.*cygwin*.com/ (contains vim)
www.*jedit*.org/

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-28 Thread Jack J. Woehr

David Crayford wrote:
Don't whine! If you're unhappy with scp then why don't you port it to do what you want? 


Two reasons:

1. Life is short and I'm both familiar with the porting process for OpenSSH and 
quite busy.
2. Everything works fine on IBM i, the IBM system I use the most!

https://github.com/jwoehr/ublu

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-28 Thread Paul Gilmartin
On Sun, 27 Nov 2016 17:10:17 -0600, Edward Gould wrote:
>
>If you don’t like EBCDIC go play in the ASCII world.
> 
Oh, I do!  this forum is conducted in ASCII, isn't it?

On Sun, 27 Nov 2016 18:14:01 -0600, John McKown wrote:
>
>> scp is universally outside z/OS a binary transfer protocol which knows
>> nothing whatsoever of the content it transfers.
>>
>​Which screws the pooch when transferring "printable" text files between
>Windows & *IX because of Windows' use of CRLF as a composite end-of-line
>indicator. Windows -> *IX leaves a ^M (CR) as part of the "data" in a text
>file. *IX -> lacks the CR which is required by many Windows programs
>(Notepad being the main one I know of).
>
Last time I tried Notepad it showed UNIX files in staircase mode.  Of
course, I haven't tried it since.

Wordpad is 50% better.  It understands UNIX files on input but always
saves as DOS.

Notepad++ accepts DOS, UNiX and Classic Mac files and saves by default
in the input format.  Or the user can select the output format.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-28 Thread David Crayford

On 28/11/2016 2:14 PM, Jack J. Woehr wrote:

David Crayford wrote:


He does! We all do. Most of the people whinging about EBCDIC on here 
also work on *nix systems.  EBCDIC is a terrible anachronism but 
unfortunately we're stuck with it.


I do indeed play on *nix. I came to traditional IBM record-based 
business systems from the Land of Nix.




In my time I've worked on many different systems. Mainly MVS and it's 
descendants but also AIX and AS/400 machines. AS/400 is also an EBCDIC 
platform and shares the same woes
as z/OS, but has the benefit of being tightly integrated with AIX so can 
spawn a process to run native in AIX which is all good. I've ported many 
open source projects to z/OS over the

years and EBCDIC is the killer.

I do not whinge about EBCDIC. EBCDIC is part of the austere and 
idiosyncratic nature of traditional IBM record-based business systems.


I find such idiosyncracies charming, much as some unfashionable aspect 
or attribute of a beautiful woman accentuates her beauty.




EBCDIC is no beauty! She's an ugly hag! Medusa comes to mind with every 
snakes head being a different EBCDIC code page. I recently received an 
e-mail from a sysprog at a Danish bank
asking me if it was possible to enable my z/OS Lua port to handle a 
Scandinavian code page. I hacked up a solution but running iconv to 
convert source modules added significant overhead

to a fast language.

I whinge about scp because that comes from my world and IBM 
mis-implemented it on z/OS!




Don't whine! If you're unhappy with scp then why don't you port it to do 
what you want?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-27 Thread Jack J. Woehr

David Crayford wrote:


He does! We all do. Most of the people whinging about EBCDIC on here also work on *nix systems.  EBCDIC is a terrible 
anachronism but unfortunately we're stuck with it.


I do indeed play on *nix. I came to traditional IBM record-based business 
systems from the Land of Nix.

I do not whinge about EBCDIC. EBCDIC is part of the austere and idiosyncratic nature of traditional IBM record-based 
business systems.


I find such idiosyncracies charming, much as some unfashionable aspect or attribute of a beautiful woman accentuates her 
beauty.


I whinge about scp because that comes from my world and IBM mis-implemented it 
on z/OS!

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-27 Thread David Crayford

On 28/11/2016 7:10 AM, Edward Gould wrote:

On Nov 27, 2016, at 4:53 PM, Edward Gould  wrote:


—SNIP-
IBM blundered with the 'scp' command on z/OS and made it automatically and 
uncontrollably convert text.

scp is universally outside z/OS a binary transfer protocol which knows nothing 
whatsoever of the content it transfers.

z/OS users are forced onto the inferior sftp which in the Unix world is merely 
an scp-knockoff nod to decades of
scripting ftp.


Have I ever mentioned that I hate EBCDIC!?  http://www.bobbemer.com/P-BIT.HTM 
 >

which came first the chicken or the egg?


Did you bother to read the link? It says that the 360 was planned to be 
an ASCII machine but they rushed it out as bi-modal and then didn't 
communicate the p-bit to the developers. A blunder that has cost 
hundreds of millions of dollars in processing costs

over the decades, and that is probably a conservative estimate.


IBM blundered by making UNIX System Services based on EBCDIC rather than ASCII.
It might yet be made impartially bimodal but until then customers will suffer.

If you don’t like EBCDIC go play in the ASCII world.


He does! We all do. Most of the people whinging about EBCDIC on here 
also work on *nix systems.  EBCDIC is a terrible anachronism but 
unfortunately we're stuck with it.



On occasion, I've resorted to such as:
   ssh user$zOS "cd somewhere & pax -w . | iconv -f ISO8859-1 -t IBM-1047" 
| pax -rv

And I think once again of Samuel Johnson's politically inorrect dog.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu  with 
the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-27 Thread John McKown
On Sun, Nov 27, 2016 at 11:25 AM, Jack J. Woehr  wrote:

> Paul Gilmartin wrote:
>
>> From a UNIXy platform or Cygwin I might try (if desperate):
>>
>
> IBM blundered with the 'scp' command on z/OS and made it automatically and
> uncontrollably convert text.
>

​I totally agree that this is a blunder. I do understand the basic "why" -
scp uses the same channel as ssh. A ssh user connecting to a UNIX shell
prompt must have their ASCII converted to EBCDIC, and vice versa, so that
thinks "work as desired". I could imagine an ssh which talks "binary" to
z/OS UNIX, but then _something_ either needs to convert the data to EBCDIC,
or the entire z/OS UNIX environment needs to be ASCII (or Unicode) based.
Hum, I can hear Gil's "I hate EBCDIC!" now [grin].​



>
> scp is universally outside z/OS a binary transfer protocol which knows
> nothing whatsoever of the content it transfers.
>

​Which screws the pooch when transferring "printable" text files between
Windows & *IX because of Windows' use of CRLF as a composite end-of-line
indicator. Windows -> *IX leaves a ^M (CR) as part of the "data" in a text
file. *IX -> lacks the CR which is required by many Windows programs
(Notepad being the main one I know of).



>
> z/OS users are forced onto the inferior sftp which in the Unix world is
> merely an scp-knockoff nod to decades of scripting ftp.


​I agree. Which really won't change much of anything.


>
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>


-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-27 Thread Steve Thompson
Inquiring minds: why did 
Burroughs use EBCDIC?

Sent from my iPhone

> On Nov 27, 2016, at 6:13 PM, Mike Schwab  wrote:
> 
> On Sun, Nov 27, 2016 at 4:53 PM, Edward Gould  wrote:
> 

> IBM came out with the 80 column card.
> BCD was the 6 bit representation of the card punches.
> EBCDIC was the 8 bit extension to BCD for the IBM 360.
> 
> -- 
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-27 Thread Mike Schwab
On Sun, Nov 27, 2016 at 4:53 PM, Edward Gould  wrote:
>>> —SNIP-
>>> IBM blundered with the 'scp' command on z/OS and made it automatically and 
>>> uncontrollably convert text.
>>>
>>> scp is universally outside z/OS a binary transfer protocol which knows 
>>> nothing whatsoever of the content it transfers.
>>>
>>> z/OS users are forced onto the inferior sftp which in the Unix world is 
>>> merely an scp-knockoff nod to decades of
>>> scripting ftp.
>>>
>> Have I ever mentioned that I hate EBCDIC!?  
>> http://www.bobbemer.com/P-BIT.HTM 
>
> which came first the chicken or the egg?
>>
>> IBM blundered by making UNIX System Services based on EBCDIC rather than 
>> ASCII.
>> It might yet be made impartially bimodal but until then customers will 
>> suffer.
>>
>> On occasion, I've resorted to such as:
>>ssh user$zOS "cd somewhere & pax -w . | iconv -f ISO8859-1 -t 
>> IBM-1047" | pax -rv
>>
>> And I think once again of Samuel Johnson's politically inorrect dog.
>>
>> -- gil

The egg has the mutation (or hybridization) that grows the first chicken.

IBM came out with the 80 column card.
BCD was the 6 bit representation of the card punches.
EBCDIC was the 8 bit extension to BCD for the IBM 360.

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-27 Thread Edward Gould
> On Nov 27, 2016, at 4:53 PM, Edward Gould  wrote:
> 
>>> —SNIP-
>>> IBM blundered with the 'scp' command on z/OS and made it automatically and 
>>> uncontrollably convert text.
>>> 
>>> scp is universally outside z/OS a binary transfer protocol which knows 
>>> nothing whatsoever of the content it transfers.
>>> 
>>> z/OS users are forced onto the inferior sftp which in the Unix world is 
>>> merely an scp-knockoff nod to decades of
>>> scripting ftp.
>>> 
>> Have I ever mentioned that I hate EBCDIC!?  
>> http://www.bobbemer.com/P-BIT.HTM  
>> >
> 
> which came first the chicken or the egg?
>> 
>> IBM blundered by making UNIX System Services based on EBCDIC rather than 
>> ASCII.
>> It might yet be made impartially bimodal but until then customers will 
>> suffer.

If you don’t like EBCDIC go play in the ASCII world.

>> 
>> On occasion, I've resorted to such as:
>>   ssh user$zOS "cd somewhere & pax -w . | iconv -f ISO8859-1 -t 
>> IBM-1047" | pax -rv
>> 
>> And I think once again of Samuel Johnson's politically inorrect dog.
>> 
>> -- gil
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu  with 
> the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-27 Thread Edward Gould
>> —SNIP-
>> IBM blundered with the 'scp' command on z/OS and made it automatically and 
>> uncontrollably convert text.
>> 
>> scp is universally outside z/OS a binary transfer protocol which knows 
>> nothing whatsoever of the content it transfers.
>> 
>> z/OS users are forced onto the inferior sftp which in the Unix world is 
>> merely an scp-knockoff nod to decades of
>> scripting ftp.
>> 
> Have I ever mentioned that I hate EBCDIC!?  http://www.bobbemer.com/P-BIT.HTM 
> 

which came first the chicken or the egg?
> 
> IBM blundered by making UNIX System Services based on EBCDIC rather than 
> ASCII.
> It might yet be made impartially bimodal but until then customers will suffer.
> 
> On occasion, I've resorted to such as:
>ssh user$zOS "cd somewhere & pax -w . | iconv -f ISO8859-1 -t 
> IBM-1047" | pax -rv
> 
> And I think once again of Samuel Johnson's politically inorrect dog.
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-27 Thread Paul Gilmartin
On Sun, 27 Nov 2016 10:25:54 -0700, Jack J. Woehr wrote:
>
>IBM blundered with the 'scp' command on z/OS and made it automatically and 
>uncontrollably convert text.
>
>scp is universally outside z/OS a binary transfer protocol which knows nothing 
>whatsoever of the content it transfers.
>
>z/OS users are forced onto the inferior sftp which in the Unix world is merely 
>an scp-knockoff nod to decades of
>scripting ftp.
>
Have I ever mentioned that I hate EBCDIC!?  http://www.bobbemer.com/P-BIT.HTM

IBM blundered by making UNIX System Services based on EBCDIC rather than ASCII.
It might yet be made impartially bimodal but until then customers will suffer.

On occasion, I've resorted to such as:
ssh user$zOS "cd somewhere & pax -w . | iconv -f ISO8859-1 -t 
IBM-1047" | pax -rv

And I think once again of Samuel Johnson's politically inorrect dog.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-27 Thread Jack J. Woehr

Paul Gilmartin wrote:

From a UNIXy platform or Cygwin I might try (if desperate):


IBM blundered with the 'scp' command on z/OS and made it automatically and 
uncontrollably convert text.

scp is universally outside z/OS a binary transfer protocol which knows nothing 
whatsoever of the content it transfers.

z/OS users are forced onto the inferior sftp which in the Unix world is merely an scp-knockoff nod to decades of 
scripting ftp.


--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-27 Thread Paul Gilmartin
On Sun, 27 Nov 2016 17:00:59 +0530, venkat kulkarni wrote:

>Thanks all. I am using winscp to transfer Unix file transfer between system
>but how can I transfer mvs PDs dataset using sftp
> 
Mostly not.  You can install Dovetailed's Co:Z.  Free to use, $ for support.

From a UNIXy platform or Cygwin I might try (if desperate):

ssh user@zOS "cp \"//'PART.DATA.SET(MEMBER)'\" /dev/fd/1" >localfile

(I rarely get that right on the first try.)

Are you allowed Cygwin?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-27 Thread venkat kulkarni
Thanks all. I am using winscp to transfer Unix file transfer between system
but how can I transfer mvs PDs dataset using sftp

On Nov 24, 2016 19:39, "Jack J. Woehr"  wrote:

> venkat kulkarni wrote:
>
>> Also please help me to find difference in tn3270 and tn3270e and when
>> should we use tn3270e instead of tn3270.
>>
>
> I believe that basically tn3270e is the modern protocol currently in use
> and is effectively what is meant when people talk about the tn3270 protocol.
>
> http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.
> ibm.zos.v2r1.halz002/telnet_tn3270e_conn_mode.htm
> https://tools.ietf.org/html/rfc2355
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-24 Thread Jack J. Woehr

venkat kulkarni wrote:

Also please help me to find difference in tn3270 and tn3270e and when
should we use tn3270e instead of tn3270.


I believe that basically tn3270e is the modern protocol currently in use and is effectively what is meant when people 
talk about the tn3270 protocol.


http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.halz002/telnet_tn3270e_conn_mode.htm
https://tools.ietf.org/html/rfc2355

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-22 Thread venkat kulkarni
Thanks to all. After receiving all reply from experts and from manual now
my understanding is,

I should use SSL 992 port and with self signed certificate to enable SSL on
tso. Please correct me , if I am going in wrong direction.

Also please help me to find difference in tn3270 and tn3270e and when
should we use tn3270e instead of tn3270.

Thanks for all help.

On Nov 22, 2016 22:54, "Kirk Wolf" <k...@dovetail.com> wrote:

> The scripting for x3270 is basically just automation control.   I don't
> really understand why there would be a performance issue or concern.
>
> http://x3270.bgp.nu/Unix/x3270-script.html
>
> Here's an example that I did that logs into TSO with a password/passticket
> supplied in an environment variable:
>
> #!/bin/bash
> # script to start x3270 and login to TSO with a MSG10 menu screen
> zosuser=$1
> zoshostandport=$2
> connecthostandport=$3
> connecthostandport=${connecthostandport:-$zoshostandport}
>
> x3270 -script -xrm 'x3270.connectFileName: none' -once $connecthostandport
> < Wait(30,InputField)
> Title($zosuser@$zoshostandport)
> String(tso)
> Enter
> Wait(30,InputField)
> String($zosuser)
> Enter
> Wait(30,InputField)
> String($X3270PW)
> Closescript(0)
> EOF
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> On Tue, Nov 22, 2016 at 10:10 AM, Martin Packer <martin_pac...@uk.ibm.com>
> wrote:
>
> > I use x3270 all the time. And I've made widespread use of custom key
> > sequences to make me more productive. So far so good.
> >
> > Kirk, you mentioned scripting. I've only had limited success with that.
> > One day I'll persist. :-)
> >
> > But the reason for leaping in is to ask whether - in anyone on the list's
> > experience - scripting performance is OK. I ask because this seems
> > analogous to the kind of protocol IND£FILE represents, which I always
> > found to be slow.
> >
> > Thoughts?
> >
> > Martin Packer,
> > zChampion, Principal Systems Investigator,
> > Worldwide Cloud & Systems Performance, IBM
> >
> > +44-7802-245-584
> >
> > email: martin_pac...@uk.ibm.com
> >
> > Twitter / Facebook IDs: MartinPacker
> >
> > Blog:
> > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
> >
> > Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/
> or
> >
> > https://itunes.apple.com/gb/podcast/mainframe-performance-
> > topics/id1127943573?mt=2
> >
> >
> >
> > From:   Kirk Wolf <k...@dovetail.com>
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date:   22/11/2016 15:27
> > Subject:Re: TSO Setup on SSH
> > Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
> >
> >
> >
> > There are a bunch of pieces that I would have to externalize; maybe some
> > day.
> >
> > I don't really find x3270 all that objectionable.  Its fairly easy to
> > customize and the scripting works fine.
> > Granted, I don't use it that much; most of my z/OS work is from a shell.
> >
> > Kirk Wolf
> > Dovetailed Technologies
> > http://dovetail.com
> >
> > On Tue, Nov 22, 2016 at 9:08 AM, John McKown
> > <john.archie.mck...@gmail.com>
> > wrote:
> >
> > > On Tue, Nov 22, 2016 at 9:01 AM, Kirk Wolf <k...@dovetail.com> wrote:
> > >
> > > > ​
> > > >
> > > >
> > > > We do something like this from our Linux workstations.  I wrote a
> > script
> > > > that makes an ssh connection (authenticating with a private key from
> a
> > > > password safe) and over this connection it runs a z/OS UNIX command
> to
> > > > return a RACF passticket for the userid.   Then it starts x3270 with
> a
> > > > automation script that connects through the ssh tunnel and
> > automatically
> > > > logs on to TSO using the passticket.
> > > >
> > >
> > > ​Oh, that is clever. Can you share this? Too bad x3270 is a PITA to use
> > > compared to most of the Windows 3270 emulators.​ I wish someone would
> > take
> > > the x3270 code and enhance it to use QT or GTK+ or even some other
> > > windowing framework.
> > >
> > >
> > >
> > > >
> > > > Kirk Wolf
> > > > http://dovetail.com
> > > >
> > > >
> > > --
> > > Heisenberg may have been here.
> > >
> > > Unicode: http://xkcd.com/1726/
> > >
> > > Maranatha! <><
> > 

Re: TSO Setup on SSH

2016-11-22 Thread Kirk Wolf
The scripting for x3270 is basically just automation control.   I don't
really understand why there would be a performance issue or concern.

http://x3270.bgp.nu/Unix/x3270-script.html

Here's an example that I did that logs into TSO with a password/passticket
supplied in an environment variable:

#!/bin/bash
# script to start x3270 and login to TSO with a MSG10 menu screen
zosuser=$1
zoshostandport=$2
connecthostandport=$3
connecthostandport=${connecthostandport:-$zoshostandport}

x3270 -script -xrm 'x3270.connectFileName: none' -once $connecthostandport
<http://dovetail.com

On Tue, Nov 22, 2016 at 10:10 AM, Martin Packer <martin_pac...@uk.ibm.com>
wrote:

> I use x3270 all the time. And I've made widespread use of custom key
> sequences to make me more productive. So far so good.
>
> Kirk, you mentioned scripting. I've only had limited success with that.
> One day I'll persist. :-)
>
> But the reason for leaping in is to ask whether - in anyone on the list's
> experience - scripting performance is OK. I ask because this seems
> analogous to the kind of protocol IND£FILE represents, which I always
> found to be slow.
>
> Thoughts?
>
> Martin Packer,
> zChampion, Principal Systems Investigator,
> Worldwide Cloud & Systems Performance, IBM
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog:
> https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker
>
> Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or
>
> https://itunes.apple.com/gb/podcast/mainframe-performance-
> topics/id1127943573?mt=2
>
>
>
> From:   Kirk Wolf <k...@dovetail.com>
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date:   22/11/2016 15:27
> Subject:Re: TSO Setup on SSH
> Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
>
>
>
> There are a bunch of pieces that I would have to externalize; maybe some
> day.
>
> I don't really find x3270 all that objectionable.  Its fairly easy to
> customize and the scripting works fine.
> Granted, I don't use it that much; most of my z/OS work is from a shell.
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> On Tue, Nov 22, 2016 at 9:08 AM, John McKown
> <john.archie.mck...@gmail.com>
> wrote:
>
> > On Tue, Nov 22, 2016 at 9:01 AM, Kirk Wolf <k...@dovetail.com> wrote:
> >
> > > ​
> > >
> > >
> > > We do something like this from our Linux workstations.  I wrote a
> script
> > > that makes an ssh connection (authenticating with a private key from a
> > > password safe) and over this connection it runs a z/OS UNIX command to
> > > return a RACF passticket for the userid.   Then it starts x3270 with a
> > > automation script that connects through the ssh tunnel and
> automatically
> > > logs on to TSO using the passticket.
> > >
> >
> > ​Oh, that is clever. Can you share this? Too bad x3270 is a PITA to use
> > compared to most of the Windows 3270 emulators.​ I wish someone would
> take
> > the x3270 code and enhance it to use QT or GTK+ or even some other
> > windowing framework.
> >
> >
> >
> > >
> > > Kirk Wolf
> > > http://dovetail.com
> > >
> > >
> > --
> > Heisenberg may have been here.
> >
> > Unicode: http://xkcd.com/1726/
> >
> > Maranatha! <><
> > John McKown
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-22 Thread Martin Packer
I use x3270 all the time. And I've made widespread use of custom key 
sequences to make me more productive. So far so good.

Kirk, you mentioned scripting. I've only had limited success with that. 
One day I'll persist. :-)

But the reason for leaping in is to ask whether - in anyone on the list's 
experience - scripting performance is OK. I ask because this seems 
analogous to the kind of protocol IND£FILE represents, which I always 
found to be slow.

Thoughts?

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2



From:   Kirk Wolf <k...@dovetail.com>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   22/11/2016 15:27
Subject:        Re: TSO Setup on SSH
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



There are a bunch of pieces that I would have to externalize; maybe some
day.

I don't really find x3270 all that objectionable.  Its fairly easy to
customize and the scripting works fine.
Granted, I don't use it that much; most of my z/OS work is from a shell.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, Nov 22, 2016 at 9:08 AM, John McKown 
<john.archie.mck...@gmail.com>
wrote:

> On Tue, Nov 22, 2016 at 9:01 AM, Kirk Wolf <k...@dovetail.com> wrote:
>
> > ​
> >
> >
> > We do something like this from our Linux workstations.  I wrote a 
script
> > that makes an ssh connection (authenticating with a private key from a
> > password safe) and over this connection it runs a z/OS UNIX command to
> > return a RACF passticket for the userid.   Then it starts x3270 with a
> > automation script that connects through the ssh tunnel and 
automatically
> > logs on to TSO using the passticket.
> >
>
> ​Oh, that is clever. Can you share this? Too bad x3270 is a PITA to use
> compared to most of the Windows 3270 emulators.​ I wish someone would 
take
> the x3270 code and enhance it to use QT or GTK+ or even some other
> windowing framework.
>
>
>
> >
> > Kirk Wolf
> > http://dovetail.com
> >
> >
> --
> Heisenberg may have been here.
>
> Unicode: http://xkcd.com/1726/
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-22 Thread Kirk Wolf
There are a bunch of pieces that I would have to externalize; maybe some
day.

I don't really find x3270 all that objectionable.  Its fairly easy to
customize and the scripting works fine.
Granted, I don't use it that much; most of my z/OS work is from a shell.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, Nov 22, 2016 at 9:08 AM, John McKown 
wrote:

> On Tue, Nov 22, 2016 at 9:01 AM, Kirk Wolf  wrote:
>
> > ​
> >
> >
> > We do something like this from our Linux workstations.  I wrote a script
> > that makes an ssh connection (authenticating with a private key from a
> > password safe) and over this connection it runs a z/OS UNIX command to
> > return a RACF passticket for the userid.   Then it starts x3270 with a
> > automation script that connects through the ssh tunnel and automatically
> > logs on to TSO using the passticket.
> >
>
> ​Oh, that is clever. Can you share this? Too bad x3270 is a PITA to use
> compared to most of the Windows 3270 emulators.​ I wish someone would take
> the x3270 code and enhance it to use QT or GTK+ or even some other
> windowing framework.
>
>
>
> >
> > Kirk Wolf
> > http://dovetail.com
> >
> >
> --
> Heisenberg may have been here.
>
> Unicode: http://xkcd.com/1726/
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-22 Thread John McKown
On Tue, Nov 22, 2016 at 9:01 AM, Kirk Wolf  wrote:

> ​
>
>
> We do something like this from our Linux workstations.  I wrote a script
> that makes an ssh connection (authenticating with a private key from a
> password safe) and over this connection it runs a z/OS UNIX command to
> return a RACF passticket for the userid.   Then it starts x3270 with a
> automation script that connects through the ssh tunnel and automatically
> logs on to TSO using the passticket.
>

​Oh, that is clever. Can you share this? Too bad x3270 is a PITA to use
compared to most of the Windows 3270 emulators.​ I wish someone would take
the x3270 code and enhance it to use QT or GTK+ or even some other
windowing framework.



>
> Kirk Wolf
> http://dovetail.com
>
>
-- 
Heisenberg may have been here.

Unicode: http://xkcd.com/1726/

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-22 Thread Kirk Wolf
On Tue, Nov 22, 2016 at 12:03 AM, Jack J. Woehr  wrote:

>
> SSH and secure Telnet3270E essentially use the same security technology,
> that is, OpenSSL.
>

 z/OS OpenSSH does include some of the EVP crypto code from OpenSSL for
Ciphers and MACs, etc, but it doesn't use any "SSL" or "TLS" functionality.
  IBM's port also includes support for ICSF algorithms, which bypass the
OpenSSL Ciphers and MACs completely.   To say the it is the same security
technology as TN3270 is very misleading IMO.


>ssh -Llocalhost:12345:myzosbox:23 myid@myzosbox


>

> and after you have logged in via ssh a redirection is established from
> your local port 12345 to z/OS's port 23.
>
> After establishing the redirect, use PCOMM to connect to localhost:12345
> ... Thus, you will be going into the z/OS port 23 via the redirect via SSH
> port 22 on the z/OS box.
>

We do something like this from our Linux workstations.  I wrote a script
that makes an ssh connection (authenticating with a private key from a
password safe) and over this connection it runs a z/OS UNIX command to
return a RACF passticket for the userid.   Then it starts x3270 with a
automation script that connects through the ssh tunnel and automatically
logs on to TSO using the passticket.

Kirk Wolf
http://dovetail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-22 Thread Bill Woodger
Venkat,

Can you please clarify exactly what you want to achieve, what point you are 
trying to reach? By "TSO" do you mean, as Paul suspects, you need direct, 
immediate, access to a TSO prompt for some long-superseded limit on some 
requirement from years 'n' years ago? Or do you, by "TSO", mean you still want 
to access things running on the Mainframe (ISPF, CICS, whatever) through a 
terminal emulator on the assumption that there is now some new odd limitation 
on how that was done previously? Or something else?

Can you describe, in words, the way that whatever-it-is works currently, and 
why something now requires some change for exactly the same to be happening in 
the changed situation? 

Else this topic can continue expanding whilst getting nowhere.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread venkat kulkarni
Hello Paul,

Thanks. So, in pcom session I should use o
992 instead of telnet port 23 which we are currently using it.

If yes, then also suggest what more changes we need to make to have 992 tso
connection work to access tso

On Nov 22, 2016 10:27, "Paul Gilmartin" <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 22 Nov 2016 11:22:54 +0530, venkat kulkarni wrote:
>
> >Thanks. As I am in process of setting up open ssh on our zos system and
> now
> >I am able to log in to system on once using my tso I'd with ssh port 22.
> >But was not able to connect to tso with port 22 by making changes in pcom
> >session connection.
> >
> BTW, if you want a secure tn3270 connection, the conventional port is
> 992.  Lots of IBM documentation mentions this.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread Paul Gilmartin
On Tue, 22 Nov 2016 11:22:54 +0530, venkat kulkarni wrote:

>Thanks. As I am in process of setting up open ssh on our zos system and now
>I am able to log in to system on once using my tso I'd with ssh port 22.
>But was not able to connect to tso with port 22 by making changes in pcom
>session connection.
> 
BTW, if you want a secure tn3270 connection, the conventional port is
992.  Lots of IBM documentation mentions this.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread Paul Gilmartin
On Tue, 22 Nov 2016 14:20:34 +0800, Timothy Sipples wrote:
>
>In contrast, TN3270E tunneling over SSH is not that common. The
>SSH Tectia Server for z/OS, a commercial product, officially supports 3270
>tunneling over SSH. As far as I know the OpenSSH server included with z/OS
>2.2, and its predecessors provided with the IBM Ported Tools for z/OS, do
>not.
>
It may work better than you expect.  On my MacBook where I'm emperor of
the universe  can set up local forwarding of port 12345 to z/OS 23.  Then
I TELNET to localhost 12345 and get a linemode connection to z/OS TSO
with old-fashioned LOGON prompt. Then it fails because allocation fails
for ISPF350.LPALIB.  I'm almost there.

Can't set up remote forwarding at all which would be secure.  But that may
be due to security cofiguration.

And I can't do some tests because there's no telnet client on z/OS.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread Timothy Sipples
That's not how TN3270E protocols typically work. If you want encrypted
TN3270E sessions (you should!), I recommend you enable TLS/SSL-encrypted
TN3270E. That capability has been available for two decades now at no
additional charge, starting way back in the OS/390 days, and progressively
improved ever since. (DES and 3DES encrypted SNA has been around even
longer than that.) There are a lot of references describing how to
configure TLS/SSL-encrypted TN3270E, but try this one first:

http://www.redbooks.ibm.com/abstracts/sg248099.html

Chapter 16 is where you'll want to spend most of your time, and
specifically with the AT-TLS configuration. Note that you'll most likely
want to deploy a TLS/SSL server certificate signed by a well known CA as
part of your setup.

IBM Personal Communications, IBM Host On-Demand, and virtually all other
3270 emulation software products support TLS/SSL-encrypted TN3270E sessions
and have for many years (also for a couple decades really) -- with nothing
particularly exotic or strange for the end users to do when configuring
sessions. In contrast, TN3270E tunneling over SSH is not that common. The
SSH Tectia Server for z/OS, a commercial product, officially supports 3270
tunneling over SSH. As far as I know the OpenSSH server included with z/OS
2.2, and its predecessors provided with the IBM Ported Tools for z/OS, do
not.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread Paul Gilmartin
On Mon, 21 Nov 2016 23:03:17 -0700, Jack J. Woehr wrote:
>
>However, on the PCOMM workstation, *if* you have ssh, you can do an ssh port 
>redirect first, and then you can get
>through to the Telnet3270E port on your z/OS machine.
>
I believe that requires an ssh *server* on the workstation.  Until recently,
I was able to run sshd under Cygwin on my employer's PC.  Not lately;
I suspect someone tightened security rules.

> From a command line on the workstation you would do:
>
>ssh -Llocalhost:12345:myzosbox:23 myid@myzosbox
>
Even so, isn't forwarding being done on localhost which makes an unsecured
connection to myzosbox:23, which may not meet the requirement?
>
>and after you have logged in via ssh a redirection is established from your 
>local port 12345 to z/OS's port 23.
>
>After establishing the redirect, use PCOMM to connect to localhost:12345 ... 
>Thus, you will be going into the z/OS port
>23 via the redirect via SSH port 22 on the z/OS box.
>
When I try remote forwarding with the -R option, which should make
a secured connection, I get:
Warning: remote port forwarding failed for listen port 12345

>But really, using secure Telnet3270E is easier!
>
I assume there's some unstated requirement to get to the TSO READY
prompt.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread Jack J. Woehr

venkat kulkarni wrote:

So, I wanted to take help of expert to make this tso connection work with
port 22. Please correct me if my understanding is wrong

Well, I'm hardly an "expert".

SSH and secure Telnet3270E essentially use the same security technology, that 
is, OpenSSL.

Secure Telnet3270E works out of the box with z/OS.

OpenSSH sshd running in Unix System Services will not, as far as I know, pass 
you directly through to TSO.

Changing the settings in PCOMM won't affect that.

However, on the PCOMM workstation, *if* you have ssh, you can do an ssh port redirect first, and then you can get 
through to the Telnet3270E port on your z/OS machine.


From a command line on the workstation you would do:

   ssh -Llocalhost:12345:myzosbox:23 myid@myzosbox


and after you have logged in via ssh a redirection is established from your 
local port 12345 to z/OS's port 23.

After establishing the redirect, use PCOMM to connect to localhost:12345 ... Thus, you will be going into the z/OS port 
23 via the redirect via SSH port 22 on the z/OS box.


Does this help?

But really, using secure Telnet3270E is easier!

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread Paul Gilmartin
On Tue, 22 Nov 2016 11:12:51 +0530, venkat kulkarni wrote:

>It's on live system not on zpdt. But as I mentioned before I would like to
>use secure port 22 to connect with tso instead of telnet port 23.
>
>Please suggest me the way to make this connection work.
>
Can you get a secure connection with a 3278?

But does that put you directly in ISPF rather than at the TSO READY prompt?

Would a READY prompt on a 3278 satisfy your needs?

If so, you need to have an alternative logon PROCEDURE defined that
doesn't automatically start ISPF.

(I assume since you say you can use sftp that you have a well-featured
client such as PuTTY, Hummingbird, Cygwin, Linux, OS X, whatever.)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread venkat kulkarni
Thanks. As I am in process of setting up open ssh on our zos system and now
I am able to log in to system on once using my tso I'd with ssh port 22.
But was not able to connect to tso with port 22 by making changes in pcom
session connection.

So, I wanted to take help of expert to make this tso connection work with
port 22. Please correct me if my understanding is wrong

On Nov 22, 2016 08:46, "Jack J. Woehr"  wrote:

> venkat kulkarni wrote:
>
>> It's on live system not on zpdt. But as I mentioned before I would like to
>> use secure port 22 to connect with tso instead of telnet port 23.
>>
>> Please suggest me the way to make this connection work.
>>
> Don't you just want secure TN3270e? You don't need SSH itself.
>
> http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.
> ibm.zos.v2r1.halz002/security_tn3270e.htm
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread Jack J. Woehr

venkat kulkarni wrote:

It's on live system not on zpdt. But as I mentioned before I would like to
use secure port 22 to connect with tso instead of telnet port 23.

Please suggest me the way to make this connection work.

Don't you just want secure TN3270e? You don't need SSH itself.

http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.halz002/security_tn3270e.htm

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread David Crayford

On 22/11/2016 1:42 PM, venkat kulkarni wrote:

It's on live system not on zpdt. But as I mentioned before I would like to
use secure port 22 to connect with tso instead of telnet port 23.

Please suggest me the way to make this connection work.


There is no way that I know of. Are you sure you don't really want to 
use telnet over an SSL connection?




On Nov 22, 2016 08:17, "Amrith" <
00ae6d97fc6e-dmarc-requ...@listserv.ua.edu> wrote:


I think thats the way it's supposed to be used, you can try using putty if
you want to. Are you on real iron or zPDT ?


 On Tuesday, November 22, 2016 10:22 AM, venkat kulkarni <
venkatkulkarn...@gmail.com> wrote:


  Hello,
Thanks for reply. Sorry for not being clear. Basically I want to use SSH
with port 22 duribg accessing tso using pcom session. Currently we use
telnet with port 22.

On Nov 22, 2016 06:11, "Paul Gilmartin" <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:


On 2016-11-21 19:34, venkat kulkarni wrote:

Hello Group,

We are setting up open SSH with our z/OS system and we are done with

making

connection to omvs using SFTP and transfer file to the system and vice
versa.

But, I still not able to find way to setup secure connection to TSO

using

port 22 ( SSH). Can you please help me to define this setup on TSO

level

access.


Ummm... you want to run TSO in linemode?  Have you a specific objective?

You might try ssh server-side port mapping (-R option) of some other
port to 23.  I suspect the protocols are dreadfully mismatched.

Why?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread venkat kulkarni
It's on live system not on zpdt. But as I mentioned before I would like to
use secure port 22 to connect with tso instead of telnet port 23.

Please suggest me the way to make this connection work.

On Nov 22, 2016 08:17, "Amrith" <
00ae6d97fc6e-dmarc-requ...@listserv.ua.edu> wrote:

> I think thats the way it's supposed to be used, you can try using putty if
> you want to. Are you on real iron or zPDT ?
>
>
> On Tuesday, November 22, 2016 10:22 AM, venkat kulkarni <
> venkatkulkarn...@gmail.com> wrote:
>
>
>  Hello,
> Thanks for reply. Sorry for not being clear. Basically I want to use SSH
> with port 22 duribg accessing tso using pcom session. Currently we use
> telnet with port 22.
>
> On Nov 22, 2016 06:11, "Paul Gilmartin" <
> 000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> > On 2016-11-21 19:34, venkat kulkarni wrote:
> > > Hello Group,
> > >
> > > We are setting up open SSH with our z/OS system and we are done with
> > making
> > > connection to omvs using SFTP and transfer file to the system and vice
> > > versa.
> > >
> > > But, I still not able to find way to setup secure connection to TSO
> using
> > > port 22 ( SSH). Can you please help me to define this setup on TSO
> level
> > > access.
> > >
> > Ummm... you want to run TSO in linemode?  Have you a specific objective?
> >
> > You might try ssh server-side port mapping (-R option) of some other
> > port to 23.  I suspect the protocols are dreadfully mismatched.
> >
> > Why?
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread Amrith
I think thats the way it's supposed to be used, you can try using putty if you 
want to. Are you on real iron or zPDT ?
 

On Tuesday, November 22, 2016 10:22 AM, venkat kulkarni 
 wrote:
 

 Hello,
Thanks for reply. Sorry for not being clear. Basically I want to use SSH
with port 22 duribg accessing tso using pcom session. Currently we use
telnet with port 22.

On Nov 22, 2016 06:11, "Paul Gilmartin" <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On 2016-11-21 19:34, venkat kulkarni wrote:
> > Hello Group,
> >
> > We are setting up open SSH with our z/OS system and we are done with
> making
> > connection to omvs using SFTP and transfer file to the system and vice
> > versa.
> >
> > But, I still not able to find way to setup secure connection to TSO using
> > port 22 ( SSH). Can you please help me to define this setup on TSO level
> > access.
> >
> Ummm... you want to run TSO in linemode?  Have you a specific objective?
>
> You might try ssh server-side port mapping (-R option) of some other
> port to 23.  I suspect the protocols are dreadfully mismatched.
>
> Why?
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread Paul Gilmartin
On Tue, 22 Nov 2016 10:22:09 +0530, venkat kulkarni wrote:
>
>Thanks for reply. Sorry for not being clear. Basically I want to use SSH
>with port 22 duribg accessing tso using pcom session. Currently we use
>telnet with port 22.
>
Looking at an arbitrarily selected /etc/services I see:

ssh 22/tcp  # SSH Remote Login Protocol
ssh 22/udp
telnet  23/tcp

... but then your configuration may be idiosyncratic.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Re: TSO Setup on SSH

2016-11-21 Thread Paul Gilmartin
On Tue, 22 Nov 2016 08:04:06 +0530, venkat kulkarni wrote:
>
>We are setting up open SSH with our z/OS system and we are done with making
>connection to omvs using SFTP and transfer file to the system and vice
>versa.
>
>But, I still not able to find way to setup secure connection to TSO using
>port 22 ( SSH). Can you please help me to define this setup on TSO level
>access.
> 
Let me guess.  From the questions you've asked lately, you're confronting
a new security regime which insists:

o All logons be validated by LDAP

and Timothy has been unable to sell them the Right Solution.

o All network connections be secured by SSL.

but you have some residue of users who depend on a linemode TELNET
connection to TSO.  The last time I remember something similar, the users
needed to punch paper tapes.  It was a while ago.  Kermit with 7171
emulation and IND$FILE?  More plausibly, they want to do scripting
over the TELNET connection.

Gasp.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


  1   2   >