Re: What cryptographic algorithm is not supported?

[Timothy Sipples]

In fairness, "PBE" (Password-Based Encryption) is a common term of art in
cryptography. OpenSSL and LibreSSL are among the many tools that use the
same TLA (three letter acronym) copiously.

However, it'd be lovely if you would submit a RFE (not PMR) to IBM to
expand that PBE-related GSK error message handling in some reasonable way
PDQ, possibly resulting in a PTF that you'd install in zFS via a TSO login.
BTW, RFC standards like TLS and SSL with their SHA, RSA, DES, PKI, CBC,
XTS, and other characteristics can sometimes be a PITA.

http://www.ibm.com/developerworks/rfe

Thx. :-)


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

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

Re: TDMF or FDRPAS or how to migrate data

[Timothy Sipples]

Radoslaw Skorupka:
>a) remote copy, like PPRC-XD, HUR, SRDF/A - all those require same
>vendor, since HDS won't talk to IBM or EMC. Unfortunately this is not an
>option.

That's a bit too pessimistic, I think. IBM and Hitachi Vantara both support
Metro Mirror (PPRC). See here for Hitachi Vantara's whitepaper (October,
2016):

https://www.hitachivantara.com/en-us/pdf/white-paper/mainframe-storage-compatibility-and-innovation-with-hitachi-vsp-g1000-whitepaper.pdf

If the fiber distance is about 150 Km, that's "far-ish" but not
automatically too far for these purposes. Whether a Metro Mirror-based
storage migration is viable will depend on the workloads (and their storage
I/O characteristics) that must run during the final pre-cutover preparation
stages, and the minimum required service levels for those workloads. In
many cases you can pick a "quiet" time, and the migration would be viable.

If the fiber distance poses a challenge for a Metro Mirror-based storage
migration, even for "quiet time" workloads, then another technically
possible Metro Mirror-based approach is to deploy a "staging" storage unit
(perhaps an off lease/refurbished, temporarily vendor-supplied, older model
unit that's "good enough" for the short-term mission) at a shorter fiber
distance to handle the cross-vendor transition, then leapfrog
asynchronously from there.

z/OS Basic HyperSwap could be in the picture.

Please talk with the storage vendors, of course, to get their viewpoints.
I'm merely providing some hypotheticals.


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

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

Re: What cryptographic algorithm is not supported?

[Charles Mills]

Got it! The only password encryption algorithm (PBE) supported for FIPS mode is 
pbeWithSha1And3DesCbc.

In OpenSSL PCKS12, I needed to add -certpbe PBE-SHA1-3DES

Sheesh! Would a more specific error message kill them?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, November 6, 2017 5:41 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What cryptographic algorithm is not supported?

Okay, I got trace information out of gskkyman. What do you make of this?

INFO crypto_des3_encrypt_ctx(): Clear key DES3 encryption performed for 8 bytes 
  
INFO crypto_des3_decrypt_ctx(): Clear key DES3 decryption performed for 8 bytes 
  
INFO crypto_des3_encrypt_ctx_alet(): Clear key DES3 encryption performed for 8 
bytes  
INFO crypto_des3_decrypt_ctx_alet(): Clear key DES3 decryption performed for 8 
bytes  
INFO crypto_aes_encrypt_ctx(): Clear key AES 128-bit encryption performed for 
16 bytes
INFO crypto_aes_decrypt_ctx(): Clear key AES 128-bit decryption performed for 
16 bytes
INFO crypto_aes_encrypt_ctx_alet(): Clear key AES 128-bit encryption performed 
for 16 bytes   
INFO crypto_aes_decrypt_ctx_alet(): Clear key AES 128-bit decryption performed 
for 16 bytes   
INFO crypto_aes_encrypt_ctx(): Clear key AES 256-bit encryption performed for 
16 bytes
INFO crypto_aes_decrypt_ctx(): Clear key AES 256-bit decryption performed for 
16 bytes
INFO crypto_aes_encrypt_ctx_alet(): Clear key AES 256-bit encryption performed 
for 16 bytes   
INFO crypto_aes_decrypt_ctx_alet(): Clear key AES 256-bit decryption performed 
for 16 bytes   
INFO crypto_rsa_public_encrypt(): RSA modulus is 2048 bits  
  
INFO crypto_rsa_public_encrypt(): Software RSA public key encryption performed  
  
INFO crypto_rsa_private_decrypt(): Using PKCS private key   
  
INFO crypto_rsa_private_decrypt(): RSA modulus is 2048 bits 
  
INFO crypto_rsa_private_decrypt(): Software RSA private key decryption 
performed  
INFO open_kdb_check_filedata(): Record size 5000, Record count 12   
  
INFO gsk_build_issuer_chains(): Record 'Equifax Secure Certificate Authority' 
is self-signed  
INFO gsk_build_issuer_chains(): Record 'Equifax Secure eBusiness CA-2' is 
self-signed 
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 1 Public Primary CA - 
G2' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 2 Public Primary CA - 
G2' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 3 Public Primary CA - 
G2' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 4 Public Primary CA - 
G2' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 1 Public Primary CA - 
G3' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 2 Public Primary CA - 
G3' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 3 Public Primary CA - 
G3' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 4 Public Primary CA - 
G3' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 3 Public Primary CA - 
G5' is self-signed   
INFO gsk_build_issuer_chains(): Record 'CMC_root_Exp_2024a' is self-signed  
  
INFO open_kdb_check_filedata(): Record size 5000, Record count 0
  
ERROR crypto_pbe_decrypt_data(): Algorithm 36 is not supported for PBE  
  
ERROR import_pkcs12v3(): Unable to decrypt EncryptedData message: Error 
0x03353003
ERROR gsk_decode_import_key(): Unable to import PKCS12 V3: Error 0x03353003 
  
ERROR gsk_import_key(): Unable to decode subject certificate or chain: Error 
0x03353003   

Algorithm 36 (cipher suite 36?) is TLS_DH_DSS_WITH_AES_256_CBC_SHA. Where does 
that come into the picture? What is PBE?

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

Re: What cryptographic algorithm is not supported?

[Charles Mills]

Okay, I got trace information out of gskkyman. What do you make of this?

INFO crypto_des3_encrypt_ctx(): Clear key DES3 encryption performed for 8 bytes 
  
INFO crypto_des3_decrypt_ctx(): Clear key DES3 decryption performed for 8 bytes 
  
INFO crypto_des3_encrypt_ctx_alet(): Clear key DES3 encryption performed for 8 
bytes  
INFO crypto_des3_decrypt_ctx_alet(): Clear key DES3 decryption performed for 8 
bytes  
INFO crypto_aes_encrypt_ctx(): Clear key AES 128-bit encryption performed for 
16 bytes
INFO crypto_aes_decrypt_ctx(): Clear key AES 128-bit decryption performed for 
16 bytes
INFO crypto_aes_encrypt_ctx_alet(): Clear key AES 128-bit encryption performed 
for 16 bytes   
INFO crypto_aes_decrypt_ctx_alet(): Clear key AES 128-bit decryption performed 
for 16 bytes   
INFO crypto_aes_encrypt_ctx(): Clear key AES 256-bit encryption performed for 
16 bytes
INFO crypto_aes_decrypt_ctx(): Clear key AES 256-bit decryption performed for 
16 bytes
INFO crypto_aes_encrypt_ctx_alet(): Clear key AES 256-bit encryption performed 
for 16 bytes   
INFO crypto_aes_decrypt_ctx_alet(): Clear key AES 256-bit decryption performed 
for 16 bytes   
INFO crypto_rsa_public_encrypt(): RSA modulus is 2048 bits  
  
INFO crypto_rsa_public_encrypt(): Software RSA public key encryption performed  
  
INFO crypto_rsa_private_decrypt(): Using PKCS private key   
  
INFO crypto_rsa_private_decrypt(): RSA modulus is 2048 bits 
  
INFO crypto_rsa_private_decrypt(): Software RSA private key decryption 
performed  
INFO open_kdb_check_filedata(): Record size 5000, Record count 12   
  
INFO gsk_build_issuer_chains(): Record 'Equifax Secure Certificate Authority' 
is self-signed  
INFO gsk_build_issuer_chains(): Record 'Equifax Secure eBusiness CA-2' is 
self-signed 
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 1 Public Primary CA - 
G2' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 2 Public Primary CA - 
G2' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 3 Public Primary CA - 
G2' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 4 Public Primary CA - 
G2' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 1 Public Primary CA - 
G3' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 2 Public Primary CA - 
G3' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 3 Public Primary CA - 
G3' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 4 Public Primary CA - 
G3' is self-signed   
INFO gsk_build_issuer_chains(): Record 'VeriSign Class 3 Public Primary CA - 
G5' is self-signed   
INFO gsk_build_issuer_chains(): Record 'CMC_root_Exp_2024a' is self-signed  
  
INFO open_kdb_check_filedata(): Record size 5000, Record count 0
  
ERROR crypto_pbe_decrypt_data(): Algorithm 36 is not supported for PBE  
  
ERROR import_pkcs12v3(): Unable to decrypt EncryptedData message: Error 
0x03353003
ERROR gsk_decode_import_key(): Unable to import PKCS12 V3: Error 0x03353003 
  
ERROR gsk_import_key(): Unable to decode subject certificate or chain: Error 
0x03353003   

Algorithm 36 (cipher suite 36?) is TLS_DH_DSS_WITH_AES_256_CBC_SHA. Where does 
that come into the picture? What is PBE?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, November 6, 2017 5:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What cryptographic algorithm is not supported?

David, thanks. I had not parsed "cryptographic" that finely. Isn't SHA512 a 
*cryptographic* hash? Who knows if IBM is being that precise? Good thought.

I'm looking at https://ibm.co/2AqCDam (I'm running on V2R2.) It looks to me 
like SHA-512 and RSA 2048 are supported in FIPS mode.

