Re: DDR multivolume tape as output

2010-12-02 Thread Järvinen , Janne
Hello,

Thanks for the tips. 
I'm not familiar using pipes but interested to try this.  
I downloaded the DRPC stuff.

ddr 
DMSMOD639E Error loading module DDR, return code 21 from DMSRLD 
Invalid CMS command 

Hmmm, maybe did something wrong when installing the extension ...

Janne



-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Bruce Hayden
Sent: 1. joulukuuta 2010 15:02
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR multivolume tape as output

The pipe enabled DDR is in the DRPC package on the download page.  And FYI, 
PIPEDDR now supports this version of DDR as an alternative, including support 
of reading and writing to a filedef name.

On Wed, Dec 1, 2010 at 7:12 AM, David Boyes dbo...@sinenomine.net wrote:
 Another option would be to use the PIPE-enabled DDR (VM download 
 library, NOT PIPEDDR) and use normal SL processing (eg, specify the 
 list of volsers to use in a LABELDEF and then DDR | TAP1 SL ...

 At one point, IBM was going to ship that version of DDR as the standard.
 Haven't heard anything about that in a while... Any progress guys? 
 Adding this function, plus the CMS file stuff from CMSDDR would be ++good.

 -- db




--
Bruce Hayden
z/VM and Linux on System z ATS
IBM, Endicott, NY


Think green - keep it on the screen.
This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you. 

Re: DDR multivolume tape as output

2010-12-02 Thread Järvinen , Janne
 
Oops, my mistake. File corrupted during file transfer when uploading.
Now, testing

1. Att d1f * 181
2. DFSMSRM mount cat scratch0 (redev d1f

3. DDTEST1 DR A looks like this:
SY CONS
IN 123 DASD
OUTPUT PIPE
PROMPTS OFF
DUMP ALL   


4. pipe ddr ddrtest1 ddr a ! tape tap1 wtm  


HCPDDR696I VOLID READ IS 610RES 
DUMPING   610RES
DUMPING DATA  12/02/10 AT 09.49.54  GMT FROM 610RES 
INPUT CYLINDER EXTENTS  OUTPUT CYLINDER EXTENTS 
  START   STOP STARTSTOP
FPLTAP291E End of tape on TAP1  
FPLMSG003I ... Issued from stage 2 of pipeline 1
FPLMSG001I ... Running tape tap1 wtm  
HCPDDR226E Unexpected EOF while reading/writing to PIPE 
END OF JOB  

So I'm back in the original problem, how to get the following output tapes 
mounted ?



-Original Message-
From: Järvinen, Janne 
Sent: 2. joulukuuta 2010 10:16
To: 'The IBM z/VM Operating System'
Subject: RE: DDR multivolume tape as output


Hello,

Thanks for the tips. 
I'm not familiar using pipes but interested to try this.  
I downloaded the DRPC stuff.

ddr 
DMSMOD639E Error loading module DDR, return code 21 from DMSRLD 
Invalid CMS command 

Hmmm, maybe did something wrong when installing the extension ...

Janne



-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Bruce Hayden
Sent: 1. joulukuuta 2010 15:02
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR multivolume tape as output

The pipe enabled DDR is in the DRPC package on the download page.  And FYI, 
PIPEDDR now supports this version of DDR as an alternative, including support 
of reading and writing to a filedef name.

On Wed, Dec 1, 2010 at 7:12 AM, David Boyes dbo...@sinenomine.net wrote:
 Another option would be to use the PIPE-enabled DDR (VM download 
 library, NOT PIPEDDR) and use normal SL processing (eg, specify the 
 list of volsers to use in a LABELDEF and then DDR | TAP1 SL ...

 At one point, IBM was going to ship that version of DDR as the standard.
 Haven't heard anything about that in a while... Any progress guys? 
 Adding this function, plus the CMS file stuff from CMSDDR would be ++good.

 -- db




--
Bruce Hayden
z/VM and Linux on System z ATS
IBM, Endicott, NY


Think green - keep it on the screen.
This e-mail and any attachment is for authorised use by the intended 
recipient(s) only. It may contain proprietary material, confidential 
information and/or be subject to legal privilege. It should not be copied, 
disclosed to, retained or used by, any other party. If you are not an intended 
recipient then please promptly delete this e-mail and any attachment and all 
copies and inform the sender. Thank you. 

Re: z/VM 6.1, SSLSERV Question

2010-12-02 Thread Mark Wheeler


 

 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
snip 
 Btw, I don't see very much pressure being placed on z/VM to provide 
 client-side TLS support for homegrown RxSocket or Pipeline apps. I see 
 slightly more pressure for VM to provide user certificate-based single- 
 and two-factor authentication for TN3270E (and, inevitably, ftp and smtp).
 
 Alan Altmark
 

It would be nice if UFT(D) would support it.
 
Mark Wheeler
UnitedHealth Group

Re: RSU 6104?

2010-12-02 Thread Bruce Hayden
The RSU plans page (http://www.vm.ibm.com/service/rsu/rsuplan.html) was
updated yesterday to state that the 6104 RSU will be made available this
month.

Note that you can get notified of changes to any page on the z/VM web site
via the Notify Me link on the left side of most of the web pages.  Then
you will know when the RSU planning schedule is updated or when RSUs are
available.

On Wed, Dec 1, 2010 at 4:18 AM, Buettner, Wolfgang 
wolfgang.buett...@softwareag.com wrote:

  At first RSU 6104 was planned for July, then for November of this year.
 Meanwhile we have December ...
 Is there anybody at IBM who can tell about the latest plans?

 Not that we had actual problems, but RSU 6103 is from May (just two months
 after RSU 6102) and I have to keep our z/VM systems as up-to-date as
 any possible.

 Thank you,
 Wolfgang


 Software AG – Group Executive Board: Karl-Heinz Streibich
 (Vorsitzender/Chairman), Arnd Zinnhardt, Mark Edwards, David Broadbent,
 Josef Bommersbach, Dr. Wolfram Jost, Kamyar Niroumand, Ivo Totev

 Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany, –
 Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/
 Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), David
 Broadbent, Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/
 Chairman of the Supervisory Board: Dr. Andreas Bereczky - *
 http://www.softwareag.com* http://www.softwareag.com/




-- 
Bruce Hayden
z/VM and Linux on System z ATS
IBM, Endicott, NY


Re: z/VM 6.1, SSLSERV Question

2010-12-02 Thread Alan Altmark
On Thursday, 12/02/2010 at 08:15 EST, Mark Wheeler 
mwheele...@hotmail.com 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 TLS on the same port as the 
unsecured version.)

Further, UFT(D) in VM is not written to the VMCF/Pascal interface and so 
couldn't support it until CMS supports dynamic TLS for IUCV sockets.

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
alan_altm...@us.ibm.com
IBM Endicott


Re: RSU 6104?

2010-12-02 Thread Colleen Brown
From Susan Baloga at IBM:

The 6104RSU is in process now and should be available in the next few 
weeks. 

Colleen M Brown 
IBM z/VM and Related Products Development and Service 



From:
Bruce Hayden bjhay...@gmail.com
To:
IBMVM@LISTSERV.UARK.EDU
Date:
12/02/2010 08:26 AM
Subject:
Re: RSU 6104?
Sent by:
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU



The RSU plans page (http://www.vm.ibm.com/service/rsu/rsuplan.html) was 
updated yesterday to state that the 6104 RSU will be made available this 
month.

Note that you can get notified of changes to any page on the z/VM web site 
via the Notify Me link on the left side of most of the web pages.  Then 
you will know when the RSU planning schedule is updated or when RSUs are 
available.

On Wed, Dec 1, 2010 at 4:18 AM, Buettner, Wolfgang 
wolfgang.buett...@softwareag.com wrote:
At first RSU 6104 was planned for July, then for November of this year.
Meanwhile we have December ... 
Is there anybody at IBM who can tell about the latest plans?
 
Not that we had actual problems, but RSU 6103 is from May (just two months 
after RSU 6102) and I have to keep our z/VM systems as up-to-date as 
any possible.
 
Thank you,
Wolfgang
 

Software AG – Group Executive Board: Karl-Heinz Streibich 
(Vorsitzender/Chairman), Arnd Zinnhardt, Mark Edwards, David Broadbent, 
Josef Bommersbach, Dr. Wolfram Jost, Kamyar Niroumand, Ivo Totev 

Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany, – 
Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/ 
Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), David 
Broadbent, Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/ 
Chairman of the Supervisory Board: Dr. Andreas Bereczky - 
http://www.softwareag.com 




-- 
Bruce Hayden
z/VM and Linux on System z ATS
IBM, Endicott, NY




Re: z/VM 6.1, SSLSERV Question

2010-12-02 Thread Richard Troth
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.

-- R;   
Rick Troth
Velocity Software
http://www.velocitysoftware.com/





On Wed, Dec 1, 2010 at 11:43, Schuh, Richard rsc...@visa.com 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?

 Regards,
 Richard Schuh



  -Original Message-
  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/30/2010 at 06:39 EST, Schuh, Richard
  rsc...@visa.com
  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 has
  traced
   the SSLSERV and sees no traffic going through it; however, the
  connection to
   TPF is made and it is not secure. The ASSORTEDPARMS are coded as:
  
   ASSORTEDPARMS
 SECURELOCAL
 PROXYARP
 IGNOREREDIRECT
 FREELOWPORTS
   ENDASSORTEDPARMS
  
   What is the magic that will allow this to be done.
 
  None.  The description of SecureLocal is somewhat deficient.
  It applies only to loopback connections and only to sockets
  managed by the Pascal/VMCF socket interface.  The
  RxSocket/C/IUCV socket interface does not have support for SSL.
 
  Under normal circumstances, loopback connections for static
  SSL connections would be superfluous since the traffic never
  leaves the stack
  and the secured apps can't tell the difference.
  SecureLocal overrides
  that decision in case you have a stack that you want to use
  for testing the management and use of SSL.
 
  Alan Altmark
 
  z/VM and Linux on System z Consultant
  IBM System Lab Services and Training
  ibm.com/systems/services/labservices
  office: 607.429.3323
  alan_altm...@us.ibm.com
  IBM Endicott
 



Re: RSU 6104?

2010-12-02 Thread Buettner, Wolfgang
Bruce, Colleen,
 
  Thank you for your updates.
 
Meanwhile I've also got the original one which rose a bit later than my post 
here.
 
Wolfgang 


From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Colleen Brown
Sent: Thursday, December 02, 2010 2:30 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: RSU 6104?



From Susan Baloga at IBM: 

The 6104RSU is in process now and should be available in the next few weeks.   

Colleen M Brown   
IBM z/VM and Related Products Development and Service 



From:   Bruce Hayden bjhay...@gmail.com 
To: IBMVM@LISTSERV.UARK.EDU 
Date:   12/02/2010 08:26 AM 
Subject:Re: RSU 6104? 
Sent by:The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU






The RSU plans page (http://www.vm.ibm.com/service/rsu/rsuplan.html 
http://www.vm.ibm.com/service/rsu/rsuplan.html ) was updated yesterday to 
state that the 6104 RSU will be made available this month.

Note that you can get notified of changes to any page on the z/VM web site via 
the Notify Me link on the left side of most of the web pages.  Then you will 
know when the RSU planning schedule is updated or when RSUs are available.

On Wed, Dec 1, 2010 at 4:18 AM, Buettner, Wolfgang 
wolfgang.buett...@softwareag.com mailto:wolfgang.buett...@softwareag.com  
wrote: 
At first RSU 6104 was planned for July, then for November of this year. 
Meanwhile we have December ... 
Is there anybody at IBM who can tell about the latest plans? 
  
Not that we had actual problems, but RSU 6103 is from May (just two months 
after RSU 6102) and I have to keep our z/VM systems as up-to-date as any 
possible. 
  
Thank you, 
Wolfgang 
  

Software AG - Group Executive Board: Karl-Heinz Streibich 
(Vorsitzender/Chairman), Arnd Zinnhardt, Mark Edwards, David Broadbent, Josef 
Bommersbach, Dr. Wolfram Jost, Kamyar Niroumand, Ivo Totev 

Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt, Germany, - 
Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/ Management 
Board: Karl-Heinz Streibich (Vorsitzender/Chairman), David Broadbent, Dr. 
Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/ Chairman of the 
Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com 
http://www.softwareag.com/ 





-- 
Bruce Hayden
z/VM and Linux on System z ATS
IBM, Endicott, NY 




Re: z/VM 6.1, SSLSERV Question

2010-12-02 Thread Richard Troth
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 since long before UFT.  GZIP was there at the start.  Both of
these have some functionality on CMS, but not well integrated.  But we were
talking about SSL, not compression.  Sorry.

Negotiation was worked on, but has never made it into a follow-on RFC.
(Probably because there is no follow-on RFC ... yet.)  Authentication in UFT
suggests how TLS/SSL negotiation might be done because authentication was
always open and variable ... negotiated.

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.
hint hint)  The point is that UFT gives you RSCS-style transport without
adding more network topology.  If then you are behind a firewall, you might
not care to secure the UFT channels.  (Did he just say that?  He did!  I
can't believe he said that!)

-- R;   





On Thu, Dec 2, 2010 at 08:29, Alan Altmark alan_altm...@us.ibm.com wrote:

 On Thursday, 12/02/2010 at 08:15 EST, Mark Wheeler
 mwheele...@hotmail.com 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 TLS on the same port as the
 unsecured version.)

 Further, UFT(D) in VM is not written to the VMCF/Pascal interface and so
 couldn't support it until CMS supports dynamic TLS for IUCV sockets.

 Alan Altmark

 z/VM and Linux on System z Consultant
 IBM System Lab Services and Training
 ibm.com/systems/services/labservices
 office: 607.429.3323
 alan_altm...@us.ibm.com
 IBM Endicott



Re: z/VM 6.1, SSLSERV Question

2010-12-02 Thread Alan Altmark
On Thursday, 12/02/2010 at 09:32 EST, Richard Troth vmcow...@gmail.com 
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 challenges with SSL are many:
- Certificate updates without taking applications out of service
- Allowing different applications to use the same certificate
- Protecting a server certificate's private key
- Tying user certificates to VM user IDs so that people can be identified 
and two-factor authentication enabled
- Keeping user certificate private keys away from the users (think about 
it)
- Implementation of a flexible policy for the validation of incoming 
certificates
- Keeping up with advancements in the protocol and the introduction of new 
encryption suites
- Required industry and government certifications such as FIPS

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 the company's 
network?!?)  And that you all, in turn, would be squeezing IBM for a 
supported, manageable solution.

It's kind of scary, actually.  My biggest fear is that folks are trying to 
fly under the radar in the hopes of not being discovered and are taking 
too many undocumented or ill-understood risks.

But perhaps I am too paranoid.  Maybe these all just trivial transmissions 
of today's cafeteria lunch menu and cannot be used by some disgruntled or 
creative employee to discredit, steal, corrupt, or destroy your fave 
virtualization platform or the data it holds.

There are large corporations who are finally starting to look at z/VM 
management policies (incl. security) to ensure that they are mitigating 
the risks inherent in any virtualization strategy.  It's easy to say, 
We'll deal with that later.   Tick, tock, tick, tock.

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
alan_altm...@us.ibm.com
IBM Endicott


Re: DDR multivolume tape as output

2010-12-02 Thread Les Geer (607-429-3580)
Oops, my mistake. File corrupted during file transfer when uploading.
Now, testing

1. Att d1f * 181
2. DFSMSRM mount cat scratch0 (redev d1f

3. DDTEST1 DR A looks like this:
SY CONS

IN 123 DASD

OUTPUT PIPE

PROMPTS OFF

DUMP ALL



4. pipe ddr ddrtest1 ddr a ! tape tap1 wtm



HCPDDR696I VOLID READ IS 610RES

DUMPING   610RES

DUMPING DATA  12/02/10 AT 09.49.54  GMT FROM 610RES

INPUT CYLINDER EXTENTS  OUTPUT CYLINDER EXTENTS

  START   STOP STARTSTOP

FPLTAP291E End of tape on TAP1

FPLMSG003I ... Issued from stage 2 of pipeline 1

FPLMSG001I ... Running tape tap1 wtm

HCPDDR226E Unexpected EOF while reading/writing to PIPE

END OF JOB


So I'm back in the original problem, how to get the following output tapes
mounted ?

I do not think this will solve the problem, however, the original
attach command should be:

Att d1f * 181 multi


Best Regards,
Les Geer
IBM z/VM and Linux Development


Re: z/VM 6.1, SSLSERV Question

2010-12-02 Thread Colin Allinson
Alan Altmark alan_altm...@us.ibm.com 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 the company's 
 network?!?)  And that you all, in turn, would be squeezing IBM for a 
 supported, manageable solution.

 It's kind of scary, actually.  My biggest fear is that folks are trying 
to 
 fly under the radar in the hopes of not being discovered and are taking 
 too many undocumented or ill-understood risks.

 But perhaps I am too paranoid.  Maybe these all just trivial 
transmissions 
 of today's cafeteria lunch menu and cannot be used by some disgruntled 
or 
 creative employee to discredit, steal, corrupt, or destroy your fave 
 virtualization platform or the data it holds.

 There are large corporations who are finally starting to look at z/VM 
 management policies (incl. security) to ensure that they are mitigating 
 the risks inherent in any virtualization strategy.  It's easy to say, 
 We'll deal with that later.   Tick, tock, tick, tock.

Because of the very power of mainframe systems, the power of any Systems 
Programmer worth their salt makes them far too dangerous to have on-site - 
unless you really trust them. You can put all sorts of controls in place 
and make their job more difficult but, unless you take away all access 
that they need for their job, they can always get round any controls.

That is not to say that there should be no controls at all - the main ones 
should be to prevent accidental or negligent issues. To make it easier to 
do it right than wrong. 

A lot of people are flying just under the Radar - not with mal intent, but 
to achieve what needs to be done.

However, my company (along with many others) does have a strategy for 
dealing with this problem. Get rid of mainframe systems because we all 
KNOW that distributed systems handle these problems SO much better !!! In 
4-5 years the risk will have been eliminated (along with all of us). 

Colin Allinson


Re: DDR multivolume tape as output

2010-12-02 Thread Dick van der Sluiszen
It is very simple. Look to this ddr command file:
INPUT DASD VMLEF3   
OUTPUT   0181 TAPE 182 (COMPACT 
SYSPRINT CONS   
DUMP ALL

Now you only have to attach a scratch on 181 and 182. So mount a scratch 
on 
a real device  and attach it to your machine with vdev 181, also, mou
nt 
a scratch on rdev  and attach the rdev to your machine as 182.
If the tape on 181 is full, output will be continued to 182.
Also with dfsmsrm:
dfsmsrm mount vol vv (rdev  vdev 181 attach *
dfsmsrm mount vol ww (rdev  vdev 182 attach *

The volumes must be in the scratch pool you are using in your VM 
environment! 

After the mount simply give the command:
DDR DDRCOM FILE A (DDRCOM FILE is the name of the command file on the
 a-
disk this mostly your 191 minidisk).


Re: z/VM 6.1, SSLSERV Question

2010-12-02 Thread Alan Altmark
On Thursday, 12/02/2010 at 10:08 EST, Richard Troth vmcow...@gmail.com 
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.  hint 
hint)  
 The point is that UFT gives you RSCS-style transport without adding more 

 network topology.  If then you are behind a firewall, you might not care 
to 
 secure the UFT channels.  (Did he just say that?  He did!  I can't 
believe he 
 said that!) 

Bah, humbug.  You simply added a new network with the label UFT instead 
of NJE.

The problem with behind the firewall is that the firewall can appear to 
move since FW management isn't within your job description.  Further, 
encryption is there to protect the data from sniffers (legitimate or 
otherwise).  When the $10/hr network tech is diagnosing a problem, do you 
want him to have access to your 401K information while she's doing it? 

Hence the reason a data security policies may say,  All PII shall be 
encrypted when at rest or transmitted on a network.  No qualifiers and no 
escape clauses.  You have to file for any exception.

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
alan_altm...@us.ibm.com
IBM Endicott


Re: z/VM 6.1, SSLSERV Question

2010-12-02 Thread Richard Troth
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 nodes to define.  Topology.

Not saying either is better than the other.  Both have value and cost.  Both
bring the wonderful concepts of job submission and a file is not an
attachment to a world that did not have them.

We should fork this thread.  Or stop it.

-- R;   
Rick Troth
Velocity Software
http://www.velocitysoftware.com/





On Thu, Dec 2, 2010 at 10:26, Alan Altmark alan_altm...@us.ibm.com wrote:

 On Thursday, 12/02/2010 at 10:08 EST, Richard Troth vmcow...@gmail.com
 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.  hint
 hint)
  The point is that UFT gives you RSCS-style transport without adding more

  network topology.  If then you are behind a firewall, you might not care
 to
  secure the UFT channels.  (Did he just say that?  He did!  I can't
 believe he
  said that!)

 Bah, humbug.  You simply added a new network with the label UFT instead
 of NJE.

 The problem with behind the firewall is that the firewall can appear to
 move since FW management isn't within your job description.  Further,
 encryption is there to protect the data from sniffers (legitimate or
 otherwise).  When the $10/hr network tech is diagnosing a problem, do you
 want him to have access to your 401K information while she's doing it?

 Hence the reason a data security policies may say,  All PII shall be
 encrypted when at rest or transmitted on a network.  No qualifiers and no
 escape clauses.  You have to file for any exception.

 Alan Altmark

 z/VM and Linux on System z Consultant
 IBM System Lab Services and Training
 ibm.com/systems/services/labservices
 office: 607.429.3323
 alan_altm...@us.ibm.com
 IBM Endicott



Re: z/VM 6.1, SSLSERV Question

2010-12-02 Thread Schuh, Richard
Does anyone have a sample SSL/TLS client assembler program that uses the VMCF 
interface? And would you be willing to share it/ If so, it isn't a lost cause.

Regards, 
Richard Schuh 

 

 -Original Message-
 From: The IBM z/VM Operating System 
 [mailto:ib...@listserv.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 
 rsc...@visa.com
 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/SSL is available for any TCP/IP *server* 
 without regard to the interface being used.  I.e. an IUCV, C, 
 RxSocket or Pipeline server can be protected by the SECURE 
 parameter on the PORT statement. 
 However, there is no such support for clients.  If a 
 connection to a SECURE port (static) comes from an app on the 
 same stack AND the SecureLocal parm is specified, the stack 
 will treat it as it would an inbound external connection and 
 route the connection through the SSL server on behalf of the 
 *server* side only.
 
 For clients, only dynamic/negotiated TLS/SSL support is 
 available, and that is only via the VMCF/Pascal API.
 
 Btw, I don't see very much pressure being placed on z/VM to 
 provide client-side TLS support for homegrown RxSocket or 
 Pipeline apps.  I see slightly more pressure for VM to 
 provide user certificate-based single- and two-factor 
 authentication for TN3270E (and, inevitably, ftp and smtp).
 
 Alan Altmark
 
 z/VM and Linux on System z Consultant
 IBM System Lab Services and Training
 ibm.com/systems/services/labservices
 office: 607.429.3323
 alan_altm...@us.ibm.com
 IBM Endicott
 

Re: FTP Question

2010-12-02 Thread Bob Heerdink
Would you consider using another product, say Connect:Direct?  It can do 
this.

Bob


Re: z/VM 6.1, SSLSERV Question

2010-12-02 Thread Alan Ackerman
What command are you issuing on the CMS client?

Alan Ackerman