Re: SMS & GDG SCRATCH option
Yes, that's correct. The ACS routines get control for new individual GDG generations at allocation time, not for catalog entries. The GDG base is a catalog entry and is created at IDCAMS DEFINE GDG time. So while the systemwide defaults can be set in IGGCATxx, they can be overridden by anyone defining a GDG by simply specifying the desired values in the DEFINE GDG control statement. Using ACC, which gets control at SVC 26 (DEFINE) time, one can set policy rules which will take precedence over both the IGGCATxx defaults and the IDCAMS DEFINE GDG specification. So if you wanted to force GDGs to be defined as extended-format, NOSCRATCH, FIFO, etc., you'd specify this in the ACC policy rules. You could also do things like have ACC check some arbitrary RACF resource to see if a user is authorized to specify SCRATCH or NOSCRATCH, etc. Similarly, ACC policy rules can control the use of pretty much any IDCAMS parameter on DEFINE or DELETE as well as overriding any JCL or dynamic allocation values (space, VOLSER, UNIT, etc) for ordinary non-VSAM or VSAM datasets. Steve Pryor DTS Software, LLC st...@dtssoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
A question or two on zOS issues
There are a couple of pressing issues in z/OS that I'm sure many folks are aware of but about which there doesn't seem to be much being done. I'm curious as to what other IBM-MAINer's thoughts might be. Specifically, I'm talking about: 1.) migration to IBM's latest COBOL release, and 2.) the not-really-that-far-off issue of Year 2042 I've been asked several times recently whether we (a z/OS ISV) should consider developing products to address these issues. Frankly, though, I live in an ivory tower and while I sometime *think* I know what installations problems and needs are, I'm usually surprised to find that reality is quite different. So I'd like to throw a couple of questions out to the list for comment: 1.) Would a reporting utility that determined which COBOL programs were executed (and which ones weren't), and what release and options they were compiled with be significantly helpful in a COBOL migration? What other features would be nice to have? Or is this a low priority for most installations, who are perhaps trying to justify keeping the mainframe alive and/or conducting business as usual, let alone doing a COBOL migration project? 2.) It's rather shocking that 2042 is so close and not much seems to be happening. We are one of the vendors that have a date-simulation utility, but we don’t know if data centers have any near-term plans for 2042. Would it be worthwhile to have a 2042 date-simulation product now, or is everyone going to cross their fingers and try to use a test LPAR once the operating system fully supports 2042 dates? Thanks for any comments and insight the IBM-MAIN hive mind might have. Steve Pryor CTO DTS Software, LLC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Courses for Storage Admin Newbies
There does indeed seem to be a lack of educational resources, not just for storage administration, but also particularly for 'newbies' to the platform. IBM seems to be trying to make progress with DFSMS Academy and such but there's a much bigger need since very few colleges teach much about the mainframe. We (DTS Software) don't have a formal 'course' (at least not yet), but I've done a lot of one-hour public webinars over the past few years that we've made available on the DTS website. Lately I've been concentrating on 'introductory' topics, and we've seen a real increase in attendance for those. You might find some of these useful. Steve Steve Pryor DTS Software, LLC st...@dtssoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "Wrong" Size Allocation with AVGREC?
I think we need to 'see the work'. You mention 'copying' the dataset. But allocation doesn't depend on the program being executed - only the SPACE specification. So if you allocate something like: //DG2 EXEC PGM=IEBDG //SYSPRINT DD SYSOUT=* //SEQOUT DD DSN=SJP.AVGR.DATA,DISP=(,CATLG), // LRECL=80,BLKSIZE=27920,RECFM=FB,DSORG=PS, // SPACE=(80,698),AVGREC=U //SYSIN DD * DSD OUTPUT=(SEQOUT) FD NAME=FIELD1,STARTLOC=1,LENGTH=4,PICTURE=4,B'0001',INDEX=1 CREATE QUANTITY=698,NAME=FIELD1 And then run an IEHLIST against the resulting dataset, it should occupy one track: CONTENTS OF VTOC ON VOL SMS007 ---DATA SET NAME SER NO SEQNO DATE.CRE DATE.EXP DATE.REF EXT DSORG RECFM OPTCD BLKSIZE SJP.AVGR.DATA SMS007 1 2021.08200.000 2021.0821 PS FB 0027920 SMS.IND LRECL KEYLEN INITIAL ALLOC 2ND ALLOCEXTEND LAST BLK(T-R-L) DIR.REM F2 OR F3(C-H-R) DSCB(C-H-R) S80TRKS 00BY 0 2 1700 1 7 EATTR NS EXTENTS NO LOW(C-H) HIGH(C-H) 0 4 134 13 ON THE ABOVE DATA SET,THERE ARE 0 EMPTY TRACK(S). One possibility is that the Default Device Geometry in the your SMS configuration is 47476 rather than 56664 (i.e., 3380 rather than 3390). If you're copying the dataset with an application such as Sort or something similar, the application may alter the output allocation or may automatically taken another extent. Another possibility is a vendor product such ours (ACC) or others (from BMC, CA, etc), that might automatically alter certain allocations. Steve Steve Pryor DTS Software LLC st...@dtssoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP-SSL from z/OS client to Linux
I have to remember to look at the IBM-MAIN list rather than the archives. Thanks, everybody, for your help. I'm glad to have another means of tracing for the (shudder) next time around. Steve Steve Pryor DTS Software, LLC st...@dtssoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP-SSL from z/OS client to Linux
Well, after considerable struggle involving setting up a completely new FTP server and experimenting with virtually every possible setting on both sides, it seems that this can occur if the TLS level used by the z/OS client isn't supported by the Linux ProFTPD server. Some settings rejiggering fixes it. But talk about a misleading message... Steve Steve Pryor DTS Software, LLC st...@dtssoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP-SSL from z/OS client to Linux
I thought perhaps that was it, since I didn't (previously) have the entire CA certificate chain on the keyring and I don't think the certificate was being presented. But I've corrected that and it seems to be using the correct certificate according to the trace below. But I'm still getting the same ' Content type 53 is not supported' error. Perhaps I'm not understanding something in the trace? Steve Pryor DTS Software, LLC st...@dtssoftware.com S0W1 MESSAGE 0001 03:04:16.329604 SSL_ENTRY Job SJP1 Process 050102AA Thread 0001 gsk_get_default_label Handle 1FCA4AF0 S0W1 MESSAGE 0002 03:04:16.330203 SSL_EXIT Job SJP1 Process 050102AA Thread 0001 gsk_get_default_label Exit status (0) Default label 'ExaVault FTP Server' S0W1 MESSAGE 0008 03:04:16.330770 SSL_INFO Job SJP1 Process 050102AA Thread 0001 gsk_secure_socket_init Using client certificate 'ExaVault FTP Server' S0W1 MESSAGE 0008 03:04:16.331372 SSL_INFO Job SJP1 Process 050102AA Thread 0001 gsk_query_security_level Security level 0x0007 S0W1 MESSAGE 0008 03:04:16.331945 SSL_INFO Job SJP1 Process 050102AA Thread 0001 edit_ciphers Initial SSL V2 cipher specs: 34 S0W1 MESSAGE 0008 03:04:16.332537 SSL_INFO Job SJP1 Process 050102AA Thread 0001 edit_ciphers SSL V2 cipher specs: 34 S0W1 MESSAGE 0008 03:04:16.38 SSL_INFO Job SJP1 Process 050102AA Thread 0001 edit_ciphers Initial SSL V3 2-character cipher specs: S0W1 MESSAGE 0008 03:04:16.333903 SSL_INFO Job SJP1 Process 050102AA Thread 0001 edit_ciphers 3538392F3233 S0W1 MESSAGE 0008 03:04:16.335928 SSL_INFO Job SJP1 Process 050102AA Thread 0001 edit_ciphers SSL V3 cipher specs: 3538392F3233 S0W1 MESSAGE 0008 03:04:16.336795 SSL_INFO Job SJP1 Process 050102AA Thread 0001 default_setsocketoptions FIONBIO turned off for socket 1 S0W1 MESSAGE 0008 03:04:16.337704 SSL_INFO Job SJP1 Process 050102AA Thread 0001 default_setsocketoptions TCP_NODELAY set for socket 1 S0W1 MESSAGE 0008 03:04:16.338294 SSL_INFO Job SJP1 Process 050102AA Thread 0001 gsk_perform_v3_client_handshake Performing SSL V3 client handshake with 67.208.93.232.21. S0W1 MESSAGE 0001 03:04:16.338944 SSL_ENTRY Job SJP1 Process 050102AA Thread 0001 crypto_generate_random_bytes Length 32 S0W1 MESSAGE 0002 03:04:16.339510 SSL_EXIT Job SJP1 Process 050102AA Thread 0001 crypto_generate_random_bytes Exit status (0) S0W1 MESSAGE
FTP-SSL from z/OS client to Linux
Job SJP1 Process 0501028D Thread 0001 gsk_secure_socket_init SSL V3 client handshake failed with 67.208.93.232.21. The server seems to be objecting to the x'35' (decimal 53) in the 'ContentType' field of the CLIENT-HELLO message. In RFC8446 it says " Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST terminate the connection with an "unexpected_message" alert. " Does anyone have any idea why the z/OS client is doing this? Surely some people are doing FTPS from z/OS to Linux somewhere. I've tried it on a couple of different z/OS levels with the same result. Any help is much appreciated. Steve Pryor DTS Software, LLC st...@dtssoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMM/OAM/SMS
The storage group name is assigned by the storage group ACS routine. RMM appends the storage group name to the mount message and updates the Load Display to use the storage group name. This allows you to have different ranges of tape volumes for each storage group, i.e., the storage groups correspond to the RMM 'scratch pools'. If the tape volser doesn't matter, you can assign all the tapes to a single RMM scratch pool in the VLPOOL statement, or don't have the ACS routine assign a storage group. Steve Steve Pryor DTS Software, LLC st...@dtssoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TS7720 to EMC DLM migration
In answer to your question, there are plenty of "things to be done", depending
upon factors such as:
- what tape management system do you have? Will the new technology share the
scratch volser range or will a new one be used?
- will the migration be performed volume-by-volume ('cloning') or
dataset-by-dataset (copy)?
- do applications maintain their own tape metadata repositories outside of the
tape management system (CA-View, HSM, others)?
- how many drives/how much time will be available for the migration as opposed
to production work?
- are the source/target volumes going to be SMS managed or will UNIT esoterics
be used?
- how many datasets and how much data needs to be migrated vs how much can
'naturally' expire or roll off? What's the target date?
- who's going to perform the migration tasks? Contractors? Vendors? In-house
staff?
There are lots of issues to consider. You might want to have a look at some of
the Share proceedings on this topic. I've done a few of these in the past both
as general education and in conjunction with our tape migration software (see
Share Sessions such as 11020 and 14361, among many others).
Steve Pryor
DTS Software, Inc.
1.919.833.8426 x162
st...@dtssoftware.com
www.dtssoftware.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: System Exit
There are a couple of vendor products that could do this, including ours (SRS, which is our successor product to our original STOP-X37). You could, if you wanted to write your own IGGPRE00 exit, do this, but products such as SRS provide a lot more feature and function. Steve Pryor DTS Software, LLC 1.919.833.8426 x162 st...@dtssoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