Could it be something in the CA certificate? It looks like it is SHA-256 RSA 
2048, so it should be good also.

Grrr. Is there any way to get more diagnostic information out of gskkyman? Hmmm 
-- I see the GSK trace. I will try that.

I hate obscure error messages. Tell me what you are objecting to, darn it!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David W Noon
Sent: Monday, November 6, 2017 4:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What cryptographic algorithm is not supported?

On Mon, 6 Nov 2017 14:32:01 -0800, Charles Mills (charl...@mcn.org) wrote about 
"What cryptographic algorithm is not supported?" (in
<210a01d3574f$11063a10$3312ae30$@mcn.org>):

Re: Z14 IOCP and USB

[Rob Schramm]

Unless they made serious changes and provide some diagnostics (anything
other than pass/fail).. I am not optimistic.

Rob Schramm

On Mon, Nov 6, 2017, 10:46 AM Tom Mathias  wrote:

> The new z14 support also added support for all three of the "ftp"
> protocols:  FTP, SFTP and FTPS.  All three will "proxy" thru the z14 HMC
> now.  I can't speak about z/OS, however.
>
> Tom Mathias
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

Re: What cryptographic algorithm is not supported?

[Charles Mills]

David, thanks. I had not parsed "cryptographic" that finely. Isn't SHA512 a 
*cryptographic* hash? Who knows if IBM is being that precise? Good thought.

I'm looking at https://ibm.co/2AqCDam (I'm running on V2R2.) It looks to me 
like SHA-512 and RSA 2048 are supported in FIPS mode.

Could it be something in the CA certificate? It looks like it is SHA-256 RSA 
2048, so it should be good also.

Grrr. Is there any way to get more diagnostic information out of gskkyman? Hmmm 
-- I see the GSK trace. I will try that.

I hate obscure error messages. Tell me what you are objecting to, darn it!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David W Noon
Sent: Monday, November 6, 2017 4:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: What cryptographic algorithm is not supported?

On Mon, 6 Nov 2017 14:32:01 -0800, Charles Mills (charl...@mcn.org) wrote about 
"What cryptographic algorithm is not supported?" (in
<210a01d3574f$11063a10$3312ae30$@mcn.org>):

> I am trying to load a certificate and key into a FIPS-140 GSK 
> database. I am getting Status 0x03353003 - Cryptographic algorithm is 
> not supported. How would I know exactly what algorithm it is 
> complaining about? Here's an extract from the certificate and key:

You have 2 lines that mention algorithms:

> Signature Algorithm: sha512WithRSAEncryption

> Public Key Algorithm: rsaEncryption

(There is actually a 3rd one, but it is the same as the first.)

Now, SHA512 is a hashing algorithm, so that leaves RSA as your crypto algorithm.

I don't know why RSA would be unsupported, as it has been around since the late 
1970's. I can only infer that it has been dropped.
--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

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

Re: Odd SMF 30 data within IEFACTRT

[Barry Merrill]

All or almost all DB2 data can contain length=0 as documented 
in DB2 Maclib SDSNMACS members, for one example below.

Barry


./   ADD   NAME=DSNDQWA0,SSI=24351827
*   %DCL DSNDQWA0_LIST CHAR EXTERNAL;   0001
*   %IF DSNDQWA0_LIST ^= '' %THEN/* DSNDQWA0_LIST IS SET TO  */ 0002
* %GOTO QWA0_LIST_ON;/*YES FOR THE LISTING   */ 0003
*   @LIST PUSH; 0004
*   @LIST OFF;  0005
*   %QWA0_LIST_ON:; 0006
*   0007
*   %GOTO PLSPART_DSNDQWA0; 0008
*/*/0009
*/* MACRO-NAME = DSNDQWA0 */0010
*/* DESCRIPTIVE-NAME = DB2 SELF DEFINING SECTION MAPPING MACRO*/0011
*/* FOR ACCOUNTING IFCID=0003 */0012
*/*Licensed Materials - Property of IBM   */0013
*/*5615-DB2   */0014
*/*(C) COPYRIGHT 1982, 2013 IBM Corp.  All Rights Reserved.   */0015
*/*   */0016
*/*STATUS = Version 11*/0017
*/* FUNCTION = MAPPING MACRO FOR DB2 ACCOUNTING SELF DEFINING */0018
*/*SECTION FOR IFCID=0003 */0019
lines deleted
*/*/0055
0057
*/**IMPORTANT PARSING INFORMATION*IMPORTANT PARSING INFORMATION 0058
* * 0059
* The length field for any (offset,length,number of data sections)* 0060
* triplet can legally be zero with a non-zero offset.  This indicates * 0061
* this section is a varying length repeating group. A varying * 0062
* length repeating group is a series of related data blocks with  * 0063
* differing lengths. This is typically, if not always, the result of  * 0064
* varying length long name fields in the data block.  * 0065
* * 0066
* In order to parse a varying length repeating group, the following   * 0067
* steps should be taken:  * 0068
* 1. Follow the offset pointer to find the first member of the group. * 0069
* 2. Each member will be mapped as follows:   * 0070
*<2 byte member length>  * 0071
* * 0072
*The length of the first member will be in the 2 bytes pointed* 0073
*to by the offset pointer.  It is important to note that the  * 0074
*data section for the first member will start 2 bytes past the* 0075
*offset pointer.  * 0076
* 3. Subsequent members can be found by advancing the pointer * 0077
*(length of current member + 2 bytes) forward.  These members * 0078
*will also be formatted as <2 byte length>.  * 0079
*Again, it is important to note that the data section starts 2* 0080
*bytes past the beginning of the member.  * 0081
* 4. The number of members in the repeating group will be held in * 0082
*the corresponding 'number of data sections' field in the * 0083
*self-defining section.   * 0084
* * 0085


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of DanD
Sent: Monday, November 6, 2017 5:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Odd SMF 30 data within IEFACTRT

Thank you Berry,

"As noted, the Length value of zero is now used to indicate that the actual 
length is in the first two bytes at the offset, if COUNT is non-zero."

Do you know of a field where this is the case?   I've never seen that.

Thanks again,
Dan

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 

Re: SUBSYS= ?

[David W Noon]

On Tue, 7 Nov 2017 00:07:13 +, Jesse 1 Robinson
(jesse1.robin...@sce.com) wrote about "Re: SUBSYS= ?" (in
):

> My comment about deprecation was limited to the SUBSYS= keyword. I saw
> from other replies that Panvalet and Librarian use the keyword.

More than that, the SUBSYS keyword is used for RLS and BLSR processing
of VSAM clusters -- and those are IBM subsystems. Deprecating that would
cause wholesale breakage at sites that do a lot of VSAM processing.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

Re: Missing C module 'MSGDLL'

[John McKown]

On Mon, Nov 6, 2017 at 5:28 PM, Tony Thigpen  wrote:

> I am running a vendor supplied program and it is abending with:
>
> CEE3501S THE MODULE MSGDLL WAS NOT FOUND.
>
> The following is some of the logs. (I have masked the vendor program name
> and service.)
>
> CEE3DMP V1 R13.0: CONDITION PROCESSING RESULTED IN THE
> UNHANDLED CONDITION
>
> TRACEBACK:
>   DSA   ENTRYLOAD MOD PROGRAM UNIT SERVICE  STATUS
>   1 CEEHDSP  CEEPLPKA CEEHDSP  UK80866  CALL
>   2 CEEHSGLT CEEPLPKA CEEHSGLT HLE7780  EXCEPTION
>   3 CEEPTLOR CEEPLPKA CEEPTLOR HLE7780  CALL
>   4 @@TRGLOC CEEEV003   CALL
>   5 INITIALIZE   *masked*  ***  CALL
>   6 MAIN *masked*  ***  CALL
>   7 EDCZMINV CEEEV003   CALL
>   8 CEEBBEXT CEEPLPKA CEEBBEXT HLE7780  CALL
>
>   DSA   DSA ADDR  COMP DATE  COMPILE ATTRIBUTES
>   1 15430860  20120806   CEL   POSIX
>   2 1542FCD0  20110318   CEL   POSIX
>   3 1542F920  20110318   CEL   POSIX
>   4 1542F848  03/18/11   LIBRARYPOSIX
>   5 1542F648  20080221   C/C++ POSIX EBCDIC  HFP
>   6 1542F230  20080221   C/C++ POSIX EBCDIC  HFP
>   7 1542F118  20110318   LIBRARYPOSIX
>   8 1542F018  20110318   CEL   POSIX
>
> I am thinking I am missing a STEPLIB, but I can't seem to find 'MSGDLL'
> anywhere.
>
> Thoughts?


​It certainly does _NOT_ look like an IBM name. I'd look in all the
vendor's libraries. Or maybe it is a "user supplied" module, with a vendor
supplied example that you need to customize and install. Are you allowed to
mention the product & vendor?​



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



-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: SUBSYS= ?

[Jesse 1 Robinson]

