date:20111216

On Fri, 16 Dec 2011 14:57:14 -0600, Mike Schwab wrote:

>At least they only loose 1 birthday a lifetime.  Just think about all
>the people born on Feb 29th.

The 60th day of the year?  What's the big deal with that?

-- 
Tom Marchant

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

Re: Tapeless Solutions

2011-12-16 Thread Dennis Trojak

Well the TS7720 holds up to 1772TB according to the doco. Check out
 http://www-03.ibm.com/systems/storage/tape/ts7700/index.html for details.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Henke, George
Sent: Friday, December 16, 2011 2:36 PM
To: IBM-MAIN@bama.ua.edu
Subject: Tapeless Solutions

Does anyone know of an IBM completely tapeless solution and what it might cost?

I have heard of the TS7740, but it holds only 6 TB per draw.

We have 750 TB on tape.

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

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

Re: Tapeless Solutions

2011-12-16 Thread Ramiro Camposagrado

Yes... 
It is called the TS7720. We have three of them in a "Grid Configutation", I 
believe that each frame could accomodate up to 162 TB of storage (without 
compression). You should talk to your IBM rep for the exact specs.

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

Re: Imagine dealing with THIS in production

2011-12-16 Thread Mike Schwab

At least they only loose 1 birthday a lifetime.  Just think about all
the people born on Feb 29th.

On Fri, Dec 16, 2011 at 1:20 PM, Jonathan Goossen
 wrote:
> And what about the pour people who will loose a birthday?
>
> Thank you and have a Terrific day!
>
> Jonathan Goossen, ACG, CL
> For help with communication and leadership skills checkout Woodwinds
-- 
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...@bama.ua.edu with the message: INFO IBM-MAIN

Alain Leclerc/DGSIG est absent(e).

2011-12-16 Thread Alain Leclerc

Je serai absent(e) du  2011-12-16 au 2012-01-04.

Je répondrai à votre message dès mon retour.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Is there an SPF setting to turn CAPS ON like keyboard key?

In <1099194836526387.wa.paulgboulderaim@bama.ua.edu>, on
12/16/2011
   at 11:01 AM, Paul Gilmartin  said:

>But the code points that later became lower case

There were none that I know of[1] Those came in with, e.g., ASCII,
EBCDIC. Before that, all IBM computers other than the 7030 used either
a two digit code or a six bit code, with no lower case in either
case[2]

[1] Anybody know whether Stretch had code points for lower case?

[2] Pun deliberate.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Tapeless Solutions

2011-12-16 Thread Henke, George

Does anyone know of an IBM completely tapeless solution and what it might cost?

I have heard of the TS7740, but it holds only 6 TB per draw.

We have 750 TB on tape.



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

Re: WAIT ECB WITH 00 First Byte

In
<77142d37c0c3c34da0d7b1da7d7ca3459...@nwt-s-mbx2.rocketsoftware.com>,
on 12/16/2011
   at 06:09 PM, Bill Fairchild  said:

>The completion code (not post code) is placed in at least bits 2-31
>of the full word. 

I never noticed that piece of nomenclature before, but apparently it
goes back to the very early days; I found it in the old Control
Program Services manual. Thanks.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Determining MSUs

2011-12-16 Thread Ed Finnell

Maybe there's an updated version, that's just the first link I found.
 
 
In a message dated 12/16/2011 10:14:14 A.M. Central Standard Time,  
p...@voltage.com writes:

appear  to get the MIPS right.


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

Re: Is there an SPF setting to turn CAPS ON like keyboard key?

2011-12-16 Thread Gerhard Postpischil


On 12/16/2011 1:06 PM, Phil Smith wrote:

OK, trivia time:
What IBM device had *13* PF keys?


Not what you wanted, but on my 3277 I wrote a game that treated 
Test-Request as PFK 0.


Gerhard Postpischil
Bradford, VT

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

Re: Calling all "crypto" gurus

2011-12-16 Thread Ford Prefect

>From LOOKAT:

   *CSFM125I* *CRYPTOGRAPHY* *-* *LIMITED* *CPU-BASED* *SERVICES*
*ARE* *AVAILABLE.*

 *Explanation:* This is an informational message. ICSF is up and remains
started. Only SHA-1 and SHA-2 services are available. The DES CPACF feature
code is not enabled.

On Fri, Dec 16, 2011 at 2:46 PM, David Booher wrote:

