What command are you issuing on the CMS client?
Alan Ackerman
v.uark.edu] On Behalf Of Alan Altmark
> Sent: Wednesday, December 01, 2010 2:11 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: z/VM 6.1, SSLSERV Question
>
> On Wednesday, 12/01/2010 at 11:43 EST, "Schuh, Richard"
>
> wrote:
> > Thanks for the reply, Alan.
No.
Look again.
There is an important topological difference between UFT and NJE-IP.
UFT is just another IP protocol (one that looks more like RSCS than, say,
FTP). Your network topology does not change.
While NJE-over-IP is a network-on-a-network. Full-blown RSCS, but with a
whole raft of "nod
On Thursday, 12/02/2010 at 10:08 EST, Richard Troth
wrote:
> The bottom line for UFT is to do over TCP what RSCS does over
CTC/VTAM/NJE, but
> not in the way NJE/IP does. (Of course, it might be a good hint to the
present
> NJE/IP authors and owners to create a UFT driver for their stuff.
Alan Altmark wrote :-
> I would have thought that everyone's IT host & network security
> departments would be turning the screws on unencrypted and
unauthenticated
> transmission to/from VM of any sensitive data and/or passwords. ("You
> mean you let MAINT's password flow in clear-text over
On Thursday, 12/02/2010 at 09:32 EST, Richard Troth
wrote:
> RXSSL comes to mind. As it happens, a couple of us were discussing
RXSSL
> off-list within the past day. Seems that it may need some attention to
get it
> working with the new VM SSL.
As I'm sure you have discovered, the challeng
Yep. A new RFC is needed. The original author has been saying that for ten
years, has asked for collaborators, and is still open.
The original design intentionally left compression and encryption out of
scope. The advent of SSL suggests that was probably a good choice. ZIP has
been around sinc
sage-
> > From: The IBM z/VM Operating System
> > [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> > Sent: Wednesday, December 01, 2010 6:53 AM
> > To: IBMVM@LISTSERV.UARK.EDU
> > Subject: Re: z/VM 6.1, SSLSERV Question
> >
> > On Tuesday, 11/3
On Thursday, 12/02/2010 at 08:15 EST, Mark Wheeler
wrote:
> It would be nice if UFT(D) would support it.
RFC 1440 does not define a mechanism for the UFT client and server to
negotiate and initiate TLS. A new RFC is needed. (Note that the IETF now
requires protocols to be able to negotiate T
> Date: Wed, 1 Dec 2010 17:10:41 -0500
> From: alan_altm...@us.ibm.com
> Subject: Re: z/VM 6.1, SSLSERV Question
> To: IBMVM@LISTSERV.UARK.EDU
> Btw, I don't see very much pressure being placed on z/VM to provide
> client-side TLS support for homegrown RxSocket
On Wednesday, 12/01/2010 at 11:43 EST, "Schuh, Richard"
wrote:
> Thanks for the reply, Alan. So it is not possible using RXSOCKET. Is it
> possible from a CMS client running a home-grown assembler or Pipelines
program,
> or is it a lost cause?
A lost cause, I would say.
Implicit/Static TLS/S
mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark
> Sent: Wednesday, December 01, 2010 6:53 AM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: z/VM 6.1, SSLSERV Question
>
> On Tuesday, 11/30/2010 at 06:39 EST, "Schuh, Richard"
>
> wrote:
>
> > We have
On Tuesday, 11/30/2010 at 06:39 EST, "Schuh, Richard"
wrote:
> We have a person who is trying to get a secure end-to-end transaction
between a
> CMS client and a TPF host. RXSOCKET is being used by the CMS client.
The port
> specified is 51105, which has been designated as a secure port. He
We have a person who is trying to get a secure end-to-end transaction between a
CMS client and a TPF host. RXSOCKET is being used by the CMS client. The port
specified is 51105, which has been designated as a secure port. He has traced
the SSLSERV and sees no traffic going through it; however,
14 matches
Mail list logo