My comment about deprecation was limited to the SUBSYS= keyword. I saw from 
other replies that Panvalet and Librarian use the keyword. I also discovered a 
few in-house PROCs with it, several in the context of DB2. Of course the 
fundamental Subsystem Interface is not going away. I guess the JCL keyword 
won't either. As I said, never mind. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Monday, November 06, 2017 10:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SUBSYS= ?

On 6 November 2017 at 11:49, Jesse 1 Robinson 
wrote:

> Throughout this thread, I've been haunted by a dim memory of some 
> SUBSYS action in the distant past. We have not had any in-house SUBSYS 
> dependencies for decades, so I did not pay very much attention.
>
> Did IBM announce long ago that SUBSYS was being deprecated? If so, 
> that might explain the dearth of doc. If not, then never mind.
>

A couple of comments on this thread...

The OP was asking specifically about SUBSYS= on a DD statement (and one might 
infer, the same via dynamic allocation). Keep in mind that this is but one 
aspect of the larger Subsystem Interface (SSI) provided by MVS.

I think it most unlikely that the SSI would be deprecated any time soon, and I 
have no recollection of any such announcement. What is clear is that
*effectively* the documentation for many subsystem functions has disappeared, 
because there never was formal doc for much of it, and the source code that was 
the reference has now mostly gone OCO. Along with the disappearance of the 
source-code-as-doc is the appearance of warnings in the doc that does exist 
that only the documented SSI calls may be used.
That doc is less than clear about the notion of a user-defined subsystem that 
defines its own SSI calls (presumably outside the range of the IBM
ones) and thus provides services to callers who know how to use them. But I 
guess that IBM would say that this *is* a supported thing to do, but of course 
when your subsystem code breaks, don't call IBM.

The fuzzy part in the middle is writing your own subsystem that supports 
IBM-defined calls that are not in the doc, and/or writing your own SSI caller 
that makes such calls. Is it possible, for instance, to write your own Job 
Entry Subsystem (JES4, perhaps)? Certainly not using the current IBM doc.

The GPSAM doc itself contains some musing on the subsystem interface and its 
level of doc and support, written at a time when OCO was not even on the 
horizon. Yet it may even today explain some of why it is as it is.

Gil suggests that the z/OS UNIX VFS interface might be an SSI replacement.
(I think PFS is the more likely interface, but no matter.) I doubt that this is 
likely, if only because the PFS/VFS interface comes up relatively late in the 
game, but the SSI is available very early. And a simple subsystem can be very 
concise but powerful (GPSAM is less than 200 lines of actual code). Writing 
even a simple PFS would probably require thousands of lines of code, and there 
are many subtle and complex calls that must be handled.

Tony H.


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

Re: What cryptographic algorithm is not supported?

[David W Noon]

On Mon, 6 Nov 2017 14:32:01 -0800, Charles Mills (charl...@mcn.org)
wrote about "What cryptographic algorithm is not supported?" (in
<210a01d3574f$11063a10$3312ae30$@mcn.org>):

> I am trying to load a certificate and key into a FIPS-140 GSK database. I am
> getting Status 0x03353003 - Cryptographic algorithm is not supported. How
> would I know exactly what algorithm it is complaining about? Here's an
> extract from the certificate and key:

You have 2 lines that mention algorithms:

> Signature Algorithm: sha512WithRSAEncryption

> Public Key Algorithm: rsaEncryption

(There is actually a 3rd one, but it is the same as the first.)

Now, SHA512 is a hashing algorithm, so that leaves RSA as your crypto
algorithm.

I don't know why RSA would be unsupported, as it has been around since
the late 1970's. I can only infer that it has been dropped.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

Re: REXX Language Processor Environment - creating new?

[John McKown]

On Mon, Nov 6, 2017 at 5:04 PM, Attila Fogarasi  wrote:

> No need to read source code as it is pretty well documented in the Rexx
> Reference manual, start with the section "replaceable routines - host
> command environment"
> https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.
> 0/com.ibm.zos.v2r1.ikja300/aerep.htm
>
> Rexx provides callable routines for things like getting the value of Rexx
> variables.  Depending upon your exec execution environment and host command
> processor, you may also need to do a dozen things in intitialization (for
> example provide your own storage management routine).  All of this is
> fairly easily done/  I no longer have an example but did this circa 25
> years ago and not much has changed, if anything, since then.  It only gets
> tricky if you want to run unsupported capabilities (such as APF
> authorized).
>
>
​Thanks. I guess I'm in too much of a hurry. I'd only gotten as far as
"Host Command Table" and was getting impatient. You'd think at my age, I'd
have learned better.​


-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: Odd SMF 30 data within IEFACTRT

[DanD]

Thank you Berry,

"As noted, the Length value of zero is now used to indicate that the
actual length is in the first two bytes at the offset, if COUNT is
non-zero."

Do you know of a field where this is the case?   I've never seen that.

Thanks again,
Dan

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

Missing C module 'MSGDLL'

[Tony Thigpen]

I am running a vendor supplied program and it is abending with:

CEE3501S THE MODULE MSGDLL WAS NOT FOUND.

The following is some of the logs. (I have masked the vendor program 
name and service.)


CEE3DMP V1 R13.0: CONDITION PROCESSING RESULTED IN THE
UNHANDLED CONDITION

TRACEBACK:
  DSA   ENTRYLOAD MOD PROGRAM UNIT SERVICE  STATUS
  1 CEEHDSP  CEEPLPKA CEEHDSP  UK80866  CALL
  2 CEEHSGLT CEEPLPKA CEEHSGLT HLE7780  EXCEPTION
  3 CEEPTLOR CEEPLPKA CEEPTLOR HLE7780  CALL
  4 @@TRGLOC CEEEV003   CALL
  5 INITIALIZE   *masked*  ***  CALL
  6 MAIN *masked*  ***  CALL
  7 EDCZMINV CEEEV003   CALL
  8 CEEBBEXT CEEPLPKA CEEBBEXT HLE7780  CALL

  DSA   DSA ADDR  COMP DATE  COMPILE ATTRIBUTES
  1 15430860  20120806   CEL   POSIX
  2 1542FCD0  20110318   CEL   POSIX
  3 1542F920  20110318   CEL   POSIX
  4 1542F848  03/18/11   LIBRARYPOSIX
  5 1542F648  20080221   C/C++ POSIX EBCDIC  HFP
  6 1542F230  20080221   C/C++ POSIX EBCDIC  HFP
  7 1542F118  20110318   LIBRARYPOSIX
  8 1542F018  20110318   CEL   POSIX

I am thinking I am missing a STEPLIB, but I can't seem to find 'MSGDLL' 
anywhere.


Thoughts?

--
Tony Thigpen

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

Re: REXX Language Processor Environment - creating new?

[Attila Fogarasi]

No need to read source code as it is pretty well documented in the Rexx
Reference manual, start with the section "replaceable routines - host
command environment"
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikja300/aerep.htm

Rexx provides callable routines for things like getting the value of Rexx
variables.  Depending upon your exec execution environment and host command
processor, you may also need to do a dozen things in intitialization (for
example provide your own storage management routine).  All of this is
fairly easily done/  I no longer have an example but did this circa 25
years ago and not much has changed, if anything, since then.  It only gets
tricky if you want to run unsupported capabilities (such as APF
authorized).

On Tue, Nov 7, 2017 at 9:00 AM, John McKown 
wrote:

> I'm reading up on this. I did not find any Redbook which seemed to address
> it. This portion of REXX is for a "Language Processor". From what I am
> gathering, this is when you want to use the "ADDRESS " ( such as
> ADDRESS TSO or ADDRESS SYSCALL ...). I am thinking of doing some "weird (of
> course) and wonderful (maybe)" with this. But, at least so far, I haven't
> gotten a firm grasp on how it all goes together. On Linux and other FOSS, I
> would look at the source and possibly get a better grasp on things. "Just
> say NO to OCO!" {grin}
>
> Anybody got anything they can share?
>
> --
> I have a theory that it's impossible to prove anything, but I can't prove
> it.
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: C/C++ Runtime Library

[Edward Gould]

> On Nov 6, 2017, at 5:58 AM, Thomas David Rivers  wrote:
> 
>> ——SNIP---
>> 
> Let me also speak as a vendor; for Dignus C/C++ (in he default mode of 
> operation)
> the runtime is linked with the program.  There is no dependency on an 
> externally
> loaded component - or LE.   So, you don't have to worry about version 
> compatibility.
> 
Dave,
Great news, glad you guys got it done properly.
I will however tell people about an issue I had with a European vendor.
I won’t mention names as I have long time forgotten them.
One of our users wanted to purchase this package. I installed it (non-smpe) and 
started my test out of the program. No matter how I tried to run it it was OC4 
ing. So I tried the second example of their product and the same thing 0C4.
I called the vendor in Europe and gave them the information and I wanted to 
know what their fax was to send the dumps (these were small dumps 2-3 pages 
each). He wouldn’t hear of it and wanted to go over the dumps on the phone, so 
we did. IIRC I had 3 dumps each of the dump 0C4 showed up in an LE module 
(different one on each dump). At the end he asked what level of LE we were at, 
I don’t remember the number but it seemed like every 6 months LE was coming out 
with a new version (this was approximately 20 years ago). He thought about it 
and he said he would call me back. Which he did about 2 hours later. He told me 
to do an amblist of every module that was in their library and create link 
statements  for each module and to replace every LE module and relink them with 
our LE version. I said you have to be kidding, no he said that is the “fix”. I 
said thanks and good bye. I looked at the amount of work involved and it was a 
healthy amount. So I made an appointment to talk with the boss. When I 
explained what was going on and what the vendor had asked me to do and I was 
guessing 10-15 hours to do the work. He said no you are not going to do this, I 
will talk with them and get them to do it for us. The next day the boss came 
out and told me to throw the work away and to return the tape to them. He then 
called the user and explained that the install process was a lot more intensive 
than what was originally thought and we would not install their software.