> Yes, my CSF will run:
>
> 13.46.16 STC01522  $HASP373 CSF  STARTED
> 13.46.17 STC01522  CSFM607I A CKDS KEY STORE POLICY IS NOT DEFINED.
> 13.46.17 STC01522  CSFM607I A PKDS KEY STORE POLICY IS NOT DEFINED.
> 13.46.17 STC01522  CSFM610I GRANULAR KEYLABEL ACCESS CONTROL IS DISABLED.
> 13.46.17 STC01522  CSFM611I XCSFKEY EXPORT CONTROL FOR AES IS DISABLED.
> 13.46.17 STC01522  CSFM611I XCSFKEY EXPORT CONTROL FOR DES IS DISABLED.
> 13.46.17 STC01522  CSFM101E PKA KEY DATA SET, CSF.CSFPKDS IS NOT
>  INITIALIZED.
> 13.46.17 STC01522  CSFM506I CRYPTOGRAPHY - THERE IS NO ACCESS TO ANY
>  CRYPTOGRAPHIC COPROCESSORS OR ACCELERATORS.
> 13.46.17 STC01522  CSFM012I NO ACCESS CONTROL AVAILABLE FOR CRYPTOZ
>  RESOURCES. ICSF PKCS11 SERVICES DISABLED.
> 13.46.18 STC01522  CSFM009I NO ACCESS CONTROL AVAILABLE FOR ICSF SERVICES
>  OR KEYS
> 13.46.18 STC01522 *CSFM122I PKA SERVICES WERE NOT ENABLED DURING ICSF
>  INITIALIZATION.
> 13.46.18 STC01522  CSFM001I ICSF INITIALIZATION COMPLETE
> 13.46.18 STC01522  CSFM125I CRYPTOGRAPHY - LIMITED CPU-BASED SERVICES ARE
>  AVAILABLE.
>
> But just was "limited" ciphers I have available is the question.
>
> Dave
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Tom Simons
> Sent: Friday, December 16, 2011 12:09 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Calling all "crypto" gurus
>
> ICSF will work on the z800 without crypto hardware. From the document
> mentioned below:
>  "ICSF is a software component of z/OS providing cryptographic support
> either in its own
>  software routines or through access to the cryptographic hardware
> available on the
>  platform."
> We used ICSF's software routines for AES encryption, back when the crypto
> hardware only supported DES.
>
> See "ICSF Version and FMID Cross Ref_110909.pdf" from this webpage:
> http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD103782.
>
> On Fri, Dec 16, 2011 at 9:26 AM, Finch, Steve (ES - Mainframe) <
> steve.fi...@hp.com> wrote:
>
> > David Booher wrote:
> >
> > >I have a z800 with no cryptographic processor installed.  I'm attempting
> > to
> >
> > use the SECURE SSL port on DB2 to establish a connection.  I've pretty
> much
> >
> > stepped thru the entire RedPaper on this.  It seems the client (running
> >
> > IBM's gskit) doesn't want to negotiate a cipher to use with the
> mainframe.
> >
> > I know since I don't have a crypto processor, I'm a very limited in what
> I
> >
> > can support on the mainframe.  By doing an SSLSCAN, I do see that the
> >
> > mainframe does offer two specific ciphers to be used, however the client
> >
> > doesn't want to negotiate those ciphers.
> >
> >
> >
> > Without a CCF (cryptographic processor) on a z800, you are very limited
> in
> >
> > what ciphers you can use. You can use 'NULL-SHA' and 'NULL-MD5' ciphers.
> >
> > That's it. Your client must be configured to accept and use one of these
> > two
> >
> > ciphers to connect with DB2's Secure SSL on your z800.
> >
> >
> >
> > However a "good" client would not support 'NULL-SHA' and 'NULL-MD5'
> > ciphers.
> >
> > They are not really secure. It's not doing encryption
> >
> >
> >
> > In short without a CCF (cryptographic processor) on your z800, you cannot
> > do
> >
> > "good" SSL.
> >
> >
> >
> >
> >
> > Steve Finch
> >
> >
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

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

Re: Calling all "crypto" gurus

Thanks for that info.  I started the server and got: 

14.11.07 STC01527  GSK01009I Cryptographic status
Algorithm   HardwareSoftware
DES --  56
3DES--  --
AES --  --
RC2 --  40
RC4 --  40
RSA Encrypt --4096
RSA Sign--4096
DSS --1024
SHA-1  160 160
SHA-2  256 512


But I think I found my answer ( I have NO AES or 3DES): 

DB2 Version 9.7 for Linux, UNIX, and Windows
Supported cipher suites
During an SSL handshake, the client and server negotiate which cipher suite to 
use to exchange data. A cipher suite is a set of algorithms that are used to 
provide authentication, encryption, and data integrity.

The DB2(r) database system uses GSKit running in FIPS mode to provide SSL 
support. GSKit supports the following cipher suites:
TLS_RSA_WITH_AES_256_CBC_SHA 
TLS_RSA_WITH_AES_128_CBC_SHA 
TLS_RSA_WITH_3DES_EDE_CBC_SHA 
The name of each cipher suite specifies the algorithms that it uses for 
authentication, encryption, and data integrity checking. For example, the 
cipher suite TLS_RSA_WITH_AES_256_CBC_SHA uses RSA for authentication; AES 
256-bit and CBC for encryption algorithms; and SHA-1 for the hash function for 
data integrity.

During the SSL handshake, the DB2 database system automatically picks the 
strongest cipher suite supported by both the client and the server. If you want 
the server to accept only one or more specific cipher suites, you can set the 
ssl_cipherspecs configuration parameter to any of the following values:
TLS_RSA_WITH_AES_256_CBC_SHA 
TLS_RSA_WITH_AES_128_CBC_SHA 
TLS_RSA_WITH_3DES_EDE_CBC_SHA 
Any combination of these three values. To set multiple values, separate each 
value by a comma but do not put a space between the values. 
Null. In this case, the strongest available algorithm is automatically picked.


Thanks to all for your valuable input!
Dave


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Richard L Peurifoy
Sent: Friday, December 16, 2011 1:58 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calling all "crypto" gurus


If you setup the GSK server, you can issue the following command:

F GSKSRVR,DISPLAY CRYPTO

to list the ciphers available.

On my system (z10 with crypto cards enabled for SSL acceleration it shows:

  GSKSRVR   GSK01009I Cryptographic status
  Algorithm   HardwareSoftware
  DES 56  56
  3DES   168 168
  AES256 256
  RC2 -- 128
  RC4 -- 128
  RSA Encrypt   20484096
  RSA Sign--4096
  DSS --1024
  SHA-1  160 160
  SHA-2  512 512

--
Richard

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

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

Re: Imagine dealing with THIS in production

2011-12-16 Thread J R

"pour people"?  -  what, you mean like bartenders?  

 > Date: Fri, 16 Dec 2011 13:20:54 -0600
> From: jonathan.goos...@assurant.com
> Subject: Re: Imagine dealing with THIS in production
> To: IBM-MAIN@bama.ua.edu
> 
> And what about the pour people who will loose a birthday?
> 
> Thank you and have a Terrific day!
> 
> Jonathan Goossen, ACG, CL
> For help with communication and leadership skills checkout Woodwinds 
> Toastmasters
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Re: Calling all "crypto" gurus

2011-12-16 Thread Richard L Peurifoy


On 12/16/2011 1:47 PM, David Booher wrote:

Yes, my CSF will run:

13.46.16 STC01522  $HASP373 CSF  STARTED
13.46.17 STC01522  CSFM607I A CKDS KEY STORE POLICY IS NOT DEFINED.
13.46.17 STC01522  CSFM607I A PKDS KEY STORE POLICY IS NOT DEFINED.
13.46.17 STC01522  CSFM610I GRANULAR KEYLABEL ACCESS CONTROL IS DISABLED.
13.46.17 STC01522  CSFM611I XCSFKEY EXPORT CONTROL FOR AES IS DISABLED.
13.46.17 STC01522  CSFM611I XCSFKEY EXPORT CONTROL FOR DES IS DISABLED.
13.46.17 STC01522  CSFM101E PKA KEY DATA SET, CSF.CSFPKDS IS NOT
  INITIALIZED.
13.46.17 STC01522  CSFM506I CRYPTOGRAPHY - THERE IS NO ACCESS TO ANY
  CRYPTOGRAPHIC COPROCESSORS OR ACCELERATORS.
13.46.17 STC01522  CSFM012I NO ACCESS CONTROL AVAILABLE FOR CRYPTOZ
  RESOURCES. ICSF PKCS11 SERVICES DISABLED.
13.46.18 STC01522  CSFM009I NO ACCESS CONTROL AVAILABLE FOR ICSF SERVICES
  OR KEYS
13.46.18 STC01522 *CSFM122I PKA SERVICES WERE NOT ENABLED DURING ICSF
  INITIALIZATION.
13.46.18 STC01522  CSFM001I ICSF INITIALIZATION COMPLETE
13.46.18 STC01522  CSFM125I CRYPTOGRAPHY - LIMITED CPU-BASED SERVICES ARE
  AVAILABLE.

But just was "limited" ciphers I have available is the question.


If you setup the GSK server, you can issue the following command:

F GSKSRVR,DISPLAY CRYPTO

to list the ciphers available.

On my system (z10 with crypto cards enabled for SSL acceleration it shows:

 GSKSRVR   GSK01009I Cryptographic status
 Algorithm   HardwareSoftware
 DES 56  56
 3DES   168 168
 AES256 256
 RC2 -- 128
 RC4 -- 128
 RSA Encrypt   20484096
 RSA Sign--4096
 DSS --1024
 SHA-1  160 160
 SHA-2  512 512

--
Richard

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

Re: Calling all "crypto" gurus

Yes, my CSF will run: 

13.46.16 STC01522  $HASP373 CSF  STARTED
13.46.17 STC01522  CSFM607I A CKDS KEY STORE POLICY IS NOT DEFINED.
13.46.17 STC01522  CSFM607I A PKDS KEY STORE POLICY IS NOT DEFINED.
13.46.17 STC01522  CSFM610I GRANULAR KEYLABEL ACCESS CONTROL IS DISABLED.
13.46.17 STC01522  CSFM611I XCSFKEY EXPORT CONTROL FOR AES IS DISABLED.
13.46.17 STC01522  CSFM611I XCSFKEY EXPORT CONTROL FOR DES IS DISABLED.
13.46.17 STC01522  CSFM101E PKA KEY DATA SET, CSF.CSFPKDS IS NOT
 INITIALIZED.
13.46.17 STC01522  CSFM506I CRYPTOGRAPHY - THERE IS NO ACCESS TO ANY
 CRYPTOGRAPHIC COPROCESSORS OR ACCELERATORS.
13.46.17 STC01522  CSFM012I NO ACCESS CONTROL AVAILABLE FOR CRYPTOZ
 RESOURCES. ICSF PKCS11 SERVICES DISABLED.
13.46.18 STC01522  CSFM009I NO ACCESS CONTROL AVAILABLE FOR ICSF SERVICES
 OR KEYS
13.46.18 STC01522 *CSFM122I PKA SERVICES WERE NOT ENABLED DURING ICSF
 INITIALIZATION.
13.46.18 STC01522  CSFM001I ICSF INITIALIZATION COMPLETE
13.46.18 STC01522  CSFM125I CRYPTOGRAPHY - LIMITED CPU-BASED SERVICES ARE
 AVAILABLE.

But just was "limited" ciphers I have available is the question. 

Dave

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Tom Simons
Sent: Friday, December 16, 2011 12:09 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calling all "crypto" gurus

ICSF will work on the z800 without crypto hardware. From the document
mentioned below:
  "ICSF is a software component of z/OS providing cryptographic support
either in its own
  software routines or through access to the cryptographic hardware
available on the
  platform."
We used ICSF's software routines for AES encryption, back when the crypto
hardware only supported DES.

See "ICSF Version and FMID Cross Ref_110909.pdf" from this webpage:
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD103782.

On Fri, Dec 16, 2011 at 9:26 AM, Finch, Steve (ES - Mainframe) <
steve.fi...@hp.com> wrote:

> David Booher wrote:
>
> >I have a z800 with no cryptographic processor installed.  I'm attempting
> to
>
> use the SECURE SSL port on DB2 to establish a connection.  I've pretty much
>
> stepped thru the entire RedPaper on this.  It seems the client (running
>
> IBM's gskit) doesn't want to negotiate a cipher to use with the mainframe.
>
> I know since I don't have a crypto processor, I'm a very limited in what I
>
> can support on the mainframe.  By doing an SSLSCAN, I do see that the
>
> mainframe does offer two specific ciphers to be used, however the client
>
> doesn't want to negotiate those ciphers.
>
>
>
> Without a CCF (cryptographic processor) on a z800, you are very limited in
>
> what ciphers you can use. You can use 'NULL-SHA' and 'NULL-MD5' ciphers.
>
> That's it. Your client must be configured to accept and use one of these
> two
>
> ciphers to connect with DB2's Secure SSL on your z800.
>
>
>
> However a "good" client would not support 'NULL-SHA' and 'NULL-MD5'
> ciphers.
>
> They are not really secure. It's not doing encryption
>
>
>
> In short without a CCF (cryptographic processor) on your z800, you cannot
> do
>
> "good" SSL.
>
>
>
>
>
> Steve Finch
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: Calling all "crypto" gurus

Tom Simons wrote, in part:
>ICSF will work on the z800 without crypto hardware.

Right, but that wasn't his question. He's asking about specific SSL/TLS 
algorithms.
--
...phsiii


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

Re: Imagine dealing with THIS in production

2011-12-16 Thread Steve Comstock


On 12/16/2011 12:20 PM, Jonathan Goossen wrote:

And what about the pour people who will loose a birthday?

 

Whoa! Is it happy hour already?




Thank you and have a Terrific day!

Jonathan Goossen, ACG, CL
For help with communication and leadership skills checkout Woodwinds
Toastmasters



IBM Mainframe Discussion List  wrote on 12/15/2011
03:04:48 PM:


From: zMan
To: IBM-MAIN@bama.ua.edu
Date: 12/15/2011 03:30 PM
Subject: Imagine dealing with THIS in production
Sent by: IBM Mainframe Discussion List



http://travelonthedollar.com/2011/06/28/samoa-will-lose-a-day-in-december/


Even things like billing a hotel stay that spans the change could be
interesting!
--
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



This e-mail message and all attachments transmitted with it may
contain legally privileged and/or confidential information intended
solely for the use of the addressee(s). If the reader of this
message is not the intended recipient, you are hereby notified that
any reading, dissemination, distribution, copying, forwarding or
other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please
notify the sender immediately and delete this message and all
copies and backups thereof. Thank you.

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




--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.html

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

Re: Calling all "crypto" gurus

I'm assuming the DB2 client on the laptop is attempting to negotiate a "good" 
cipher for its SSL.  I can't seem to find any doc on what ciphers it does 
support, but NULL-SHA and NULL-MD5 doesn't appear to be ones it does.

It's too bad I can't get my ciphers out of my z800, even if its software 
emulated (at the cost of CPU). 

Dave


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Finch, Steve (ES - Mainframe)
Sent: Friday, December 16, 2011 11:27 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calling all "crypto" gurus

David Booher wrote:

>I have a z800 with no cryptographic processor installed.  I'm attempting to

use the SECURE SSL port on DB2 to establish a connection.  I've pretty much

stepped thru the entire RedPaper on this.  It seems the client (running

IBM's gskit) doesn't want to negotiate a cipher to use with the mainframe.

I know since I don't have a crypto processor, I'm a very limited in what I

can support on the mainframe.  By doing an SSLSCAN, I do see that the

mainframe does offer two specific ciphers to be used, however the client

doesn't want to negotiate those ciphers.



Without a CCF (cryptographic processor) on a z800, you are very limited in

what ciphers you can use. You can use 'NULL-SHA' and 'NULL-MD5' ciphers.

That's it. Your client must be configured to accept and use one of these two

ciphers to connect with DB2's Secure SSL on your z800.



However a "good" client would not support 'NULL-SHA' and 'NULL-MD5' ciphers.

They are not really secure. It's not doing encryption



In short without a CCF (cryptographic processor) on your z800, you cannot do

"good" SSL.





Steve Finch




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

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

Re: Imagine dealing with THIS in production

2011-12-16 Thread Jonathan Goossen

And what about the pour people who will loose a birthday?

Thank you and have a Terrific day!

Jonathan Goossen, ACG, CL
For help with communication and leadership skills checkout Woodwinds 
Toastmasters



IBM Mainframe Discussion List  wrote on 12/15/2011 
03:04:48 PM:

> From: zMan 
> To: IBM-MAIN@bama.ua.edu
> Date: 12/15/2011 03:30 PM
> Subject: Imagine dealing with THIS in production
> Sent by: IBM Mainframe Discussion List 
> 
> 
http://travelonthedollar.com/2011/06/28/samoa-will-lose-a-day-in-december/
> 
> Even things like billing a hotel stay that spans the change could be
> interesting!
> -- 
> zMan -- "I've got a mainframe and I'm not afraid to use it"
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html


This e-mail message and all attachments transmitted with it may
contain legally privileged and/or confidential information intended
solely for the use of the addressee(s). If the reader of this
message is not the intended recipient, you are hereby notified that
any reading, dissemination, distribution, copying, forwarding or
other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please
notify the sender immediately and delete this message and all
copies and backups thereof. Thank you.

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

Re: Heads up APAR OA35970 & CA-Top Secret

2011-12-16 Thread Joe D'Alessandro

The ACF2 folks sent out a HIPER warning to all subscribers about this issue 
already.  The APAR applies to zOS v1.12 and v1.13 according to them.  The 
informational APAR is RI38633 for ACF2 v14 but the solution applies to v15 as 
well.  There are a few definitions that need to be made to ensure that the SAF 
call is approved.
regards, Joe D'Alessandro   

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

Re: Calling all "crypto" gurus

David Booher :

Wow. Opaque and obdurate. However:
"this usually indicates a cipher suite could not be negotiated between the 
client and the server during the cipher suite exchange phase in the SSL 
handshake" suggests to me that it isn't that the client doesn't want to 
negotiate, it's that the client is too stupid/backlevel to negotiate any of the 
ciphers that z/OS supports.

BTW, the note about "exportable cipher suites" has to do with crypto that's 
embargoed as a "munition"; I'm assuming you're in the US and this doesn't apply 
to you. OTOH, if you don't have the right Feature Codes enabled, maybe you're 
not supporting some of the more common ciphers. Hmm.

Have you talked to your CE about this, making sure the right Feature Codes are 
enabled?
--
...phsiii


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

Re: Calling all "crypto" gurus

2011-12-16 Thread Tom Simons

ICSF will work on the z800 without crypto hardware. From the document
mentioned below:
  "ICSF is a software component of z/OS providing cryptographic support
either in its own
  software routines or through access to the cryptographic hardware
available on the
  platform."
We used ICSF's software routines for AES encryption, back when the crypto
hardware only supported DES.

See "ICSF Version and FMID Cross Ref_110909.pdf" from this webpage:
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD103782.

On Fri, Dec 16, 2011 at 9:26 AM, Finch, Steve (ES - Mainframe) <
steve.fi...@hp.com> wrote:

> David Booher wrote:
>
> >I have a z800 with no cryptographic processor installed.  I'm attempting
> to
>
> use the SECURE SSL port on DB2 to establish a connection.  I've pretty much
>
> stepped thru the entire RedPaper on this.  It seems the client (running
>
> IBM's gskit) doesn't want to negotiate a cipher to use with the mainframe.
>
> I know since I don't have a crypto processor, I'm a very limited in what I
>
> can support on the mainframe.  By doing an SSLSCAN, I do see that the
>
> mainframe does offer two specific ciphers to be used, however the client
>
> doesn't want to negotiate those ciphers.
>
>
>
> Without a CCF (cryptographic processor) on a z800, you are very limited in
>
> what ciphers you can use. You can use 'NULL-SHA' and 'NULL-MD5' ciphers.
>
> That's it. Your client must be configured to accept and use one of these
> two
>
> ciphers to connect with DB2's Secure SSL on your z800.
>
>
>
> However a "good" client would not support 'NULL-SHA' and 'NULL-MD5'
> ciphers.
>
> They are not really secure. It's not doing encryption
>
>
>
> In short without a CCF (cryptographic processor) on your z800, you cannot
> do
>
> "good" SSL.
>
>
>
>
>
> Steve Finch
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
>

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

Re: WAIT ECB WITH 00 First Byte

2011-12-16 Thread Bill Fairchild

The completion code (not post code) is placed in at least bits 2-31 of the full 
word.  So it is true that the code is in the lower 3 bytes, and it is also true 
that the code is in the lower 4 bytes (FSVO "4").

Comments from within the IHAECB mapping macro:
*/*02*  An ECB can be posted with a two-part completion code:
*/*02*   -  Bits 1 through 7 are posted by data management   
*/* and teleprocessing functions.  This part of the  
*/* completion code is described in the mapping of the   
*/* ECB control block.   
*/*02*   -  Bits 8 through 31 are posted by all system components
*/* and by user-written programs.  When a task is abnormally 
*/* terminated, the ECB for the task is posted with an   
*/* abnormal system completion code in bits 8 through 19,
*/* or with an abnormal user completion code in  
*/* bits 20 through 31.  

>From the Authorized Assembler Services book:
Bits 2 through 31 are set to the specified completion code.

Bill Fairchild

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Shmuel Metz (Seymour J.)
Sent: Friday, December 16, 2011 10:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: WAIT ECB WITH 00 First Byte

In ,
on 12/16/2011
   at 07:51 AM, "McKown, John"  said:

>The "post code" is placed in the lower 3 bytes by POST, where the RB 
>address is placed by the WAIT.

Lower 4 bytes ;-)

>I will bet that the contents are undisturbed. If so, this means that 
>those ECBs will have Bit 0 set to '1'b, Bit 1 set to '0'b, and the RB 
>address in the lower 3 bytes

How much did you want to bet?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

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

Re: Is there an SPF setting to turn CAPS ON like keyboard key?

2011-12-16 Thread zMan

On Fri, Dec 16, 2011 at 9:34 AM, Roger Bowler  wrote:
 after which the SPF assignments just look arbitrary.

True. But they became part of the CUA standard, which also mapped to
Microsoft standards pretty closely! From such strange beginnings...
-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

P.S. Let's not start a digression on use of "Microsoft" and
"standards" together, eh?

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

Re: Is there an SPF setting to turn CAPS ON like keyboard key?

OK, trivia time:
What IBM device had *13* PF keys?
--
...phsiii

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

Re: Calling all "crypto" gurus

Steve Finch wrote:
>Without a CCF (cryptographic processor) on a z800, you are very limited in
>what ciphers you can use. You can use 'NULL-SHA' and 'NULL-MD5' ciphers.
>That's it. Your client must be configured to accept and use one of these two
>ciphers to connect with DB2's Secure SSL on your z800.

I do NOT want to start a flamewar here - that's absolutely not my intention - 
but I don't believe that (or at least don't want to).

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDIQFjAA&url=ftp%3A%2F%2Fftp.boulder.ibm.com%2Fs390%2Fzos%2Fracf%2Fpdf%2Fr07_system_ssL_and_zseries_crypto.pdf&ei=6YPrTo_8HMrw0gG9su2mCQ&usg=AFQjCNEjnzvCUihmimNk4r7bjN3Exo_tSQ
 on slides 21 and 22 sure *seems* to say that it will do other algorithms in 
software.

Steve, can you cite something supporting your contention? It would certainly 
fit the symptoms!
--
...phsiii

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

Re: Calling all "crypto" gurus

2011-12-16 Thread Finch, Steve (ES - Mainframe)

David Booher wrote:

>I have a z800 with no cryptographic processor installed.  I'm attempting to

use the SECURE SSL port on DB2 to establish a connection.  I've pretty much

stepped thru the entire RedPaper on this.  It seems the client (running

IBM's gskit) doesn't want to negotiate a cipher to use with the mainframe.

I know since I don't have a crypto processor, I'm a very limited in what I

can support on the mainframe.  By doing an SSLSCAN, I do see that the

mainframe does offer two specific ciphers to be used, however the client

doesn't want to negotiate those ciphers.



Without a CCF (cryptographic processor) on a z800, you are very limited in

what ciphers you can use. You can use 'NULL-SHA' and 'NULL-MD5' ciphers.

That's it. Your client must be configured to accept and use one of these two

ciphers to connect with DB2's Secure SSL on your z800.



However a "good" client would not support 'NULL-SHA' and 'NULL-MD5' ciphers.

They are not really secure. It's not doing encryption



In short without a CCF (cryptographic processor) on your z800, you cannot do

"good" SSL.





Steve Finch




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

Re: Calling all "crypto" gurus

2011-12-16 Thread Scott Ford

David:
 
This reads as if there is a product missinginteresting

Scott J Ford
Software Engineer
http://www.identityforge.com
 
 


 From: David Booher 
To: IBM-MAIN@bama.ua.edu 
Sent: Friday, December 16, 2011 10:58 AM
Subject: Re: Calling all "crypto" gurus
 
This is the error from the mainframe: 

BPXF024I (TCPIP) Dec 16 15:49:41 TTLS 33620154 : 09:49:41 TCPIP 855
EZD1283I TTLS Event GRPID: 0003 ENVID:  CONNID: 0002F628
RC:    0 Connection Init
EZD1287I TTLS Error RC:  402 Initial Handshake 854
  JOBNAME: UKXADIST RULE: UKXASecureSever
  USERID: ADCDMST GRPID: 0003 ENVID: 000D CONNID: 0002F628
BPXF024I (TCPIP) Dec 16 15:49:41 TTLS 33620154 : 09:49:41 TCPIP 856
EZD1282I TTLS Start GRPID: 0003 ENVID: 000D CONNID: 0002F628
Initial Handshake ACTIONS: UKXASecureGrpAct UKXASecureEnvAct **N/A**
HS-Server
BPXF024I (TCPIP) Dec 16 15:49:41 TTLS 33620154 : 09:49:41 TCPIP 857
EZD1283I TTLS Event GRPID: 0003 ENVID: 000D CONNID: 0002F628
RC:  402 Initial Handshake  7ED0A118
BPXF024I (TCPIP) Dec 16 15:49:41 TTLS 33620154 : 09:49:41 TCPIP 858
EZD1286I TTLS Error GRPID: 0003 ENVID: 000D CONNID: 0002F628
JOBNAME: UKXADIST USERID: ADCDMST RULE: UKXASecureSever  RC:  402
Initial Handshake  7ED0A118
BPXF024I (TCPIP) Dec 16 15:49:41 TTLS 33620154 : 09:49:41 TCPIP 859
EZD1283I TTLS Event GRPID: 0003 ENVID: 000D CONNID: 0002F628
RC:    0 Connection Close  7ED0A118

The RedBook I'm using states: 

"When a secure SSL connection is being established between a client and a 
server and the z/OS System SSL return code, 402 is encountered, this usually 
indicates a cipher suite could not be negotiated between the client and the 
server during the cipher suite exchange phase in the SSL handshake.  A common 
cause for this to occur is the client is trying to negotiate a cipher suite 
which is defined as exportable.  In this situation, verify that the proper 
FMIDs to support the encryption level are installed." 

Cryptic indeed - pardon the pun. 

db

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

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

Re: Is there an SPF setting to turn CAPS ON like keyboard key?

2011-12-16 Thread Paul Gilmartin

On Fri, 16 Dec 2011 10:14:48 -0500, Shmuel Metz (Seymour J.) wrote:
>
>Assemblers supported macros well before IBM formally defined a
>character set with lower case.
> 
But the code points that later became lower case could be used
in syntactic contexts where case never mattered, including
arguments to macros.

>>perhaps better than HLASM does.
>
>What's the issue with HLA?
> 
HLASM changed the behavior, introducing incompatibilities.  Then
it provided a MACROCASECOMP/NOMACROCASECOMP option.
But they violated their own conventions.  For all (most?) other
...COMP/NO...COMP options, ...COMP provides behavior compatible
with earlier assemblers; NO...COMP enables incompatible behavior.
MACROCASECOMP/NOMACROCASECOMP reverses the convention.
I have an example where the same source program assembles
identically with IEV90 and HLASM/NOMACROCASECOMP, but gets
errors with HLASM/MACROCASECOMP.

AFAIK, IBM has supplied no macros with MACROCASECOMP
dependencies.

-- gil

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

Re: z/OS 1.13 ASCENV incompatible change in Assembler

2011-12-16 Thread John Gilmore

MXG's "asmguy" wrote

 The SYSSTATE macro is an assembler directive - it sets
   a flag that tells any macros that support AR mode
   (Access Register, used for cross memory access) to use
   their AR mode compatible expansion. Macros that don't
   have an AR mode expansion used to ignore this because
   they had nothing to do, and it's always the coder's
   responsibility to make sure that when those non-AR
   compatible macros are executed, that the system is not
   in AR mode.  This is similar to switching back and forth
   from 24-bit to 31-bit mode: some macros can't tolerate
   31-bit mode.  Nothing has really changed though; it is
   still the coders responsibility to make sure the system
   is not in AR mode and macros that can't tolerate AR mode
   still can't, except now IBM is requiring the coder to
   explicitly set SYSSTATE to indicate to the assembler
   that the system is not in AR mode.
   Of course this is all very silly because the assembler
   can't know ahead of time that the system is or isn't in
   AR mode.  So regardless of whether or not SYSSTATE is
   coded this way the system still could be in AR mode,

I am with Rob Scott in this matter.   Much of this gentleman's comment
seems to me to either 1) "very silly", or 2) uninformed, or 3) both.

It is of course true that the HLASM cannot know that a routine it is
assembling will be executed, wholly or in part, in AR Mode  (In
passing let me not that AR mode has many uses that that do not have to
do with CMS [overloaded acronym].)   There is indeed much else that
the HLASM cannot know at assembly time about what the execution-time
environment in which some piece of code it is assembling will be.

It is, however, the business of the programmer who wrote the routine
being assembled to know these things, and to inform the assembler
about them.

On occasion, of course, that environment is not fully determined.  I
have been working this morning on a routine I have designed to be
usable under both a TCB and an SRB; and this is necessarily reflected,
sometimes tediously, in my code and testing regime.

The notion that since the HLASM cannot know something without being
informed of it makes informing it moot or silly is itself silly or
worse.

John Gilmore - Ashland, MA 01721 - USA

On 12/16/11, Rob Scott  wrote:
> Barry
>
> Maybe I am strange - but I welcome the new stricter approach to the SYSSTATE
> by IBM macros.
>
> Anything that can flag up a potential problem in my code due to my lack of
> care of the declared environment seems very useful to me.
>
> Rob Scott
> Lead Developer
> Rocket Software
> 275 Grove Street * Newton, MA 02466-2272 * USA
> Tel: +1.617.614.2305
> Email: rsc...@rs.com
> Web: www.rocketsoftware.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
> Of Barry Merrill
> Sent: 16 December 2011 15:20
> To: IBM-MAIN@bama.ua.edu
> Subject: z/OS 1.13 ASCENV incompatible change in Assembler
>
> Change 29.280 -z/OS 1.13 ASM ERROR when assembling ASMTAPEE/MXGTMNT:
> ASMTAPEE"YOU SPECIFIED ASCENV=AR OR ANY ON THE SYSSTATE MACRO.
> Dec 15, 2011 THE OPEN MACRO SUPPORTS ONLY ASCENV=P."
>But there is NO NEED to ASM a new load module under 1.13;
>your currently executing MXGTMNT module works just fine!
>
>   -This IBM note (migration guide) is the ONLY clue of the
>incompatible change, which impacts OPEN/CLOSE macros, but
>doesn't mention any by name:
> DFSMSdfp: Accommodate 64-bit & AR mode rules enforcement
> in DFSMS macros; required if you have code that invokes
> DFSMS macros (but not all!).  Before z/OS V1R13, many
> DFSMS macros that did not support 64-bit or AR mode did
> not react to being invoked in 64-bit or AR mode, and
> generated code that might have been invalid in 64-bit or
> AR mode. Starting with z/OS V1R13, these macros are
> changed to issue an assembly-time message and suppress
> expansion if they are invoked in 64-bit or AR mode."
>
>   -But as noted above, you didn't really need to ASM.  Now,
>from MXG's "asmguy", his comments on this change:
>
> Nothing is going to happen to an existing site using
> MXGTMNT and in fact the modification I have to make for
> this does not result in any change to the executable
> code.
>
> The SYSSTATE macro is an assembler directive - it sets
> a flag that tells any macros that support AR mode
> (Access Register, used for cross me

Re: zFS parm sysplex=filesys

2011-12-16 Thread Lizette Koehler

> > [ snip ]
> >
> > Sorry, I am still a little confused on this issue.  So if I could get
> a little more clarification
> >
> > I am running with SYSPLEX(NO) in my BPXPRMxx member.
> >
> > Does this mean with z/OS V1.13 I will have to change to SYSPLEX(YES)
> in order to have zFS files
> > mounted?  Or will zFS still mount even with SYSPLEX(NO)
> 
> My conclusion is that if BPXPRMxx contains SYSPLEX(NO), then the setting
of the
> SYSPLEX parm in your zFS parm member is irrelevant.  zFS will perceive
each image in
> the sysplex as a stand-alone system for its purposes.  We'll see early
next year when
> we start on z/OS 1.13, because we also run with SYSPLEX(NO) in BPXPRMxx.
> 
> However, *IF* you change to SYSPLEX(YES) in BPXPRMxx, *THEN* you will have
to
> specify SYSPLEX=FILESYS in your zFS parm member ON EVERY SYSTEM in your
> sysplex, regardless of z/OS level, for z/OS 1.13's zFS to initialize.
> 
> -jc-


 Thanks,  that is much more clear.  However I will YMMV the process.  ;-) 

Lizette

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

Re: WAIT ECB WITH 00 First Byte

2011-12-16 Thread McKown, John

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.)
> Sent: Friday, December 16, 2011 10:02 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: WAIT ECB WITH 00 First Byte
> 
> In ,
> on 12/16/2011
>at 07:51 AM, "McKown, John"  said:
> 
> >The "post code" is placed in the lower 3 bytes by POST, where the RB
> >address is placed by the WAIT.
> 
> Lower 4 bytes ;-)
> 
> >I will bet that the contents are undisturbed. If so, this means that
> >those ECBs will have Bit 0 set to '1'b, Bit 1 set to '0'b, and the
> >RB address in the lower 3 bytes
> 
> How much did you want to bet?

I'll bet "a hardy well done!" 

>  
> -- 
>  Shmuel (Seymour J.) Metz, SysProg and JOAT

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

 

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

Re: WAIT ECB WITH 00 First Byte

In ,
on 12/16/2011
   at 07:51 AM, "McKown, John"  said:

>The "post code" is placed in the lower 3 bytes by POST, where the RB
>address is placed by the WAIT.

Lower 4 bytes ;-)

>I will bet that the contents are undisturbed. If so, this means that
>those ECBs will have Bit 0 set to '1'b, Bit 1 set to '0'b, and the
>RB address in the lower 3 bytes

How much did you want to bet?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: zFS parm sysplex=filesys

2011-12-16 Thread Chase, John

> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Lizette Koehler
> 
> [ snip ]
> 
> Sorry, I am still a little confused on this issue.  So if I could get
a little more clarification
> 
> I am running with SYSPLEX(NO) in my BPXPRMxx member.
> 
> Does this mean with z/OS V1.13 I will have to change to SYSPLEX(YES)
in order to have zFS files
> mounted?  Or will zFS still mount even with SYSPLEX(NO)

My conclusion is that if BPXPRMxx contains SYSPLEX(NO), then the setting
of the SYSPLEX parm in your zFS parm member is irrelevant.  zFS will
perceive each image in the sysplex as a stand-alone system for its
purposes.  We'll see early next year when we start on z/OS 1.13, because
we also run with SYSPLEX(NO) in BPXPRMxx.

However, *IF* you change to SYSPLEX(YES) in BPXPRMxx, *THEN* you will
have to specify SYSPLEX=FILESYS in your zFS parm member ON EVERY SYSTEM
in your sysplex, regardless of z/OS level, for z/OS 1.13's zFS to
initialize.

-jc-

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

Re: IEBCOPY in z/OS 1.13

In <45e5f2f45d7878458ee5ca679697335502e25...@usdaexch01.kbm1.loc>, on
12/16/2011
   at 07:27 AM, "Staller, Allan"  said:

>Also (at the time) IEBCOPY would run in a region much smaller than 1
>meg. ISTR 64K, but am not positive.

That would not have been in the same timeframe as a 1 MiB conditional
GETMAIN. As I recall, the OS/360 SysGen process generated different
Linkage Editor control statements for IEBCOPY depending on whether it
was for PCP, MFT or MVT. Given the design points for OS/360, your
64KiB recollection is certainly likely to within a factor of 2 either
way. That is, I'm sure that the required partition/region it wasn't
less than 32KiB or greater than 128 KiB.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Is there an SPF setting to turn CAPS ON like keyboard key?

2011-12-16 Thread Anne & Lynn Wheeler

ibm-m...@snacons.com (Roger Bowler) writes:
> This would have been the IBM 3277 Data Entry keyboard. Page 25 of
> GA27-2749-5_3270descr_Nov75.pdf at bitsavers shows two forms of the
> Data Entry keyboard both having PF1-PF5 keys neatly hidden amongst the
> other keys in the top right area of the keyboard. The 78-key
> typewriter keyboard and the operator console keyboard were the ones

re:
http://www.garlic.com/~lynn/2011p.html#84

oops, missed that.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: Is there an SPF setting to turn CAPS ON like keyboard key?

2011-12-16 Thread Anne & Lynn Wheeler

paulgboul...@aim.com (Paul Gilmartin) writes:
> Or do utilities not count as applications?  Define "application".  Again,
> I'm confident that at least one very old application would accept
> (define "accept") lower case, at least in comments.  And very old
> assemblers tolerated lower case in macro arguments, perhaps better
> than HLASM does.  (But only as long as assemblers supported macros.)

CTSS on ibm7094 used 2741s with upper/lower case ... and at least CTSS
document formating utility "runoff" regularly had lowercase.
http://en.wikipedia.org/wiki/Compatible_Time-Sharing_System
http://en.wikipedia.org/wiki/IBM_2741

some of the ctss people went to 5th flr, 545 tech sq and did multics.
others went to the science center on the 4th flr and did cp67/cms (first
cp40/cms on specially modified 360/40 with virtual memory which then
morphs into cp67/cms when standard virtual memory became available with
360/67). misc. past posts mentioning science center
http://www.garlic.com/~lynn/subtopic.html#545tech

ctss runoff 
http://en.wikipedia.org/wiki/RUNOFF

was ported to cms as "script". GML (for initials of three inventors) was
invented at the science center in 1969 and GML tag processing was added
to script (in addition to the runoff "dot" controls). misc.  past posts
mentioning gml
http://www.garlic.com/~lynn/submain.html#sgml

a decade later, gml mophs into ISO standard sgml ... and another decade,
sgml morphs into html
http://infomesh.net/html/history/early

one of the first mainstream corporate manuals moved to script was
principles of operation. the actual document was the called the
architecture redbook (for distribution in red 3-ring manuals).  script
conditional control governed whether the full redbook was formated or
just the principles of operation subsection.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: z/OS 1.13 ASCENV incompatible change in Assembler

2011-12-16 Thread Rob Scott

Barry

Maybe I am strange - but I welcome the new stricter approach to the SYSSTATE by 
IBM macros.

Anything that can flag up a potential problem in my code due to my lack of care 
of the declared environment seems very useful to me. 

Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Barry Merrill
Sent: 16 December 2011 15:20
To: IBM-MAIN@bama.ua.edu
Subject: z/OS 1.13 ASCENV incompatible change in Assembler

Change 29.280 -z/OS 1.13 ASM ERROR when assembling ASMTAPEE/MXGTMNT:
ASMTAPEE"YOU SPECIFIED ASCENV=AR OR ANY ON THE SYSSTATE MACRO.
Dec 15, 2011 THE OPEN MACRO SUPPORTS ONLY ASCENV=P."
   But there is NO NEED to ASM a new load module under 1.13;
   your currently executing MXGTMNT module works just fine!

  -This IBM note (migration guide) is the ONLY clue of the
   incompatible change, which impacts OPEN/CLOSE macros, but
   doesn't mention any by name:
DFSMSdfp: Accommodate 64-bit & AR mode rules enforcement
in DFSMS macros; required if you have code that invokes
DFSMS macros (but not all!).  Before z/OS V1R13, many
DFSMS macros that did not support 64-bit or AR mode did
not react to being invoked in 64-bit or AR mode, and
generated code that might have been invalid in 64-bit or
AR mode. Starting with z/OS V1R13, these macros are
changed to issue an assembly-time message and suppress
expansion if they are invoked in 64-bit or AR mode."

  -But as noted above, you didn't really need to ASM.  Now,
   from MXG's "asmguy", his comments on this change:

Nothing is going to happen to an existing site using
MXGTMNT and in fact the modification I have to make for
this does not result in any change to the executable
code.

The SYSSTATE macro is an assembler directive - it sets
a flag that tells any macros that support AR mode
(Access Register, used for cross memory access) to use
their AR mode compatible expansion. Macros that don't
have an AR mode expansion used to ignore this because
they had nothing to do, and it's always the coder's
responsibility to make sure that when those non-AR
compatible macros are executed, that the system is not
in AR mode.  This is similar to switching back and forth
from 24-bit to 31-bit mode: some macros can't tolerate
31-bit mode.  Nothing has really changed though; it is
still the coders responsibility to make sure the system
is not in AR mode and macros that can't tolerate AR mode
still can't, except now IBM is requiring the coder to
explicitly set SYSSTATE to indicate to the assembler
that the system is not in AR mode.
Of course this is all very silly because the assembler
can't know ahead of time that the system is or isn't in
AR mode.  So regardless of whether or not SYSSTATE is
coded this way the system still could be in AR mode,
OPEN/CLOSE will still expand the same way, and if the
system really is in AR mode OPEN/CLOSE will abend when
executed.
So the bottom line is that nothing has changed except
our need to do something for no reason at all.

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

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

Re: Calling all "crypto" gurus

This is the error from the mainframe: 

BPXF024I (TCPIP) Dec 16 15:49:41 TTLS 33620154 : 09:49:41 TCPIP 855
EZD1283I TTLS Event GRPID: 0003 ENVID:  CONNID: 0002F628
RC:0 Connection Init
EZD1287I TTLS Error RC:  402 Initial Handshake 854
  JOBNAME: UKXADIST RULE: UKXASecureSever
  USERID: ADCDMST GRPID: 0003 ENVID: 000D CONNID: 0002F628
BPXF024I (TCPIP) Dec 16 15:49:41 TTLS 33620154 : 09:49:41 TCPIP 856
EZD1282I TTLS Start GRPID: 0003 ENVID: 000D CONNID: 0002F628
Initial Handshake ACTIONS: UKXASecureGrpAct UKXASecureEnvAct **N/A**
HS-Server
BPXF024I (TCPIP) Dec 16 15:49:41 TTLS 33620154 : 09:49:41 TCPIP 857
EZD1283I TTLS Event GRPID: 0003 ENVID: 000D CONNID: 0002F628
RC:  402 Initial Handshake  7ED0A118
BPXF024I (TCPIP) Dec 16 15:49:41 TTLS 33620154 : 09:49:41 TCPIP 858
EZD1286I TTLS Error GRPID: 0003 ENVID: 000D CONNID: 0002F628
JOBNAME: UKXADIST USERID: ADCDMST RULE: UKXASecureSever  RC:  402
Initial Handshake  7ED0A118
BPXF024I (TCPIP) Dec 16 15:49:41 TTLS 33620154 : 09:49:41 TCPIP 859
EZD1283I TTLS Event GRPID: 0003 ENVID: 000D CONNID: 0002F628
RC:0 Connection Close  7ED0A118

The RedBook I'm using states: 

"When a secure SSL connection is being established between a client and a 
server and the z/OS System SSL return code, 402 is encountered, this usually 
indicates a cipher suite could not be negotiated between the client and the 
server during the cipher suite exchange phase in the SSL handshake.  A common 
cause for this to occur is the client is trying to negotiate a cipher suite 
which is defined as exportable.  In this situation, verify that the proper 
FMIDs to support the encryption level are installed." 

Cryptic indeed - pardon the pun. 

db

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

Re: z/OS 1.13 ASCENV incompatible change in Assembler

2011-12-16 Thread Don Poitras

Barry Merrill wrote:
> So the bottom line is that nothing has changed except
> our need to do something for no reason at all.

We only had to add 431 SYSSTATE calls to 64-bit SAS. :)

-- 
Don Poitras - zSeries R & D  -  SAS Institute Inc. -  SAS Campus Drive 
mailto:sas...@sas.com   (919)531-5637  Fax:677- Cary, NC 27513

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

Re: Is there an SPF setting to turn CAPS ON like keyboard key?

2011-12-16 Thread Eric Bielefeld


Thanks Roger.  I knew someone would remember the 5 PFK keyboards.

Eric Bielefeld
Sr. Systems Programmer
IBM Global Services Division
Dubuque, Iowa


- Original Message - 
From: "Roger Bowler" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Friday, December 16, 2011 8:34 AM
Subject: Re: Is there an SPF setting to turn CAPS ON like keyboard key?


This would have been the IBM 3277 Data Entry keyboard. Page 25 of 
GA27-2749-5_3270descr_Nov75.pdf at bitsavers shows two forms of the Data 
Entry keyboard both having PF1-PF5 keys neatly hidden amongst the other 
keys in the top right area of the keyboard. The 78-key typewriter keyboard 
and the operator console keyboard were the ones with the more familiar 
block of 12 PF keys to the right. When you look at the pictures on page 25 
you can see the reason why SPF assigns PF7/8 to ScrollUp/Down and PF10/11 
to ScrollLeft/Right -- the PF7/PF8, PF10/PF11 keys are in a block adjacent 
to the Up/Down, Left/Right arrow keys so it's easy to remember. Of course 
this logic went out of the window when they switched to 3278 terminals 
with the PF keys along the top, after which the SPF assignments just look 
arbitrary.


Roger Bowler
Hercules "the people's mainframe"


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

Re: Calling all "crypto" gurus

David Booher wrote:
>From other posts I've seen on the list, the initialization of the CKDS and 
>PKDS all fail with a return code of 12.  My question is:  Can you still run 
>CSF with empty datasets and no crypto processor and still expect it to offer 
>any SSL ciphers?

Yes. SSL has nothing to do with CKDS/PKDS - it has to do with certificates.

>Regarding the client:  by client, I meant DB2 connect running on a laptop.  My 
>previous sslscan indicated only a few ciphers were "preferred", but I don't 
>know how to get the DB2 client on the laptop to request one of those 
>ciphers.what a mess!

Ah. So maybe your DB2 connect machine isn't using a properly signed certificate.

What are the symptoms you're seeing? Is there any kind of error message?
--
...phsiii


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

Re: Is there an SPF setting to turn CAPS ON like keyboard key?

In <5925490962292924.wa.paulgboulderaim@bama.ua.edu>, on
12/15/2011
   at 07:16 PM, Paul Gilmartin  said:

>(   o but I haven't an ancient IEBGENER around to verify.
>o and IIRC you dislike IEBGENER, so perhaps you won't count it.)

I've been known to hold my nose and use it.

>Or do utilities not count as applications?

I'd certainly count Script as an application.

>(But only as long as assemblers supported macros.)

Assemblers supported macros well before IBM formally defined a
character set with lower case.

>perhaps better than HLASM does.

What's the issue with HLA?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Calling all "crypto" gurus

>From other posts I've seen on the list, the initialization of the CKDS and 
>PKDS all fail with a return code of 12.  My question is:  Can you still run 
>CSF with empty datasets and no crypto processor and still expect it to offer 
>any SSL ciphers? 

Regarding the client:  by client, I meant DB2 connect running on a laptop.  My 
previous sslscan indicated only a few ciphers were "preferred", but I don't 
know how to get the DB2 client on the laptop to request one of those 
ciphers.what a mess! 

db


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Phil Smith
Sent: Friday, December 16, 2011 9:08 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Calling all "crypto" gurus

David Booher wrote:
>I have a z800 with no cryptographic processor installed.  I'm attempting to 
>use the SECURE SSL port on DB2 to establish a connection.  I've pretty much 
>stepped thru the entire RedPaper on this.  It seems the client (running IBM's 
>gskit) doesn't want to negotiate a cipher to use with the mainframe.  I know 
>since I don't have a crypto processor, I'm a very limited in what I can 
>support on the mainframe.  By doing an SSLSCAN, I do see that the mainframe 
>does offer two specific ciphers to be used, however the client doesn't want to 
>negotiate those ciphers.

As RS notes, you don't need crypto hardware to use SSL - only to use it rapidly.

But "the client ... doesn't want to negotiate a cipher" really bothers me. 
That's how SSL/TLS work. What does the client suggest? Not using SSL? Using a 
specific cipher? Tin cans and string (SECURE string, mind you)??? It doesn't 
really sound to me like z/OS is the problem here.
--
...phsiii

Phil Smith III
p...@voltage.com
Voltage Security, Inc.
www.voltage.com
(703) 476-4511 (home office)
(703) 568-6662 (cell)


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

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

Re: zFS parm sysplex=filesys

2011-12-16 Thread Lizette Koehler

> Walter and John,
> Thanks for the good suggestions for improved messages on a successful
migration
> health check run.   I will pass them along.
> 
> The indication that the check did pass (I hope) would be enough to let you
know that
> the migration action didn't affect you, even if the message wording could
be improved.

Sorry, I am still a little confused on this issue.  So if I could get a
little more clarification

I am running with SYSPLEX(NO) in my BPXPRMxx member.

Does this mean with z/OS V1.13 I will have to change to SYSPLEX(YES) in
order to have zFS files mounted?  Or will zFS still mount even with
SYSPLEX(NO)

Lizette

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

z/OS 1.13 ASCENV incompatible change in Assembler

2011-12-16 Thread Barry Merrill

Change 29.280 -z/OS 1.13 ASM ERROR when assembling ASMTAPEE/MXGTMNT:
ASMTAPEE"YOU SPECIFIED ASCENV=AR OR ANY ON THE SYSSTATE MACRO.
Dec 15, 2011 THE OPEN MACRO SUPPORTS ONLY ASCENV=P."
   But there is NO NEED to ASM a new load module under 1.13;
   your currently executing MXGTMNT module works just fine!

  -This IBM note (migration guide) is the ONLY clue of the
   incompatible change, which impacts OPEN/CLOSE macros, but
   doesn't mention any by name:
DFSMSdfp: Accommodate 64-bit & AR mode rules enforcement
in DFSMS macros; required if you have code that invokes
DFSMS macros (but not all!).  Before z/OS V1R13, many
DFSMS macros that did not support 64-bit or AR mode did
not react to being invoked in 64-bit or AR mode, and
generated code that might have been invalid in 64-bit or
AR mode. Starting with z/OS V1R13, these macros are
changed to issue an assembly-time message and suppress
expansion if they are invoked in 64-bit or AR mode."

  -But as noted above, you didn't really need to ASM.  Now,
   from MXG's "asmguy", his comments on this change:

Nothing is going to happen to an existing site using
MXGTMNT and in fact the modification I have to make for
this does not result in any change to the executable
code.

The SYSSTATE macro is an assembler directive - it sets
a flag that tells any macros that support AR mode
(Access Register, used for cross memory access) to use
their AR mode compatible expansion. Macros that don't
have an AR mode expansion used to ignore this because
they had nothing to do, and it's always the coder's
responsibility to make sure that when those non-AR
compatible macros are executed, that the system is not
in AR mode.  This is similar to switching back and forth
from 24-bit to 31-bit mode: some macros can't tolerate
31-bit mode.  Nothing has really changed though; it is
still the coders responsibility to make sure the system
is not in AR mode and macros that can't tolerate AR mode
still can't, except now IBM is requiring the coder to
explicitly set SYSSTATE to indicate to the assembler
that the system is not in AR mode.
Of course this is all very silly because the assembler
can't know ahead of time that the system is or isn't in
AR mode.  So regardless of whether or not SYSSTATE is
coded this way the system still could be in AR mode,
OPEN/CLOSE will still expand the same way, and if the
system really is in AR mode OPEN/CLOSE will abend when
executed.
So the bottom line is that nothing has changed except
our need to do something for no reason at all.

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

Re: Determining MSUs

Ed Finnell wrote:
>I've used Theirry Falissard's MIPS thingy for about 15 yrs.

Hm. That seems wrong for current machines, based on the fact that it reports 
171 MSUs on a 1631-MSU box (the comment about "I did not verify whether it is 
still OK for recent 9672 machines..." is also a bit worrisome!). It does appear 
to get the MIPS right.
--
...phsiii


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

Re: Calling all "crypto" gurus

David Booher wrote:
>I have a z800 with no cryptographic processor installed.  I'm attempting to 
>use the SECURE SSL port on DB2 to establish a connection.  I've pretty much 
>stepped thru the entire RedPaper on this.  It seems the client (running IBM's 
>gskit) doesn't want to negotiate a cipher to use with the mainframe.  I know 
>since I don't have a crypto processor, I'm a very limited in what I can 
>support on the mainframe.  By doing an SSLSCAN, I do see that the mainframe 
>does offer two specific ciphers to be used, however the client doesn't want to 
>negotiate those ciphers.

As RS notes, you don't need crypto hardware to use SSL - only to use it rapidly.

But "the client ... doesn't want to negotiate a cipher" really bothers me. 
That's how SSL/TLS work. What does the client suggest? Not using SSL? Using a 
specific cipher? Tin cans and string (SECURE string, mind you)??? It doesn't 
really sound to me like z/OS is the problem here.
--
...phsiii

Phil Smith III
p...@voltage.com
Voltage Security, Inc.
www.voltage.com
(703) 476-4511 (home office)
(703) 568-6662 (cell)


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

Re: Is there an SPF setting to turn CAPS ON like keyboard key?

2011-12-16 Thread Roger Bowler

This would have been the IBM 3277 Data Entry keyboard. Page 25 of 
GA27-2749-5_3270descr_Nov75.pdf at bitsavers shows two forms of the Data Entry 
keyboard both having PF1-PF5 keys neatly hidden amongst the other keys in the 
top right area of the keyboard. The 78-key typewriter keyboard and the operator 
console keyboard were the ones with the more familiar block of 12 PF keys to 
the right. When you look at the pictures on page 25 you can see the reason why 
SPF assigns PF7/8 to ScrollUp/Down and PF10/11 to ScrollLeft/Right -- the 
PF7/PF8, PF10/PF11 keys are in a block adjacent to the Up/Down, Left/Right 
arrow keys so it's easy to remember. Of course this logic went out of the 
window when they switched to 3278 terminals with the PF keys along the top, 
after which the SPF assignments just look arbitrary.

Roger Bowler
Hercules "the people's mainframe"

On Thu, 15 Dec 2011 18:18:52 -0600, Eric Bielefeld  
wrote:

>I guess to be honest I don't remember if it was a 3277.  I do remember that
>it had 5 PFKs.  I beleive they were on the keyboard itself and you had to
>push another key with the letter key that had the PFK function on it.  I
>remember being very happy when I got a different terminal that had the PFK
>pad on the side with 12 of them.
>
>Eric Bielefeld
>Sr. Systems Programmer
>IBM Global Services Division
>Dubuque, Iowa
>
>
>- Original Message -
>From: "Anne & Lynn Wheeler" 
>Newsgroups: bit.listserv.ibm-main
>To: 
>Sent: Thursday, December 15, 2011 5:35 PM
>Subject: Re: Is there an SPF setting to turn CAPS ON like keyboard key?
>
>
>> eric-ibmm...@wi.rr.com (Eric Bielefeld) writes:
>>> I remember the first 3277 I used.  When we were converting from VS1 to
>>> MVS 3.7, and actually had ISPF, it was a real pain as there were only
>>> 5 PFKs.  I quickly learned to change PF4 & 5 to UP and DOWN so at
>>> least I could scroll.
>>>
>>
>> are you sure it was a real 3277? pg. 25 shows 3277&3275 keyboard layouts
>> (two w/o any pfkey and two with 12 pfkeys to right side):
>> http://bitsavers.trailing-edge.com/pdf/ibm/3270/GA27-2749-5_3270descr_Nov75.pdf

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

Re: FW: Calling all "crypto" gurus

2011-12-16 Thread R.S.

W dniu 2011-12-16 15:08, David Booher pisze:

== cross=posted on DB2-L ==

Hi,

I have a z800 with no cryptographic processor installed. I'm attempting to use
the SECURE SSL port on DB2 to establish a connection. I've pretty much stepped
thru the entire RedPaper on this. It seems the client (running IBM's gskit)
doesn't want to negotiate a cipher to use with the mainframe. I know since I
don't have a crypto processor, I'm a very limited in what I can support on the
mainframe. By doing an SSLSCAN, I do see that the mainframe does offer two
specific ciphers to be used, however the client doesn't want to negotiate those
ciphers.

Crypto hardware is not required for SSL.
First, you should check your TCP/IP configuration, actually TN3270.

--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax
+48 (22) 829 00 33, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88.
Wedug stanu na dzie 01.01.2011 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.346.696 zotych.

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

Re: WAIT ECB WITH 00 First Byte

On Fri, 16 Dec 2011 07:14:21 -0600, Donald Likens wrote:

>I see this situation in a locked up (waiting forever) environment. 
>I have no idea how it gets set this way. I have decided to do it 
>another way.

Previously, On Wed, 14 Dec 2011 22:59:37 -0600, Donald Likens wrote:

>I know that an ECB's first byte is x'80' if waiting and x'40' if posted 
>but what does X'00' mean. When I zero out the ECB I zero out the 
>whole word. This ECB has a PRB in it.

If you were waiting and you saw in a dump that the first byte of the 
ECB was zero, that means that someone zeroed the byte when they 
shouldn't have.

If you have an ECB with the wait and post bits off and an RB address 
in it, the wait bit must have been zeroed after the WAIT was issued 
and POST must not have been issued.

-- 
Tom Marchant

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

Re: WAIT ECB WITH 00 First Byte

On Fri, 16 Dec 2011 07:34:35 -0600, Tom Marchant  
wrote:

>On Fri, 16 Dec 2011 00:30:52 +0200, Binyamin Dissen wrote:
>
>>AFAIK multi-ecb WAIT (for example, 5 ECBs, count of 1) does not reset the
>>additional ECB's when the count is reached.
>
>Not sure what you mean by this, Binyamin.
>
>My understanding, which might be incorrect or incomplete, is that WAIT sets
>the wait bits, stores the RB address in the ECBs, sets the wait count in the
>RB and puts the task in a wait state.  At that point, isn't WAIT finished?
>
>POST sets the post bit, clears the wait bit, decrements the wait count if it
>is greater than zero, then if it is zero, makes the task dispatchable.
>The ECBs are not reset.

I should have said, POST sets the post bit, if the wait bit is set, clears the 
wait bit, decrements the wait count in the RB if the wait count is greater 
than zero, then if it is zero, it makes the task dispatchable.

Similarly, if the post bit in an ECB is set, WAIT does not set the wait bit. 
Also, the wait count is set to the count specified minus the number of ECBs 
that were found to have the post bit already set, but not less than zero. 
If the wait count is not zero, the task is put into a wait state.

Just my understanding.

--
Tom Marchant

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

FW: Calling all "crypto" gurus

== cross=posted on DB2-L ==

Hi,

I have a z800 with no cryptographic processor installed.  I'm attempting to use 
the SECURE SSL port on DB2 to establish a connection.  I've pretty much stepped 
thru the entire RedPaper on this.  It seems the client (running IBM's gskit) 
doesn't want to negotiate a cipher to use with the mainframe.  I know since I 
don't have a crypto processor, I'm a very limited in what I can support on the 
mainframe.  By doing an SSLSCAN, I do see that the mainframe does offer two 
specific ciphers to be used, however the client doesn't want to negotiate those 
ciphers.

I'm wondering if I have any options to get this connection to handshake and 
complete.  Any suggestions would be appreciated.
Here's the sslscan output of what the mainframe is saying:

   _
   ___ ___| |___  ___ __ _ _ __
  / __/ __| / __|/ __/ _` | '_ \
  \__ \__ \ \__ \ (_| (_| | | | |
  |___/___/_|___/\___\__,_|_| |_|

  Version 1.8.2-win
 http://www.titania.co.uk
Copyright Ian Ventura-Whiting 2009
Compiled against OpenSSL 0.9.8m 25 Feb 2010

Testing SSL server 10.10.180.58 on port 9012

  Supported Server Cipher(s):
FailedSSLv2  168 bits  DES-CBC3-MD5
FailedSSLv2   56 bits  DES-CBC-MD5
FailedSSLv2  128 bits  IDEA-CBC-MD5
FailedSSLv2   40 bits  EXP-RC2-CBC-MD5
FailedSSLv2  128 bits  RC2-CBC-MD5
FailedSSLv2   40 bits  EXP-RC4-MD5
FailedSSLv2  128 bits  RC4-MD5
Rejected  SSLv3  256 bits  ADH-AES256-SHA
Rejected  SSLv3  256 bits  DHE-RSA-AES256-SHA
Rejected  SSLv3  256 bits  DHE-DSS-AES256-SHA
Rejected  SSLv3  256 bits  AES256-SHA
Rejected  SSLv3  128 bits  ADH-AES128-SHA
Rejected  SSLv3  128 bits  DHE-RSA-AES128-SHA
Rejected  SSLv3  128 bits  DHE-DSS-AES128-SHA
Rejected  SSLv3  128 bits  AES128-SHA
Rejected  SSLv3  168 bits  ADH-DES-CBC3-SHA
Rejected  SSLv3   56 bits  ADH-DES-CBC-SHA
Rejected  SSLv3   40 bits  EXP-ADH-DES-CBC-SHA
Rejected  SSLv3  128 bits  ADH-RC4-MD5
Rejected  SSLv3   40 bits  EXP-ADH-RC4-MD5
Rejected  SSLv3  168 bits  EDH-RSA-DES-CBC3-SHA
Accepted  SSLv3   56 bits  EDH-RSA-DES-CBC-SHA
Rejected  SSLv3   40 bits  EXP-EDH-RSA-DES-CBC-SHA
Rejected  SSLv3  168 bits  EDH-DSS-DES-CBC3-SHA
Rejected  SSLv3   56 bits  EDH-DSS-DES-CBC-SHA
Rejected  SSLv3   40 bits  EXP-EDH-DSS-DES-CBC-SHA
Rejected  SSLv3  168 bits  DES-CBC3-SHA
Accepted  SSLv3   56 bits  DES-CBC-SHA
Rejected  SSLv3   40 bits  EXP-DES-CBC-SHA
Rejected  SSLv3  128 bits  IDEA-CBC-SHA
FailedSSLv3   40 bits  EXP-RC2-CBC-MD5
Rejected  SSLv3  128 bits  RC4-SHA
Rejected  SSLv3  128 bits  RC4-MD5
FailedSSLv3   40 bits  EXP-RC4-MD5
Accepted  SSLv30 bits  NULL-SHA
Accepted  SSLv30 bits  NULL-MD5
Rejected  TLSv1  256 bits  ADH-AES256-SHA
Rejected  TLSv1  256 bits  DHE-RSA-AES256-SHA
Rejected  TLSv1  256 bits  DHE-DSS-AES256-SHA
Rejected  TLSv1  256 bits  AES256-SHA
Rejected  TLSv1  128 bits  ADH-AES128-SHA
Rejected  TLSv1  128 bits  DHE-RSA-AES128-SHA
Rejected  TLSv1  128 bits  DHE-DSS-AES128-SHA
Rejected  TLSv1  128 bits  AES128-SHA
Rejected  TLSv1  168 bits  ADH-DES-CBC3-SHA
Rejected  TLSv1   56 bits  ADH-DES-CBC-SHA
Rejected  TLSv1   40 bits  EXP-ADH-DES-CBC-SHA
Rejected  TLSv1  128 bits  ADH-RC4-MD5
Rejected  TLSv1   40 bits  EXP-ADH-RC4-MD5
Rejected  TLSv1  168 bits  EDH-RSA-DES-CBC3-SHA
Accepted  TLSv1   56 bits  EDH-RSA-DES-CBC-SHA
Rejected  TLSv1   40 bits  EXP-EDH-RSA-DES-CBC-SHA
Rejected  TLSv1  168 bits  EDH-DSS-DES-CBC3-SHA
Rejected  TLSv1   56 bits  EDH-DSS-DES-CBC-SHA
Rejected  TLSv1   40 bits  EXP-EDH-DSS-DES-CBC-SHA
Rejected  TLSv1  168 bits  DES-CBC3-SHA
Accepted  TLSv1   56 bits  DES-CBC-SHA
Rejected  TLSv1   40 bits  EXP-DES-CBC-SHA
Rejected  TLSv1  128 bits  IDEA-CBC-SHA
FailedTLSv1   40 bits  EXP-RC2-CBC-MD5
Rejected  TLSv1  128 bits  RC4-SHA
Rejected  TLSv1  128 bits  RC4-MD5
FailedTLSv1   40 bits  EXP-RC4-MD5
Accepted  TLSv10 bits  NULL-SHA
Accepted  TLSv10 bits  NULL-MD5

  Prefered Server Cipher(s):
SSLv3   56 bits  DES-CBC-SHA
TLSv1   56 bits  DES-CBC-SHA

Thanks,
David Booher
Quest Software


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

Re: WAIT ECB WITH 00 First Byte

2011-12-16 Thread McKown, John

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tom Marchant
> Sent: Friday, December 16, 2011 7:35 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: WAIT ECB WITH 00 First Byte
> 
> On Fri, 16 Dec 2011 00:30:52 +0200, Binyamin Dissen wrote:
> 
> >AFAIK multi-ecb WAIT (for example, 5 ECBs, count of 1) does 
> not reset the
> >additional ECB's when the count is reached.
> 
> Not sure what you mean by this, Binyamin.  
> 
> My understanding, which might be incorrect or incomplete, is 
> that WAIT sets 
> the wait bits, stores the RB address in the ECBs, sets the 
> wait count in the 
> RB and puts the task in a wait state.  At that point, isn't 
> WAIT finished?
> 
> POST sets the post bit, clears the wait bit, decrements the 
> wait count if it 
> is greater than zero, then if it is zero, makes the task 
> dispatchable. 
> The ECBs are not reset.
> 
> -- 
> Tom Marchant

The "post code" is placed in the lower 3 bytes by POST, where the RB address is 
placed by the WAIT.
ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A3A0/28.1

Use the POST macro to set a specified event control block (ECB) to indicate the 
occurrence of an event. If this event satisfies the requirements of an 
outstanding WAIT or EVENTS macro, the waiting task is taken out of the wait 
state and dispatched according to its priority.

The bits in the ECB are set as follows:

Bit 0 of the specified ECB is set to 0 (wait bit).
Bit 1 is set to 1 (complete bit).
Bits 2 through 31 are set to the specified completion code. 

Now, when you are waiting on multiple ECBs and the wait number is less than the 
number of ECBs WAIT'ed upon, what happens to the contents of the non-POSTed 
ECBs? I will bet that the contents are undisturbed. If so, this means that 
those ECBs will have Bit 0 set to '1'b, Bit 1 set to '0'b, and the RB address 
in the lower 3 bytes. But I'm not sure of that. I don't have the code to the 
WAIT logic. And I'm too lazy to run a test.

--
John McKown 
Systems Engineer IV
IT

Administrative Services Group

HealthMarkets(r)

9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * 
john.mck...@healthmarkets.com * www.HealthMarkets.com

Confidentiality Notice: This e-mail message may contain confidential or 
proprietary information. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original message. 
HealthMarkets(r) is the brand name for products underwritten and issued by the 
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance 
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The 
MEGA Life and Health Insurance Company.SM

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

Re: 2 STC running on different GMT zones

2011-12-16 Thread CUNY Yann

I didn't know Hourglass ... Xchange seems to be similar, effectively ...



-Message d'origine-
De : IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] De la part de 
Vernooij, CP - SPLXM
Envoyé : vendredi 16 décembre 2011 14:09
À : IBM-MAIN@bama.ua.edu
Objet : Re: 2 STC running on different GMT zones

What is that?
Is it similar to Hourglass? This allows a task to 'see' a different time, 
heavily used for Y2K testing. 
This could be an option, however I wonder how it will handle signals coming in 
with 'real' timestamps.

Kees.


"CUNY Yann"  wrote in message 
news:...
> And what about Compure XChange ?
> 
> Cordialement,
> ___
> YANN CUNY
> AXA TECH
> IDST OUTILS
> 
> ( + 33 1 55 67 22 49
> ___
> 
> 
> -Message d'origine-
> De : IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] De la 
> part de Vernooij, CP - SPLXM Envoyé : vendredi 16 décembre 2011 13:19 
> À : IBM-MAIN@bama.ua.edu Objet : Re: 2 STC running on different GMT 
> zones
> 
> "CUNY Yann"  wrote in message 
> news: io
> ns.services.axa-tech.intraxa>...
> > Hi all,
> > 
> > Here's my problem :
> > 
> > We set up a scheduling LPAR to schedule all our production (Z/OS 
> > 1.11
> - TWS 8.5). On this LPAR, we have many TWS instances (3 For France,  3 for 
> the rest of the world). 
> > As you know, paris is on GMT+1.  But we have to schedule some jobs 
> > for
> our Japan teams 
> > 
> > So, my question is : 
> > Is it possible to have 2 STC running with different GMT zones ? 
> > 
> > Regards,
> > 
> > Yann
> > 
> 
> Not 2 STCs. A z/OS LPAR has 1 timezone, bot GMT and Local.
> You can have 2 LPARs with different Local times, if that helps.
> 
> Kees.
> 
> For information, services and offers, please visit our web site: 
> http://www.klm.com. This e-mail and any attachment may contain confidential 
> and privileged material intended for the addressee only. If you are not the 
> addressee, you are notified that no part of the e-mail or any attachment may 
> be disclosed, copied or distributed, and that any other action related to 
> this e-mail or attachment is strictly prohibited, and may be unlawful. If you 
> have received this e-mail by error, please notify the sender immediately by 
> return e-mail, and delete this message. 
> 
> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
> employees shall not be liable for the incorrect or incomplete transmission of 
> this e-mail or any attachments, nor responsible for any delay in receipt. 
> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal 
> Dutch Airlines) is registered in Amstelveen, The Netherlands, with 
> registered number 33014286
> 
>   
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
> 
> 
> Ce message est confidentiel;  Son contenu ne represente en aucun cas 
> un engagement de la part de  AXA Technology Services (AXA Tech) sous 
> reserve de tout accord conclu par ecrit entre vous et AXA Technology 
> Services (AXA Tech).Toute publication, utilisation ou diffusion,meme 
> partielle,  doit etre autorisee  prealablement.  Si vous  n'etes pas 
> destinataire de ce message, merci d'en avertir immediatement l'expe- 
> diteur.
> 
> This message is  confidential;  its  contents  do not  constitute  a 
> commitment by AXA Technology Services (AXA Tech) except where provi- 
> ded  for in  a written agreement  between  you  and  AXA  Technology 
> Services (AXA Tech).  Any unauthorised disclosure, use or dissemina- 
> tion, either  whole  or  partial, is prohibited. If  you are not the 
> intended recipient  of the message,  please notify  the sender imme- 
> diately.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e

Re: WAIT ECB WITH 00 First Byte