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: 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.commailto:p...@voltage.com Voltage Security, Inc. www.voltage.comhttp://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: 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: 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: 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
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: Question for SMP/E gurus with DB2 knowledge
Thanks for your opinion. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, September 13, 2011 2:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Question for SMP/E gurus with DB2 knowledge In 08ef7d7816b3b642a380513303a2d77b225c4...@alvmbxw02.prod.quest.corp, on 09/13/2011 at 07:17 PM, David Booher david.boo...@quest.com said: I posted this to DB2-L, but no takers :) Perhaps because it was a bad idea. I have recently decided that I'll re-run DSNTIJUZ assembly steps separately and don't want SMP doing it. Why? Foot, gun; gun, foot. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- 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
Re: Question for SMP/E gurus with DB2 knowledge
Yes, on my new DB2 installs, I simply omit the step from DSNTIJUZ, but once it's run, the damage is done. You pin-pointed my problem on older systems, the APPLY CHECK works fine, but when you actually run the APPLY, it can fail because of a reference to an obsolete SDSNEXIT library. Your suggestion is worth a try. Unfortunately, once the damage is done to SMP, it's hard to reverse it. Thanks, Dave -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Clark, Stan [GCG-PFS] Sent: Wednesday, September 14, 2011 9:02 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Question for SMP/E gurus with DB2 knowledge You could point SDSNEXIT to a library you don't use for anything. SMP would still assemble and link DSNZPARM, but you wouldn't use the output module. In our case, I always delete the SMP step from DSNTIJUZ. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of David Booher Sent: Tuesday, September 13, 2011 3:18 PM To: IBM-MAIN@bama.ua.edu Subject: Question for SMP/E gurus with DB2 knowledge I posted this to DB2-L, but no takers :) I was wondering if anyone was able to successfully 'unhook' the automatic assemblies of DSNZPARM, DSNDECP that result when maintenance hits the DSN6SPRM, DSN6ARVP, etc... macros? During job DSNTINUZ, step DSNTIMQ places entries into the target zone that generate automatic assembly and link of these members. I have recently decided that I'll re-run DSNTIJUZ assembly steps separately and don't want SMP doing it. I was wondering if anyone who has run DSNTIMQ has been able to successfully unhook its entries after the fact. Basically I've narrowed it down to the following entries in the target zone: MAC (DSN6ENV, DSN6SPRM, DSN6ARVP, DSN6LOGP, DSNHDECM, DSNHMCIM); ASSEM(DSNTILMM, DSNHDECA, DSNHMCIA); MOD(DSNTILMM, DSNHDECA, DSNHMCIA); LMOD(DSNHZAPRM, DSNDECP, DSNHMCID). Thanks, Dave Booher -- 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 -- 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 -- 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
Question for SMP/E gurus with DB2 knowledge
I posted this to DB2-L, but no takers :) I was wondering if anyone was able to successfully 'unhook' the automatic assemblies of DSNZPARM, DSNDECP that result when maintenance hits the DSN6SPRM, DSN6ARVP, etc... macros? During job DSNTINUZ, step DSNTIMQ places entries into the target zone that generate automatic assembly and link of these members. I have recently decided that I'll re-run DSNTIJUZ assembly steps separately and don't want SMP doing it. I was wondering if anyone who has run DSNTIMQ has been able to successfully unhook its entries after the fact. Basically I've narrowed it down to the following entries in the target zone: MAC (DSN6ENV, DSN6SPRM, DSN6ARVP, DSN6LOGP, DSNHDECM, DSNHMCIM); ASSEM(DSNTILMM, DSNHDECA, DSNHMCIA); MOD(DSNTILMM, DSNHDECA, DSNHMCIA); LMOD(DSNHZAPRM, DSNDECP, DSNHMCID). Thanks, Dave Booher -- 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
NFSS and Windows 7
Hello all, I've been experimenting with mapping USS NFS shares to my new Windows 7 box. In Windows I can do: mount -o fileaccess=777 \\10.4.23.212\u\dbooher W: This allows me to see the directory, browse file contents and even delete files. But when I attempt to create a file (like a .txt document) on Windows and then attempt to save it back to USS thru NFS, I get: The volume for a file has been externally altered so that the opened file is no longer valid from Windows. I've mapped the same USS NFS share with a Linux machine and have full control over the directory on USS So I'm pretty sure this is a Windows problem and it seems to only happen when a create file is going on. This isn't an authentication problem because the USS share is mounted RW to everyone at the moment. Anyone else seen this? It would be nice to populate USS directories thru Windows. Thanks, Dave Booher Quest Software -- 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
Re: IBM driving mainframe systems programmers into the ground
Well, without us Sysprogs, to whom would everyone pass the buck? Dave Booher *My opinions strictly my own From: IBM Mainframe Discussion List [ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin [paulgboul...@aim.com] Sent: Friday, November 13, 2009 4:51 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IBM driving mainframe systems programmers into the ground On Fri, 13 Nov 2009 14:15:57 -0800, Howard Rifkind wrote: In fact I believe there really is a very good chance to see the need for sysprogs disappear completely. Log into an IBM web site and download all the updates, fixes, new operating systems etc. And, taking an unbiased view, this would be bad because ... what? -- gil -- 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 -- 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
New ShopzSeries service
Hello, Does anyone know a quick way around this? Our z800 doesn't have a crytographic processor, so ICSF isn't configured. RECEIVE SYSMODS SOURCEID(PTF021) FROMNETWORK( SERVER(SERVINFO) /* CLIENT(CLNTINFO) */ /* === NOTE 4 */ /* TRANSFERONLY *//* === NOTE 3 */ ). GIM23412S ** RECEIVE COMMAND PROCESSING HAS FAILED. ICSF IS NOT AVAILABLE. DATA PERFORMED ON PACKAGE U00745744. GIM20501IRECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12. Dave Booher Quest Software * All opinions strictly my own -- 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
Re: New ShopzSeries service
I'll try that, but I have a hunch that there's something else required to enable this Java-based support. I miss the old way of doing maintenance...It was simple. thanks for you help. db -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chris Hoelscher Sent: Monday, November 09, 2009 1:16 PM To: IBM-MAIN@bama.ua.edu Subject: Re: New ShopzSeries service this may or may not work for you, but i added a DDDEF for SMPJHOME with a path of '/usr/lpp/java/IBM/J6.0/' and this seemed to resolve our similar issue (we switched the LPAR where SMP/E work was done to an LPAR where the crytographic processor was not currently available) Chris Hoelscher Senior IDMS DB2 Database Administrator Humana Inc 502-476-2538 choelsc...@humana.com you only need to test the programs that you want to work correctly The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- 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 -- 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
Re: New ShopzSeries service
My problem was that I was using an older 1.6 system that didn't have the /usr/lpp/smp/classes. For my 1.6 system, I can use the FTP/GIMUNZIP followed by the usual SMP RECEIVE. For my 1.7 system, I have it working with SMP RECIEVE FROMNTS using those the SMP Java classes. It seems to be working. Our shop still provides support for our products on z/OS 1.4 thru z/OS 1.10, so these older LPARs are still around. As long as I have a way to get the traditional SMPPTFIN file, then I'm OK. Thanks to all for your help. Dave Booher Quest Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pommier, Rex R. Sent: Monday, November 09, 2009 3:40 PM To: IBM-MAIN@bama.ua.edu Subject: Re: New ShopzSeries service You also don't need to start ICSF to perform the shopzseries install. The hashing works just fine (albeit taking lots of CPU resources) using the JAVA based software routines. When I downloaded my 1.10 order a couple months ago, I just had to have the //SMPJHOME DD PATH='/usr/lpp/java/J1.4/' card in my GIMGTPKG job runs. And even better, the CPAC job to do the download put the card in my JCL for me. Rex -- 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
Re: LE Options
It gives a return code 8 on open of SYSMGS but the options get printed. This is sufficient for my purposes. Thanks again, Dave -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bill Klein Sent: Monday, April 16, 2007 8:54 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Fw: LE Options I have NOT tried this myself, but if you are looking for a utility to do what you want, try running a job with the following step: //LISTOPT EXEC PGM=EDCALIAS,PARM='ROPTOPTS(ON)/' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
LE Options
Hello, Does anyone know of a way to print the system-wide LE options in effect for a system? Is there a utility? I can't seem to find one. Thanks, David Booher -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Help
Sometimes I mistakenly run jobs as IBMUSER and my ACS routines SET the STORCLASS to '' for IBMUSER. This was purposely done So that I'd to avoid using SMS-packs for that USERID. So, occaisionally I will run a job accidentally logged on as IBMUSER and the result is NON-SMS (files without a STORCLASS). Dave Booher Quest Software -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Barry Schwarz Sent: Thursday, September 01, 2005 2:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SMS Help In order for a new allocation to be SMS managed and go to a managed pack, it must be assigned a storage class. This can be done in JCL but most use the ACS routines. So the question becomes why isn't your ACS routine assigning a storage class. Once you invoke ISMF in administrator mode, you can display the names of the ACS routines. If you can't find the problem by analysis, you can add debugging WRITE statements at key decision points. Mark Steely [EMAIL PROTECTED] wrote: I have implemented SMS for our production files. Everything appears to be working correctly except this one file. It is a IEFBR14 and it is allocating the dataset as non-SMS, but every test I do using the same JCL works correctly. All the other files with this hi-level qualifier are working. What can I do to help track this allocation. I have looked at the SMS routines and can't figure out why it is not being SMS managed. Like I said all my test work correctly and even the test under ISMF work correctly. Any ideas would be greatly appreciated. We are z/OS v1r4. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