Ed  
> - Dave Rivers -
> 
> -- 
> riv...@dignus.comWork: (919) 676-0847
> Get your mainframe programming tools at http://www.dignus.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: Odd SMF 30 data within IEFACTRT

[Barry Merrill]

It is documented for many newer SMF records that the COUNT field is the
sole indicator that there are in fact these segments in this record.
The OFFSET seems always to be busy, and the value of the location of
the next triplet, even when this is the last triplet.

As noted, the Length value of zero is now used to indicate that the
actual length is in the first two bytes at the offsed, if COUNT is
non-zero.

Barry


Merrilly yours,

 Herbert W. Barry Merrill, PhD
 President-Programmer
 Merrill Consultants
 MXG Software
 10717 Cromwell Drive  technical questions: supp...@mxg.com
 Dallas, TX 75229
 http://www.mxg.comadmin questions: ad...@mxg.com
 tel: 214 351 1966
 fax: 214 350 3694



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of DanD
Sent: Monday, November 6, 2017 2:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Odd SMF 30 data within IEFACTRT

Thanks everyone.

I WILL check all 3 fields for zeros in the future.
It's still odd that the 1st record has an offset and length but the count is 
zeros...

"Here's the section your looking for ... it's this big ... and there are NONE"  
what? ;-)

Dan

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

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

What cryptographic algorithm is not supported?

[Charles Mills]

X-Posted IBM-MAIN and MVS-OE.

 

I am trying to load a certificate and key into a FIPS-140 GSK database. I am
getting Status 0x03353003 - Cryptographic algorithm is not supported. How
would I know exactly what algorithm it is complaining about? Here's an
extract from the certificate and key:

 

Certificate:

Data:

Version: 3 (0x2)

Serial Number: 33 (0x21)

Signature Algorithm: sha512WithRSAEncryption

Validity

Not Before: Nov  6 22:23:23 2017 GMT

Not After : Nov  6 22:23:23 2018 GMT

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

X509v3 Extended Key Usage:

TLS Web Server Authentication, TLS Web Client Authentication

Netscape Comment:

OpenSSL Generated Certificate

82:7D:1F:EF:53:DB:3D:E1:14:62:03:49:34:16:A2:92:D9:46:51:1E

Signature Algorithm: sha512WithRSAEncryption

 

It loads into a non-FIPS-140 certificate database, so everything about the
format and so forth is fine - it's just that some algorithm is out of date.

 

Thanks,

 

Charles 

 


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

REXX Language Processor Environment - creating new?

[John McKown]

I'm reading up on this. I did not find any Redbook which seemed to address
it. This portion of REXX is for a "Language Processor". From what I am
gathering, this is when you want to use the "ADDRESS " ( such as
ADDRESS TSO or ADDRESS SYSCALL ...). I am thinking of doing some "weird (of
course) and wonderful (maybe)" with this. But, at least so far, I haven't
gotten a firm grasp on how it all goes together. On Linux and other FOSS, I
would look at the source and possibly get a better grasp on things. "Just
say NO to OCO!" {grin}

Anybody got anything they can share?

-- 
I have a theory that it's impossible to prove anything, but I can't prove
it.

Maranatha! <><
John McKown

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

Re: Odd SMF 30 data within IEFACTRT

[Charles Mills]

Here is the offset, here is the (fixed, never any different) length, and here 
is how many of them there are: as it happens, zero.

For many triplets you need to process that count anyway as it may be greater 
than one. 

It's one of those things. It may not make sense to you, but it's the way it is.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of DanD
Sent: Monday, November 6, 2017 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Odd SMF 30 data within IEFACTRT

Thanks everyone.

I WILL check all 3 fields for zeros in the future.
It's still odd that the 1st record has an offset and length but the count is 
zeros...

"Here's the section your looking for ... it's this big ... and there are NONE"  
what? ;-)

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

Re: Odd SMF 30 data within IEFACTRT

[DanD]

Thanks everyone.

I WILL check all 3 fields for zeros in the future.
It's still odd that the 1st record has an offset and length but the count is 
zeros...

"Here's the section your looking for ... it's this big ... and there are NONE"  
what? ;-)

Dan

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

Re: TDMF or FDRPAS or how to migrate data

[Dana Mitchell]

We have used both TDMF and FDRPAS in the past to migrate entire shop's DASD 
from one Vendors equipment to another,  usually included in the deal for the 
new DASD.  Both seemed to work equally well, and got the job done smoothly 
without disruption.(I do have personal preference for FDR's products).

I just now looked at FDRPAS (haven't used it in a few years)  and found this 
new feature that sounds like it's made for you:

FDRPAS now supports migration to a site where the disks are not connected to
the CPU where FDRPAS is running. FDRPAS reads the data from the source
volumes and uses TCP/IP to send the data to the remote site. At the remote site,
FDR/UPSTREAM for FDRPAS TCP/IP receives the data and writes it to the target
disks. For more information, see Chapter 317 “FDRPAS SWAPDUMP to a Remote
Site via TCP/IP”.

For a large scale synchronized migration, the new FDRPAS option
KEEPACTIVE=REPEAT offers a new mode of operation for SWAPDUMP that
greatly increases the number of source volumes that can be included in one job,
thus reducing the required number of SWAPDUMP and monitor jobs as compared
to CONFIRMSPLIT=YES. With KEEPACTIVE=REPEAT, first the initial copy pass is
done for every source volume. The SWAPDUMP subtasks terminate, but the I/O
intercepts are left active. Then, after a pause, all of the source volumes are
processed again; since the I/O intercepts have remained active, only updated
tracks need to be recopied. SWAPDUMP repeatedly cycles through all of the
source volumes, keeping the target volumes synchronized, until you are ready to
complete the operation. For more information, see Chapter 317 “FDRPAS
SWAPDUMP to a Remote Site via TCP/IP”. 

HTH
Dana


On Mon, 6 Nov 2017 17:45:22 +0100, R.S.  wrote:

>The following scenario:
>CPC is connected to a DASD box of vendor A (DISK A). The goal is to move
>the data to new DASD box of unlike vendor (DISK B). DISK B is located
>150km away from DISK A. In location B there will be also another CPC.
>
>Of course it would be nice to do it with very limited disk utilisation
>and as short as possible outage window.
>
>The idea is to move the data in the background over some cable, stop
>production, synchronize all remaining changes, stop the z/OS in location
>A, start z/OS in location B.
>

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

Re: TDMF or FDRPAS or how to migrate data

[Jackson, Rob]

When we insourced our data center six years ago, we used TDMF to migrate more 
than 3300 volumes of various sizes approximately a thousand kilometers using a 
"spare" DS3 line.  It required seven master sessions and corresponding agents 
on each source LPAR, and we ensured time-consistency between them by running 
the masters and agents under the master subsystem and shutting down everything 
else, including JES2, prior to copy session finalization.  At that line speed, 
it took a few days to reach full copy, and we generally had less than an hour 
to wait for full synch to be reached during the mock and final cutover events.  
The solution worked amazingly well, and I highly recommend it over XRC for a 
migration.

At the time, we were working with IBM through a VAR, so TDMF was the obvious 
choice.  Since then I've worked with Hitachi, who prefers to use FDR, which has 
equivalent functionality.  In either case, you can use the software short-term 
under the terms of whatever SOW you work out with the storage vendor for 
implementation.

If you end up going the TDMF route, let me know if you'd be interested in a 
program I wrote to generate master and agent sessions, as well as CLIPs, INITs, 
vary jobs, and some other stuff.  It was very helpful for me, as the JCL and 
control cards can be laborious, especially when keeping up with a changing 
source pool of volumes not under your control.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Monday, November 06, 2017 1:40 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TDMF or FDRPAS or how to migrate data

[External Email]

I feel like Paul Harvey... now for the rest of the story:

We also had problems with the extended protocol, but it was not the vendor's 
(CNT, I think) fault. IIRC correctly, HDS had promised that they were fully 
functional to do XRC (or HRC as they called it then) from themselves to IBM 
over the CNT topology. Over the course of a year, we  experienced enough 
transmission issues pointing to HDS that we replaced their DASD in the source 
side and upgraded the DASD on the target side to the fastest available from IBM 
at the time. I assume those issues have been resolved by HDS and CNT/McData was 
ultimately acquired by Brocade?

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, November 06, 2017 1:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TDMF or FDRPAS or how to migrate data

Excellent warning. That's why I said "(more or less) invisible to systems on 
the source side". We had a similar experience when we started mirroring around 
Y2K. In our case, the DASD was comparable at both sides, but protocol was ESCON 
extended by third party technology. We got around the problem then with tuning.

Today the problem is non-existent. DASD is FICON extended by DWDM. Most 
important, XRC works differently. Originally any changed data not yet mirrored 
was captured in the 'controller'; that was obviously limited by subsystem 
memory capacity. Now if a volume mirror falls behind, the subsystem maintains 
only a track map of changed data. That map cannot exceed the number of tracks 
regardless of the amount of data involved. Today we rarely run more than one or 
two seconds behind.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Monday, November 06, 2017 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TDMF or FDRPAS or how to migrate data

One word of caution to what Skip wrote about a "pull" XRC setup that I 
experienced problems with in the past (12 yrs. ago). If the source side has 
faster DASD than the target side, the target side sent I/O pacing back to the 
source requesting that it slow down. This had a ripple effect on DASD response 
times on the source side that was definitely unacceptable. I am not sure if 
this is still an issue or not, but thought it worth mentioning as a point to 
research/consider.

We replaced the slower DASD on the target side with equal or faster DASD and 
the issue never arose again.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, November 06, 2017 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TDMF or FDRPAS or how to migrate data

We use XRC and TDMF. No experience with PPRC or FDRPAS.

XRC requires DS8* DASD on the source side only, and an XRC code license on the 
source DS8* only. DASD on the target side can be any brand because data is 
written out using normal I/O process. The only requirement is that each source 
and target volume pair 

Re: TDMF or FDRPAS or how to migrate data

[Richards, Robert B.]

I feel like Paul Harvey... now for the rest of the story:

We also had problems with the extended protocol, but it was not the vendor's 
(CNT, I think) fault. IIRC correctly, HDS had promised that they were fully 
functional to do XRC (or HRC as they called it then) from themselves to IBM 
over the CNT topology. Over the course of a year, we  experienced enough 
transmission issues pointing to HDS that we replaced their DASD in the source 
side and upgraded the DASD on the target side to the fastest available from IBM 
at the time. I assume those issues have been resolved by HDS and CNT/McData was 
ultimately acquired by Brocade?

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, November 06, 2017 1:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TDMF or FDRPAS or how to migrate data

Excellent warning. That's why I said "(more or less) invisible to systems on 
the source side". We had a similar experience when we started mirroring around 
Y2K. In our case, the DASD was comparable at both sides, but protocol was ESCON 
extended by third party technology. We got around the problem then with tuning.

Today the problem is non-existent. DASD is FICON extended by DWDM. Most 
important, XRC works differently. Originally any changed data not yet mirrored 
was captured in the 'controller'; that was obviously limited by subsystem 
memory capacity. Now if a volume mirror falls behind, the subsystem maintains 
only a track map of changed data. That map cannot exceed the number of tracks 
regardless of the amount of data involved. Today we rarely run more than one or 
two seconds behind.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Monday, November 06, 2017 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TDMF or FDRPAS or how to migrate data

One word of caution to what Skip wrote about a "pull" XRC setup that I 
experienced problems with in the past (12 yrs. ago). If the source side has 
faster DASD than the target side, the target side sent I/O pacing back to the 
source requesting that it slow down. This had a ripple effect on DASD response 
times on the source side that was definitely unacceptable. I am not sure if 
this is still an issue or not, but thought it worth mentioning as a point to 
research/consider.  

We replaced the slower DASD on the target side with equal or faster DASD and 
the issue never arose again. 

Bob 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, November 06, 2017 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TDMF or FDRPAS or how to migrate data

We use XRC and TDMF. No experience with PPRC or FDRPAS. 

XRC requires DS8* DASD on the source side only, and an XRC code license on the 
source DS8* only. DASD on the target side can be any brand because data is 
written out using normal I/O process. The only requirement is that each source 
and target volume pair geometry must match: 3390-x must be mapped to identical 
3390-x. I/O is asynchronous. Mirroring is (more or less) invisible to systems 
on the source side because data goes straight from the source volume to the 
target system. Although we implemented XRC for DR purposes, we have used it 
twice to migrate data from one data center to another. It works extremely well 
for migration. There is very little outage for the actual migration because all 
data is already in place; just IPL and perform any necessary reconfiguration. 
For DR purposes, we run the SDM data mover on the target side to 'pull' data. 
You can run SDM on the source side, but that did not make sense to us for DR. 
If you have no running system on the target side, and migration is your only 
goal, you can run SDM on the source side and 'push' data; final result should 
be the same.

TDMF is used for moving a volume from one UCB address to another within the 
same complex. When a TDMF move is complete, all sharing systems see the volser 
only at its new location. The old volume UCB is no longer used. I can't imagine 
using TDMF for center-to-center migration because the original volume 
'disappears' on the source side. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, November 06, 2017 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):TDMF or FDRPAS or how to migrate data

The following scenario:
CPC is connected to a DASD 

Re: SUBSYS= ?

[Tony Harminc]

On 6 November 2017 at 11:49, Jesse 1 Robinson 
wrote:

> Throughout this thread, I've been haunted by a dim memory of some SUBSYS
> action in the distant past. We have not had any
> in-house SUBSYS dependencies for decades, so I did not pay very much
> attention.
>
> Did IBM announce long ago that SUBSYS was being deprecated? If so, that
> might explain the dearth of doc. If not, then never mind.
>

A couple of comments on this thread...

The OP was asking specifically about SUBSYS= on a DD statement (and one
might infer, the same via dynamic allocation). Keep in mind that this is
but one aspect of the larger Subsystem Interface (SSI) provided by MVS.

I think it most unlikely that the SSI would be deprecated any time soon,
and I have no recollection of any such announcement. What is clear is that
*effectively* the documentation for many subsystem functions has
disappeared, because there never was formal doc for much of it, and the
source code that was the reference has now mostly gone OCO. Along with the
disappearance of the source-code-as-doc is the appearance of warnings in
the doc that does exist that only the documented SSI calls may be used.
That doc is less than clear about the notion of a user-defined subsystem
that defines its own SSI calls (presumably outside the range of the IBM
ones) and thus provides services to callers who know how to use them. But I
guess that IBM would say that this *is* a supported thing to do, but of
course when your subsystem code breaks, don't call IBM.

The fuzzy part in the middle is writing your own subsystem that supports
IBM-defined calls that are not in the doc, and/or writing your own SSI
caller that makes such calls. Is it possible, for instance, to write your
own Job Entry Subsystem (JES4, perhaps)? Certainly not using the current
IBM doc.

The GPSAM doc itself contains some musing on the subsystem interface and
its level of doc and support, written at a time when OCO was not even on
the horizon. Yet it may even today explain some of why it is as it is.

Gil suggests that the z/OS UNIX VFS interface might be an SSI replacement.
(I think PFS is the more likely interface, but no matter.) I doubt that
this is likely, if only because the PFS/VFS interface comes up relatively
late in the game, but the SSI is available very early. And a simple
subsystem can be very concise but powerful (GPSAM is less than 200 lines of
actual code). Writing even a simple PFS would probably require thousands of
lines of code, and there are many subtle and complex calls that must be
handled.

Tony H.

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

Re: TDMF or FDRPAS or how to migrate data

[Jesse 1 Robinson]

Excellent warning. That's why I said "(more or less) invisible to systems on 
the source side". We had a similar experience when we started mirroring around 
Y2K. In our case, the DASD was comparable at both sides, but protocol was ESCON 
extended by third party technology. We got around the problem then with tuning.

Today the problem is non-existent. DASD is FICON extended by DWDM. Most 
important, XRC works differently. Originally any changed data not yet mirrored 
was captured in the 'controller'; that was obviously limited by subsystem 
memory capacity. Now if a volume mirror falls behind, the subsystem maintains 
only a track map of changed data. That map cannot exceed the number of tracks 
regardless of the amount of data involved. Today we rarely run more than one or 
two seconds behind.  

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Monday, November 06, 2017 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TDMF or FDRPAS or how to migrate data

One word of caution to what Skip wrote about a "pull" XRC setup that I 
experienced problems with in the past (12 yrs. ago). If the source side has 
faster DASD than the target side, the target side sent I/O pacing back to the 
source requesting that it slow down. This had a ripple effect on DASD response 
times on the source side that was definitely unacceptable. I am not sure if 
this is still an issue or not, but thought it worth mentioning as a point to 
research/consider.  

We replaced the slower DASD on the target side with equal or faster DASD and 
the issue never arose again. 

Bob 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, November 06, 2017 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TDMF or FDRPAS or how to migrate data

We use XRC and TDMF. No experience with PPRC or FDRPAS. 

XRC requires DS8* DASD on the source side only, and an XRC code license on the 
source DS8* only. DASD on the target side can be any brand because data is 
written out using normal I/O process. The only requirement is that each source 
and target volume pair geometry must match: 3390-x must be mapped to identical 
3390-x. I/O is asynchronous. Mirroring is (more or less) invisible to systems 
on the source side because data goes straight from the source volume to the 
target system. Although we implemented XRC for DR purposes, we have used it 
twice to migrate data from one data center to another. It works extremely well 
for migration. There is very little outage for the actual migration because all 
data is already in place; just IPL and perform any necessary reconfiguration. 
For DR purposes, we run the SDM data mover on the target side to 'pull' data. 
You can run SDM on the source side, but that did not make sense to us for DR. 
If you have no running system on the target side, and migration is your only 
goal, you can run SDM on the source side and 'push' data; final result should 
be the same.

TDMF is used for moving a volume from one UCB address to another within the 
same complex. When a TDMF move is complete, all sharing systems see the volser 
only at its new location. The old volume UCB is no longer used. I can't imagine 
using TDMF for center-to-center migration because the original volume 
'disappears' on the source side. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, November 06, 2017 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):TDMF or FDRPAS or how to migrate data

The following scenario:
CPC is connected to a DASD box of vendor A (DISK A). The goal is to move the 
data to new DASD box of unlike vendor (DISK B). DISK B is located 150km away 
from DISK A. In location B there will be also another CPC.

Of course it would be nice to do it with very limited disk utilisation and as 
short as possible outage window.

The idea is to move the data in the background over some cable, stop 
production, synchronize all remaining changes, stop the z/OS in location A, 
start z/OS in location B.

Possible solutions, I'm aware:
a) remote copy, like PPRC-XD, HUR, SRDF/A - all those require same vendor, 
since HDS won't talk to IBM or EMC. Unfortunately this is not an option.

b) XRC. Require data mover. Where should it be located? In source or 
destination datacenter? Which DISK need  XRC feature, is it source?

c) software like TDMF or FDRPAS. I have no idea whether such software would 
help for remote 

Re: TDMF or FDRPAS or how to migrate data

[Richards, Robert B.]

One word of caution to what Skip wrote about a "pull" XRC setup that I 
experienced problems with in the past (12 yrs. ago). If the source side has 
faster DASD than the target side, the target side sent I/O pacing back to the 
source requesting that it slow down. This had a ripple effect on DASD response 
times on the source side that was definitely unacceptable. I am not sure if 
this is still an issue or not, but thought it worth mentioning as a point to 
research/consider.  

We replaced the slower DASD on the target side with equal or faster DASD and 
the issue never arose again. 

Bob 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, November 06, 2017 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TDMF or FDRPAS or how to migrate data

We use XRC and TDMF. No experience with PPRC or FDRPAS. 

XRC requires DS8* DASD on the source side only, and an XRC code license on the 
source DS8* only. DASD on the target side can be any brand because data is 
written out using normal I/O process. The only requirement is that each source 
and target volume pair geometry must match: 3390-x must be mapped to identical 
3390-x. I/O is asynchronous. Mirroring is (more or less) invisible to systems 
on the source side because data goes straight from the source volume to the 
target system. Although we implemented XRC for DR purposes, we have used it 
twice to migrate data from one data center to another. It works extremely well 
for migration. There is very little outage for the actual migration because all 
data is already in place; just IPL and perform any necessary reconfiguration. 
For DR purposes, we run the SDM data mover on the target side to 'pull' data. 
You can run SDM on the source side, but that did not make sense to us for DR. 
If you have no running system on the target side, and migration is your only 
goal, you can run SDM on the source side and 'push' data; final result should 
be the same.

TDMF is used for moving a volume from one UCB address to another within the 
same complex. When a TDMF move is complete, all sharing systems see the volser 
only at its new location. The old volume UCB is no longer used. I can't imagine 
using TDMF for center-to-center migration because the original volume 
'disappears' on the source side. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, November 06, 2017 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):TDMF or FDRPAS or how to migrate data

The following scenario:
CPC is connected to a DASD box of vendor A (DISK A). The goal is to move the 
data to new DASD box of unlike vendor (DISK B). DISK B is located 150km away 
from DISK A. In location B there will be also another CPC.

Of course it would be nice to do it with very limited disk utilisation and as 
short as possible outage window.

The idea is to move the data in the background over some cable, stop 
production, synchronize all remaining changes, stop the z/OS in location A, 
start z/OS in location B.

Possible solutions, I'm aware:
a) remote copy, like PPRC-XD, HUR, SRDF/A - all those require same vendor, 
since HDS won't talk to IBM or EMC. Unfortunately this is not an option.

b) XRC. Require data mover. Where should it be located? In source or 
destination datacenter? Which DISK need  XRC feature, is it source?

c) software like TDMF or FDRPAS. I have no idea whether such software would 
help for remote target. Would it?

Any other clue or idea?

--
Radoslaw Skorupka
Lodz, Poland


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

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

Re: Odd SMF 30 data within IEFACTRT

[Martin Packer]

I suspect you’re trying to process records with “only” EXCP sections - so 
probably not the first one cut by the address space in this interval.

SMF 30 can cut multiple - if there are enough EXCP sections.

Cheers, Martin 

Sent from my iPad

> On 6 Nov 2017, at 16:24, DanD  wrote:
> 
> I still find this a little odd but it's explainable.
> The OFFSET field has a value but the COUNT field is zero.
> 
> SMF30USO=04C8 SMF30USL=0040 SMF30USN=
> 
> Why give an offset and length of a null segment.  Weird, but I can code 
> around it.
> 
> Thanks for waking me up ;-)
> 
> Dan
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: TDMF or FDRPAS or how to migrate data

[Jesse 1 Robinson]

We use XRC and TDMF. No experience with PPRC or FDRPAS. 

XRC requires DS8* DASD on the source side only, and an XRC code license on the 
source DS8* only. DASD on the target side can be any brand because data is 
written out using normal I/O process. The only requirement is that each source 
and target volume pair geometry must match: 3390-x must be mapped to identical 
3390-x. I/O is asynchronous. Mirroring is (more or less) invisible to systems 
on the source side because data goes straight from the source volume to the 
target system. Although we implemented XRC for DR purposes, we have used it 
twice to migrate data from one data center to another. It works extremely well 
for migration. There is very little outage for the actual migration because all 
data is already in place; just IPL and perform any necessary reconfiguration. 
For DR purposes, we run the SDM data mover on the target side to 'pull' data. 
You can run SDM on the source side, but that did not make sense to us for DR. 
If you have no running system on the target side, and migration is your only 
goal, you can run SDM on the source side and 'push' data; final result should 
be the same.

TDMF is used for moving a volume from one UCB address to another within the 
same complex. When a TDMF move is complete, all sharing systems see the volser 
only at its new location. The old volume UCB is no longer used. I can't imagine 
using TDMF for center-to-center migration because the original volume 
'disappears' on the source side. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, November 06, 2017 8:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):TDMF or FDRPAS or how to migrate data

The following scenario:
CPC is connected to a DASD box of vendor A (DISK A). The goal is to move the 
data to new DASD box of unlike vendor (DISK B). DISK B is located 150km away 
from DISK A. In location B there will be also another CPC.

Of course it would be nice to do it with very limited disk utilisation and as 
short as possible outage window.

The idea is to move the data in the background over some cable, stop 
production, synchronize all remaining changes, stop the z/OS in location A, 
start z/OS in location B.

Possible solutions, I'm aware:
a) remote copy, like PPRC-XD, HUR, SRDF/A - all those require same vendor, 
since HDS won't talk to IBM or EMC. Unfortunately this is not an option.

b) XRC. Require data mover. Where should it be located? In source or 
destination datacenter? Which DISK need  XRC feature, is it source?

c) software like TDMF or FDRPAS. I have no idea whether such software would 
help for remote target. Would it?

Any other clue or idea?

--
Radoslaw Skorupka
Lodz, Poland


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

Re: SUBSYS= ?

[Paul Gilmartin]

On Mon, 6 Nov 2017 16:49:54 +, Jesse 1 Robinson wrote:

>Throughout this thread, I've been haunted by a dim memory of some SUBSYS 
>action in the distant past. We have not had any
>in-house SUBSYS dependencies for decades, so I did not pay very much 
>attention. 
>
>Did IBM announce long ago that SUBSYS was being deprecated? If so, that might 
>explain the dearth of doc. If not, then never mind. 
> 
Is the function of a z/OS UNIX VFS similar to SUBSYS?  Might IBM see VFS
as a replacement for (deprecated?) SUBSYS?

-- gil

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

Re: SUBSYS= ?

[Barry Merrill]

For what it might be worth, considering free advice may only be worth the price,
the below code is used in MXG Software to decode JCTJOBID into TYPETASK and 
JESNR, and
it tests for all SUBSYS names I have ever seen in any SMF record, which are 
used only
to prevent warning messages about known records that don't have a valid 
JCTJOBID value
to decode. 

Barry  


/* COPYRIGHT (C) 2002,2017 MERRILL CONSULTANTS, DALLAS, TEXAS, USA */
 /* LAST UPDATED: NOV  4, 2017.  CHANGE 35.252. */
 /* THIS ROUTINE EXPECTS JCTJOBID AND JOB AS 8-BYTE CHARACTERS, */
 /* AND SUBSYS AS A 4-BYTE CHARACTER AS INPUT.  */

 /* JCTJOBID OF ONE LETTER AND 7 DIGITS EXIST, BUT THE MAXIMUM  */
 /* JESNR IS 99 BECAUSE THE 1ST WHEN SEVEN IS ALWAYS ZERO.  */

 /* IT CREATES THE 4-BYTE CHARACTER TYPETASK AND NUMERIC JESNR  */
 /* VARIABLES TYPETASK AND JESNR NEED TO BE LABELED IN INVOKER. */

 /* IT IS %INCLUDE-D AFTER JCTJOBID AND SUBSYS EXIST.   */

 TYPETASK='';
 JESNR=.;
 IF SUBSYS=''  THEN SUBSYS=''; /*EARLY ASIDS,TMNT */
 IF JCTJOBID=JOB OR (JCTJOBID LE ' ' AND SUBSYS='STC')
   OR (JCTJOBID EQ ''X AND SUBSYS='SMS')
   OR (JCTJOBID EQ 'MSTR' AND SUBSYS='SMS')
   OR (JCTJOBID EQ 'INIT' AND SUBSYS='SMS') THEN DO;
   JESNR=.;
   TYPETASK='STC';
 END;
 ELSE DO;
   IF INPUT(SUBSTR(JCTJOBID,2,7),?? 7.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,2,7),?? 7.);
 TYPETASK=SUBSTR(JCTJOBID,1,1);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,3,6),?? 6.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,3,6),?? 6.);
 TYPETASK=SUBSTR(JCTJOBID,1,2);
 /* THE PRINTWAY SMF 6 RECORDS HAVE PSNN */
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,4,5),?? 5.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,4,5),?? 5.);
 TYPETASK=SUBSTR(JCTJOBID,1,3);
   END;
   ELSE IF INPUT(SUBSTR(JCTJOBID,5,4),?? 4.) GT . THEN DO;
 JESNR=INPUT(SUBSTR(JCTJOBID,5,4),?? 4.);
 TYPETASK=SUBSTR(JCTJOBID,1,4);
   END;
   IF SUBSYS='TCP ' OR TYPETASK='PS ' THEN TYPETASK='TCP ';
   ELSE IF SUBSYS='TCPE' THEN TYPETASK='TCPE';
   ELSE IF SUBSYS='PSF ' THEN TYPETASK='PSF ';
   ELSE IF SUBSYS='VPS ' THEN TYPETASK='VPS ';
   ELSE IF TYPETASK=:'J' THEN DO;
 IF  SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE   TYPETASK='JOB ';
   END;
   ELSE IF TYPETASK=:'O' OR SUBSYS='OMVS' THEN TYPETASK='OMVS';
   ELSE IF TYPETASK=:'G' THEN TYPETASK='JOBG';
   ELSE IF TYPETASK=:'S' THEN TYPETASK='STC ';
   ELSE IF TYPETASK=:'A' THEN DO;
 IF SUBSYS GT '' THEN TYPETASK=SUBSYS;
 ELSE TYPETASK='APPC';
   END;
   ELSE IF TYPETASK=:'T' THEN TYPETASK='TSU ';
   ELSE IF TYPETASK=:'I' AND SUBSYS='STC' THEN TYPETASK='STC  ';
   ELSE DO;
 IF  SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='TSO ' THEN TYPETASK='TSU ';
 ELSE IF SUBSYS='JES2' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='JES3' THEN TYPETASK='JOB ';
 ELSE IF SUBSYS='STC ' THEN TYPETASK='STC ';
 ELSE IF SUBSYS='OMVS' THEN TYPETASK='OMVS';
 ELSE DO;
   IF PRODUCT='' THEN PRODUCT='';;
   IF SUBTYPE=.  THEN SUBTYPE=.;
   IF PRODUCT='PERFMON ' AND SUBTYPE=3 THEN DO;
 TYPETASK='STC';
 SUBSYS='PERFMON';
   END;
 END;
   END;
   IF TYPETASK=' ' THEN DO;
 BADVJESN+1;
 IF BADVJESN LE 2 THEN
   PUT '*** WARNING - TYPETASK NOT DECODED: ' /  +10
   _N_= SYSTEM= ID= SUBTYPE= JOB=
   JCTJOBID= SUBSYS= TYPETASK= JESNR= ;
   END;
   
 END;
  /* END OF MEMBER VGETJESN - GET JESNR AND TYPETASK FROM JCTJOBID */



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jesse 1 Robinson
Sent: Monday, November 6, 2017 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SUBSYS= ?

Throughout this thread, I've been haunted by a dim memory of some SUBSYS action 
in the distant past. We have not had any in-house SUBSYS dependencies for 
decades, so I did not pay very much attention. 

Did IBM announce long ago that SUBSYS was being deprecated? If so, that might 
explain the dearth of doc. If not, then never mind. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, November 06, 2017 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SUBSYS= ?

I have back to OS/390 V2R8, 1999, on nine CDs. Way pre-PDF. Not there. (Not 
disagreeing with you, just sayin'.)

Perhaps Bitsavers. I don't see it there, but I am not an expert on searching 
Bitsavers.

Perhaps a reader here has an MVS manual they would 

Re: Odd SMF 30 data within IEFACTRT

[Charles Mills]

You have to check all three fields of the triplet for zero (at least if your 
logic is to work across many SMF record types -- perhaps checking offset & 
count is adequate for SMF 30). Any one of them zero indicates no data.

Except! For DB2 SMF, where a zero length indicates the sections are of variable 
length, each prefixed by a 16-bit length field.

Also, some SMF records use a triplet count or last triplet field somewhere 
around +X'20'. Exact fields in the SMF doc. You need to check that to make sure 
your triplet is there at all.

This is why we get the big bucks ...

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of DanD
Sent: Monday, November 6, 2017 8:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Odd SMF 30 data within IEFACTRT

I still find this a little odd but it's explainable.
The OFFSET field has a value but the COUNT field is zero.

SMF30USO=04C8 SMF30USL=0040 SMF30USN=

Why give an offset and length of a null segment.  Weird, but I can code around 
it.

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

Re: SUBSYS= ?

[Jesse 1 Robinson]

Throughout this thread, I've been haunted by a dim memory of some SUBSYS action 
in the distant past. We have not had any
in-house SUBSYS dependencies for decades, so I did not pay very much attention. 

Did IBM announce long ago that SUBSYS was being deprecated? If so, that might 
explain the dearth of doc. If not, then never mind. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Monday, November 06, 2017 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: SUBSYS= ?

I have back to OS/390 V2R8, 1999, on nine CDs. Way pre-PDF. Not there. (Not 
disagreeing with you, just sayin'.)

Perhaps Bitsavers. I don't see it there, but I am not an expert on searching 
Bitsavers.

Perhaps a reader here has an MVS manual they would share.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Monday, November 6, 2017 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SUBSYS= ?

The functions needed are 6, 7, 16-19, 38, 39, & 81.  It has been a very long 
time since they were documented -- pre-PDF, afaik.

sas


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

TDMF or FDRPAS or how to migrate data

[R.S.]

The following scenario:
CPC is connected to a DASD box of vendor A (DISK A). The goal is to move 
the data to new DASD box of unlike vendor (DISK B). DISK B is located 
150km away from DISK A. In location B there will be also another CPC.


Of course it would be nice to do it with very limited disk utilisation 
and as short as possible outage window.


The idea is to move the data in the background over some cable, stop 
production, synchronize all remaining changes, stop the z/OS in location 
A, start z/OS in location B.


Possible solutions, I'm aware:
a) remote copy, like PPRC-XD, HUR, SRDF/A - all those require same 
vendor, since HDS won't talk to IBM or EMC. Unfortunately this is not an 
option.


b) XRC. Require data mover. Where should it be located? In source or 
destination datacenter? Which DISK need  XRC feature, is it source?


c) software like TDMF or FDRPAS. I have no idea whether such software 
would help for remote target. Would it?


Any other clue or idea?

--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając 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 authorized 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.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: SUBSYS= ?

[Charles Mills]

I have back to OS/390 V2R8, 1999, on nine CDs. Way pre-PDF. Not there. (Not 
disagreeing with you, just sayin'.)

Perhaps Bitsavers. I don't see it there, but I am not an expert on searching 
Bitsavers.

Perhaps a reader here has an MVS manual they would share.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Monday, November 6, 2017 8:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SUBSYS= ?

The functions needed are 6, 7, 16-19, 38, 39, & 81.  It has been a very long 
time since they were documented -- pre-PDF, afaik.

sas

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

Re: Odd SMF 30 data within IEFACTRT

[DanD]

I still find this a little odd but it's explainable.
The OFFSET field has a value but the COUNT field is zero.

SMF30USO=04C8 SMF30USL=0040 SMF30USN=

Why give an offset and length of a null segment.  Weird, but I can code around 
it.

Thanks for waking me up ;-)

Dan

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

Re: Odd SMF 30 data within IEFACTRT

[Daniel S. Dalby]

Thanks for having such great eyes.  I thought they looked like TOD values.

Not sure what the problem is...
the base for the SMF record is in R5 and the offset to the field I'm interested 
in is in R1 ...
ICM   R15,15,SMF30USO Offset To Section
BZGETSM800B. If No Section 
ARR15,R5  A(Current Section)   
ARR1,R15  A(SMF Field) 

I'll have to examine the SMF record that I'm processing to see what's messing 
up.

Thanks again
Dan

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

Re: SUBSYS= ?

[Steve Smith]

The functions needed are 6, 7, 16-19, 38, 39, & 81.  It has been a
very long time since they were documented -- pre-PDF, afaik.

sas

On Mon, Nov 6, 2017 at 10:11 AM, Charles Mills  wrote:
>> There are a number of SSI requests that have been un-documented
>
> "Using the Subsystem Interface" for z/OS V2R2 is 626 pages. For z/OS V1R13, 
> 504 pages. Does not seem like anything fell out there. Before that the doc is 
> BookManager and does not have page numbers.
>
> For V2R2, IBM documents function codes 1, 11, 15, 20, 21, 54, 70, 71, 75, 79, 
> 80, 82, 83 & 85.
>
> For V1R10, IBM documents function codes 1, 11, 15, 20, 21, 54, 70, 71, 75, 79 
> & 80.
>
> For OS/390 V2R8, IBM documents function codes 1, 15, 20, 21, 54, 75, 79 & 80.
>
> So at least in the past 18 years it does not look like anything has fallen 
> out of the documentation.
>
> Charles
>

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

Re: Z14 IOCP and USB

[Tom Mathias]

The new z14 support also added support for all three of the "ftp" protocols:  
FTP, SFTP and FTPS.  All three will "proxy" thru the z14 HMC now.  I can't 
speak about z/OS, however.  

Tom Mathias

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

Re: SUBSYS= ?

[Charles Mills]

> There are a number of SSI requests that have been un-documented

"Using the Subsystem Interface" for z/OS V2R2 is 626 pages. For z/OS V1R13, 504 
pages. Does not seem like anything fell out there. Before that the doc is 
BookManager and does not have page numbers.

For V2R2, IBM documents function codes 1, 11, 15, 20, 21, 54, 70, 71, 75, 79, 
80, 82, 83 & 85.

For V1R10, IBM documents function codes 1, 11, 15, 20, 21, 54, 70, 71, 75, 79 & 
80.

For OS/390 V2R8, IBM documents function codes 1, 15, 20, 21, 54, 75, 79 & 80.

So at least in the past 18 years it does not look like anything has fallen out 
of the documentation.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Monday, November 6, 2017 4:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SUBSYS= ?

z/OS has had for a long time something called the SSI, the "SubSystem 
Interface", which implicitly defines a specific kind of subsystem.
Yes, it is an overloaded word, but given the original question, there's really 
no confusion about what is meant here.  For searching, you probably want to 
include some terms like IEFSSIREQ (not exactly that).

There are a number of SSI requests that have been un-documented, including all 
of those needed to support SUBSYS=.  The old documentation can be found 
(maybe), but the CBT and JES2 suggestions are likely anyone's best chance to 
work out how it works.

I have worked on developing such a thing, and I can say that it can be 
difficult.  I do not know what IBM's corporate policy is on doing this.  I 
presume they un-documented it for a reason.

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

Re: SUBSYS= ?

[Phil Smith]

Elardus Engelbrecht wrote:
>>Has the archives search always been busted (FSVO "always")?

>No, not AFAIK. How are you seeing that it is 'busted'?

It returns "No Match" for anything I try. Have you tried it lately?

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

Re: Z14 IOCP and USB

[Rob Schramm]

But of course it doesn't work with z/OS ftp nor SFTP.



So dumb.

Rob Schramm

On Fri, Nov 3, 2017, 11:39 AM Tom Mathias  wrote:

> Starting with the z14, you don't need the SE to be able to connect to the
> FTP server anymore.  The SE will go thru an HMC to get to an FTP server.
> So, your SE's can remain on a more isolated network but one of your HMC's
> adapters must be on a network with connectivity to the FTP server.
>
> This only works for z14 systems (z14 SE thru a z14 HMC).
>
> Tom Mathias
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

Re: Odd SMF 30 data within IEFACTRT

[Martin Packer]

Right; The pair of DD names gives that away.

Cheers, Martin

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

+44-7802-245-584

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

Twitter / Facebook IDs: MartinPacker

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

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



From:   Steve Smith 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   06/11/2017 12:03
Subject:Re: Odd SMF 30 data within IEFACTRT
Sent by:IBM Mainframe Discussion List 



I am sure that he is *not* mapping a zEDC section.  It's plainly
obvious, regardless of the embedded EBCDIC characters, that the data
doesn't match.

As a matter of fact, I can tell that it's looking at a couple of EXCP
sections.  Not that it matters much; the program needs to be debugged.

sas

On Mon, Nov 6, 2017 at 1:14 AM, Mario Bezzi  wrote:
>   Dan,
>
> starting in the middle of SMF30_US_ComprReq I see
> x'E2E3C5D7D3C9C2' which is 'STEPLIB', starting in SMF30_US_Def_UncomprIn
> I see x'E2E8E2D7D9C9D5E3', which is 'SYSPRINT'.
>
> Are you sure you are
> properly pointing to the zEDC section?
>
> On 11/04/2017 09:17 PM, DanD
> wrote:
>
>> I've been looking at various data available within the
> IEFACTRT exit's SMF 30 record.

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




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

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

Re: Standalone IPL ADRDSSU and Operating Systems Messages z14

[Crispin Hugo]

Thank you that very good advice.



Sent from my Samsung Galaxy smartphone.


 Original message 
From: John Eells 
Date: 06/11/2017 07:10 (GMT-05:00)
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Standalone IPL ADRDSSU and Operating Systems Messages z14

> Is there anything in the z14 PSP bucket?

Well, yes, there is. And several years ago I'd have asked the very same
question.

However, we highly recommend using FIXCATs to identify the PTFs needed
for z14s. Reliance on manual PSP-based procedures seems to be the
proximate cause of about a zillion questions and issues that simply
would not arise for those who get the current 2-year HOLDDATA file and
let SMP/E tell you what's missing. (Get that file from the Enhanced
HOLDDATA website or by using RECEIVE ORDER, which always gives you the
2-year file.)


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

Re: SUBSYS= ?

[Steve Smith]

z/OS has had for a long time something called the SSI, the "SubSystem
Interface", which implicitly defines a specific kind of subsystem.
Yes, it is an overloaded word, but given the original question,
there's really no confusion about what is meant here.  For searching,
you probably want to include some terms like IEFSSIREQ (not exactly
that).

There are a number of SSI requests that have been un-documented,
including all of those needed to support SUBSYS=.  The old
documentation can be found (maybe), but the CBT and JES2 suggestions
are likely anyone's best chance to work out how it works.

I have worked on developing such a thing, and I can say that it can be
difficult.  I do not know what IBM's corporate policy is on doing
this.  I presume they un-documented it for a reason.

sas

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

Re: Standalone IPL ADRDSSU and Operating Systems Messages z14

[John Eells]

Is there anything in the z14 PSP bucket?


Well, yes, there is. And several years ago I'd have asked the very same 
question.


However, we highly recommend using FIXCATs to identify the PTFs needed 
for z14s. Reliance on manual PSP-based procedures seems to be the 
proximate cause of about a zillion questions and issues that simply 
would not arise for those who get the current 2-year HOLDDATA file and 
let SMP/E tell you what's missing. (Get that file from the Enhanced 
HOLDDATA website or by using RECEIVE ORDER, which always gives you the 
2-year file.)



--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Odd SMF 30 data within IEFACTRT

[Steve Smith]

I am sure that he is *not* mapping a zEDC section.  It's plainly
obvious, regardless of the embedded EBCDIC characters, that the data
doesn't match.

As a matter of fact, I can tell that it's looking at a couple of EXCP
sections.  Not that it matters much; the program needs to be debugged.

sas

On Mon, Nov 6, 2017 at 1:14 AM, Mario Bezzi  wrote:
>   Dan,
>
> starting in the middle of SMF30_US_ComprReq I see
> x'E2E3C5D7D3C9C2' which is 'STEPLIB', starting in SMF30_US_Def_UncomprIn
> I see x'E2E8E2D7D9C9D5E3', which is 'SYSPRINT'.
>
> Are you sure you are
> properly pointing to the zEDC section?
>
> On 11/04/2017 09:17 PM, DanD
> wrote:
>
>> I've been looking at various data available within the
> IEFACTRT exit's SMF 30 record.

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

Re: C/C++ Runtime Library

[Thomas David Rivers]

Ze'ev Atlas wrote:

I hope that I word my question correctlyIs the C/C++ Runtime Library installed by default on z/OS  or is it a product that needs to be licensed separately?In other words, if I distribute a software product, written in C, in binary form (load modules) and that product rely on the runtime library, what is the likelihood that the client's installations out there would not be able to run the product because the runtime library is not present? 
Ze'ev Atlas


 

Let me also speak as a vendor; for Dignus C/C++ (in he default mode of 
operation)
the runtime is linked with the program.  There is no dependency on an 
externally
loaded component - or LE.   So, you don't have to worry about version 
compatibility.


 - Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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

Re: SUBSYS= ?

[Elardus Engelbrecht]

Phil Smith wrote:

>I'm trying to understand more about using a SUBSYS= on a DD. The problem is 
>that Googling "z/OS" and "subsys" or "subsystem" isn't exactly fruitful, 

The word 'subsystem' has many meanings and you will certainly overflow your 
search results with junk.


>and the IBM-MAIN archives search seems to be broken (unless nobody has ever 
>mentioned "jcl").

Perhaps your search argument(s) are incorrect? I never have trouble using it. I 
just use another set of search arguments or combinations of that. Yes, it can 
be tiresome, if you use words like 'JCL', 'MVS', 'RACF', 'JES2'... ;-)

... or USS (to the dismay of some one not active anymore on IBM-MAIN...)   ;-D 

PS: It is really tiresome to choose which one of these two to use as search 
argument: TCPIP or TCP/IP. Which one is 'better'?


>Can someone point me at a book that talks about what this does and how one 
>would implement one?

You have gotten good repliess: JCL Ref about SUBSYS statement, CBT Tape 
examples, z/OS bookies, etc.

You could also look at EREP and System Logger in KC.

So, after you read all these books and samples, it seemed to me that 
'subsystem' is a specific subsystem (re-use of that word!) or service which 
does an ad-hoc job or work on something.

Either you use an existing subsystem or you write one yourself.


>Has the archives search always been busted (FSVO "always")?

No, not AFAIK. How are you seeing that it is 'busted'?

Groete / Greetings
Elardus Engelbrecht

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

Re: C/C++ Runtime Library

[Ze'ev Atlas]

Thank you everybody for the answers.The ZS, ARCH and TUNE numbers will be taken 
into account Ze'ev Atlas

 


   

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