CHPID dynamic Activation error
Hello Group, For our New storage Box,While dynamically adding new CHPID to existing control UNIT, I tried displaying new CHIPD but its only show that path are online not operational. I have referred the below link but I am not able to get any Clue. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2M9C1/SPTM013022 D M=CHP(E2) IEE174I 23.18.04 DISPLAY M 250 CHPID E2: TYPE=1A, DESC=FICON POINT TO POINT, ONLINE DEVICE STATUS FOR CHANNEL PATH E2 0 1 2 3 4 5 6 7 8 9 A B C D E F 300 * * * * * * * * * * * * * * * * 301 * * * * * * * * * * * * * * * * 302 * * * * * * * * * * * * * * * * 303 * * * * * * * * * * * * * * * * 304 * * * * * * * * * * * * * * * * 305 * * * * * * * * * * * * * * * * 306 * * * * * * * * * * * * * * * * 307 * * * * * * * * * * * * * * * * 308 AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL 309 AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL 30A AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL IOS444I DYNAMIC PATHING NOT OPERATIONAL ON PATH (3F38,E2) IOS444I DYNAMIC PATHING NOT OPERATIONAL ON PATH (3F3E,E2) IOS444I DYNAMIC PATHING NOT OPERATIONAL ON PATH (3F3F,E2) Could someone please shed light on the above. Any suggestions or directions are much appreciated. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: USS Callable Assembler Services
Hi Sometimes it is worth to look into the proper (in this case msgsnd) C/C++ documentation. Seems to me , in some cases the USS Callable Services and the C/C++ Runtime Library Reference together complete. On 20.11.2013 15:20, esst...@juno.com wrote: I have found out that the documentation is poor. This sequence of Instructions is correct. L 15,16 CVT - common vector table L 15,544(15) CSRTABLE L 15,24(15) CSR slot L 15,offset(15) Address of the service BALR 14,15 Branch and link The issue with the Reason Code has to do with the setting of the MSG_TYPE. The documentation does not expalin it well enough that the MSG_ID returned from BXP1QGT needs to be stored in the MSG_TYPE field prior to the MSG_TEXT before issuing BPX1QSND. I can noe WRITE and RED from the queue. Thanks To All Who responded. Paul D'Angelo -- Original Message -- From: Tony Harminc t...@harminc.net To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: USS Callable Assembler Services Date: Mon, 18 Nov 2013 15:17:59 -0500 On 18 November 2013 14:36, esst...@juno.com esst...@juno.com wrote: Tom Marchant and others pointed out I don't have an answer to your questions, but I think you mean LA 15,16 And I agree, However From z/OS UNIX System Services Programming: Assembler Callable Services Reference SA23-2281-00 The following is an example of code that specifies the offset. The example assumes that register 1 is set up with the address of the parameter list. Replace offset with the appropriate value from the following offset table. L 15,16 CVT - common vector table L 15,544(15) CSRTABLE L 15,24(15) CSR slot L 15,offset(15) Address of the service BALR 14,15 Branch and link I suspect the documentation is wrong It's not wrong, and changing L to LA would break what you have. You could indeed use the IHAPSA and CVT macros and avoid use of hard-coded constants, but the problem with this is that the CSRTABLE and what it points to are OCO, so there are no IBM-supplied mappings or names. I wrote a little macro that contains roughly what you show above. It takes the service name as an argument and generates the call with the offset and arguments. There are other services reached through the CSRTABLE with offsets other than 24; some of them are documented to various extents, and others not at all. Tony H. -- 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 -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reviewing hardware configuration
Hi, A short answer to your question is to get the Hardware Management Console(HMC) and Service Element(SE) guides for your particular processor model. Pretty much everything you ever want to know about processor configuration setting information is in those books. You'll also find the z/OS Initialization and Tuning guide and/or z/VM CP Planning and Administration and CMS Planning and Administration guides handy when researching OS-related settings. Now, exactly what to configure each setting at depends on what kind of CP you have, how much central storage you have, how many I/O channels and how they're configured, how many LPAR's do you have, how big is each one, etc. The list gets long and there are no simple answers, largely because many settings depend on what a related settings is, e.g., settings A B each depend on what C is set to which might be processor-dependent. It is VERY educational. Good luck and try to enjoy yourself doing this. Kent Kent Ramsay System Programmer PEMCO Corporation kent.ram...@pemco.com www.pemco.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CHPID dynamic Activation error
I would start by doing an internet search on your messages IOS444I. There should be some helpful hints out there. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jake anderson Sent: Thursday, November 21, 2013 1:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CHPID dynamic Activation error Hello Group, For our New storage Box,While dynamically adding new CHPID to existing control UNIT, I tried displaying new CHIPD but its only show that path are online not operational. I have referred the below link but I am not able to get any Clue. http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/IEA2M9C1/SPTM013022 D M=CHP(E2) IEE174I 23.18.04 DISPLAY M 250 CHPID E2: TYPE=1A, DESC=FICON POINT TO POINT, ONLINE DEVICE STATUS FOR CHANNEL PATH E2 0 1 2 3 4 5 6 7 8 9 A B C D E F 300 * * * * * * * * * * * * * * * * 301 * * * * * * * * * * * * * * * * 302 * * * * * * * * * * * * * * * * 303 * * * * * * * * * * * * * * * * 304 * * * * * * * * * * * * * * * * 305 * * * * * * * * * * * * * * * * 306 * * * * * * * * * * * * * * * * 307 * * * * * * * * * * * * * * * * 308 AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL 309 AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL 30A AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL AL IOS444I DYNAMIC PATHING NOT OPERATIONAL ON PATH (3F38,E2) IOS444I DYNAMIC PATHING NOT OPERATIONAL ON PATH (3F3E,E2) IOS444I DYNAMIC PATHING NOT OPERATIONAL ON PATH (3F3F,E2) Could someone please shed light on the above. Any suggestions or directions are much appreciated. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS (UNCLASSIFIED)
Where do the -71 and -16 come from? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Storr, Lon A CTR USARMY HRC (US) lon.a.storr@mail.mil Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Thu, 21 Nov 2013 19:11:58 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE According to my personal notes The restriction of 127 extents per volume (device) comes from the DEB: DEBLNGTH is the number of double-words in the DEB (up to 255 === 255 * 8 = 2040; (2040 - 71) / 16 = 123). The restriction of 59 volumes (devices) per DD comes from the TIOT: TIOELNGH is the number of bytes in the TIOT entry (up to 255 === (255 - 16) / 4 = 59) Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DASDBILL2 Sent: Thursday, November 21, 2013 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS I think there was some rational explanation given several years ago. Check the archives, John. Something about how many whatevers could fit within one such-and-such, where both are control blocks within a VSAM catalog structure. I disagree with the other post that mentioned up to five different extents to satisfy the primary size. If this were true, then we wouldn't have a limit of 16 extents for a non-VSAM data set, but rather 12 (16 minus 4). Each of those five extents that might be necessary to fulfill the primary request count towards the total, whether the total is 123 or 16. And, since the primary request could also be fulfilled with only one extent, then there can still be 122 more non-primary extents in a VSAM data set. Bill Fairchild Franklin, TN - Original Message - From: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 21, 2013 11:11:46 AM Subject: Re: Extents limit for HFS Why the magic number of 123 extents per volume? 127 is more plausible. What else is going on here? On 11/21/13, John Eells ee...@us.ibm.com wrote: z/OS DFSMS Using Data Sets, topic 3.9.2.1, Creating HFS Data Sets: ... These data sets can expand to as many as 255 extents of DASD space on multiple volumes (59 volumes maximum with 123 extents per volume). John Gilmore, Ashland, MA 01721 - USA -- 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 Classification: UNCLASSIFIED Caveats: NONE -- 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: Getting a VSAM data set's system timestamp
I am not sure that the time stamp is updated until the file is actually closed. So if the file is open for a long time, the time stamp may not reflect what you are looking for. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robin Atwood Sent: Thursday, November 21, 2013 5:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Getting a VSAM data set's system timestamp I want our file server to be able to tell the clients when a data set last changed. For non-VSAM it's easy (if a bit vague), there's the last reference date in the F1 DSCB. For VSAM you can see a SYSTEM-TIMESTAMP in the LISTCAT output but how do you get that from a program? We currently use IGGCSI00 for VSAM info but there is no field name for the timestamp. The SHOWCAT macro does not seem to show all that much at all. Any ideas out there? I am hoping I have missed something. TIA Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: smf records for updating racf profiles
Hi Kees, That's exactly what I did, went to the SMF manual where I found the pointer to the RACF book. In retrospect I should have mentioned the SMF book pointer and/or put quotes around my 'cleverly hidden' comment. Take care, Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP - SPLXM Sent: Thursday, November 21, 2013 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: smf records for updating racf profiles Rex, Your 'hidden' description triggered me: a few years ago I was looking for an SMF record from a product (somewhere in the 90 range, I don't know exactly which anymore). I found nothing in the SMF manual and after consulting IBM, it appeared to be described in the product manuals. I argued that each SMF record should be anchored in *the* SMF manual, at least with a pointer to the real manual. IBM agreed and added a chapter in the SMF manual with a link to the correct manual. The SMF 80 also appears to be nicely documented in the SMF manual with a pointer to the appropriate manual, so it is not hidden from people who try, using common sense, to find this SMF information in the SMF manual. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Thursday, November 21, 2013 15:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: smf records for updating racf profiles SMF type 80, cleverly hidden in the RACF Macros and Interfaces manual. :-) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tim Brown Sent: Thursday, November 21, 2013 7:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: smf records for updating racf profiles Which smf records will give detail on creates/updates/deletes for racf discrete/generic profiles Thanks, Tim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff
Re: Extents limit for HFS
I think there was some rational explanation given several years ago. Check the archives, John. Something about how many whatevers could fit within one such-and-such, where both are control blocks within a VSAM catalog structure. I disagree with the other post that mentioned up to five different extents to satisfy the primary size. If this were true, then we wouldn't have a limit of 16 extents for a non-VSAM data set, but rather 12 (16 minus 4). Each of those five extents that might be necessary to fulfill the primary request count towards the total, whether the total is 123 or 16. And, since the primary request could also be fulfilled with only one extent, then there can still be 122 more non-primary extents in a VSAM data set. Bill Fairchild Franklin, TN - Original Message - From: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 21, 2013 11:11:46 AM Subject: Re: Extents limit for HFS Why the magic number of 123 extents per volume? 127 is more plausible. What else is going on here? On 11/21/13, John Eells ee...@us.ibm.com wrote: z/OS DFSMS Using Data Sets, topic 3.9.2.1, Creating HFS Data Sets: ... These data sets can expand to as many as 255 extents of DASD space on multiple volumes (59 volumes maximum with 123 extents per volume). John Gilmore, Ashland, MA 01721 - USA -- 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: Extents limit for HFS (UNCLASSIFIED)
The limit of 16 extents per volume for a non-VSAM data set dates back to the mid-1960s and release 1 of OS/360. A Format 1 DSCB has space for 3 extent descriptors and a pointer to a Format 3 DSCB, which has space for 13 more extent descriptors AND ALSO a pointer to another Format 3 DSCB. Thus the VTOC was architected to allow an infinite number of extents in one data set, as long as the volume has enough free space for one more Format 3 DSCB. For reasons unknown to me now, but probably due to the smallness and expense of storage in the 1960s, IBM chose to cap a data set's VTOC usage to a maximum of two DSCBs for a non-ISAM data set and three for an ISAM data set. The way VSAM data sets are described in terms of DSCBs is that you start with a Format 1, it points to a Format 3, that F3 can then point to another F3, etc. up to however many F3 DSDBs are needed to hold all the extents that are allowed by some other constraint somewhere in the system software. That is the only reason why a VSAM data set is limited to 123 extents. Nine full Format 3 DSCBs can be used with a 10th Format 3 DSCB having only three of its possible 13 extent descriptor slots filled in. Somewhere else in MVS is the limit of 123 imposed. This limit came about when VSAM was invented along with making OS/360 use virtual storage. The system catalog's internal structure was redesigned at the same time to use VSAM in which to store catalog entries. So the limit of 123 extents, I believe, is related to some part of a VSAM catalog's internal structure. One DEB can have 255 different extent entries in it. They could theoretically all be on the same volume if there weren't the other constraint about 16 extents per volume for one data set. In fact they can be all on the same volume if multiple different data sets, all on one volume, are concatenated. Remember the DEB was invented in the mid-1960s also, long before VSAM came along with the new larger 123 extent limit. I don't know about the limit of 59 volumes per data set. The TIOT's constraint looks like a reasonable explanation. Bill Fairchild Franklin, TN - Original Message - From: Lon A CTR USARMY HRC Storr (US) lon.a.storr@mail.mil To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 21, 2013 1:11:58 PM Subject: Re: Extents limit for HFS (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE According to my personal notes The restriction of 127 extents per volume (device) comes from the DEB: DEBLNGTH is the number of double-words in the DEB (up to 255 === 255 * 8 = 2040; (2040 - 71) / 16 = 123). The restriction of 59 volumes (devices) per DD comes from the TIOT: TIOELNGH is the number of bytes in the TIOT entry (up to 255 === (255 - 16) / 4 = 59) Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DASDBILL2 Sent: Thursday, November 21, 2013 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS I think there was some rational explanation given several years ago. Check the archives, John. Something about how many whatevers could fit within one such-and-such, where both are control blocks within a VSAM catalog structure. I disagree with the other post that mentioned up to five different extents to satisfy the primary size. If this were true, then we wouldn't have a limit of 16 extents for a non-VSAM data set, but rather 12 (16 minus 4). Each of those five extents that might be necessary to fulfill the primary request count towards the total, whether the total is 123 or 16. And, since the primary request could also be fulfilled with only one extent, then there can still be 122 more non-primary extents in a VSAM data set. Bill Fairchild Franklin, TN - Original Message - From: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 21, 2013 11:11:46 AM Subject: Re: Extents limit for HFS Why the magic number of 123 extents per volume? 127 is more plausible. What else is going on here? On 11/21/13, John Eells ee...@us.ibm.com wrote: z/OS DFSMS Using Data Sets, topic 3.9.2.1, Creating HFS Data Sets: ... These data sets can expand to as many as 255 extents of DASD space on multiple volumes (59 volumes maximum with 123 extents per volume). John Gilmore, Ashland, MA 01721 - USA -- 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 Classification: UNCLASSIFIED Caveats: NONE -- For IBM-MAIN subscribe /
VVDS delete
I was cleaning up VVDSs from empty volumes. I did one volume too many. The VSAM datasets are still on the volume (MOBIOUS Linear VSAM). Do I DEFINE RECATALOG the VVDS? Do I need to DEFINE RECATALOG to all the various catalogs? After getting the VVDS reset, do I need to DEFINE RECATALOG the individual datasets? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS
The magic number of 123 extents per volume is because the primary space in the DEFINE can actually take up to 5 extents to satisfy the request. Adding the 4 'secondary primary' extents to the 123 total extents totals the 127. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Thursday, November 21, 2013 11:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS Why the magic number of 123 extents per volume? 127 is more plausible. What else is going on here? On 11/21/13, John Eells ee...@us.ibm.com wrote: z/OS DFSMS Using Data Sets, topic 3.9.2.1, Creating HFS Data Sets: ... These data sets can expand to as many as 255 extents of DASD space on multiple volumes (59 volumes maximum with 123 extents per volume). John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS
At 18:44 + on 11/21/2013, DASDBILL2 wrote about Re: Extents limit for HFS: I disagree with the other post that mentioned up to five different extents to satisfy the primary size. If this were true, then we wouldn't have a limit of 16 extents for a non-VSAM data set, but rather 12 (16 minus 4). The 16 extent Non-VSAM limit is because the first 3 extents are in the Format 1 VTOC record (The file definition record) and there is room for 13 extents in a Format 3 (I think that is the right format number) record chained from the Format 1. Non-VSAM Format 3 records either do not have or are not allowed to use a link field to point at another Format 3. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Type 64 - SMF64RIN - Bit 01 on?
Well, shoot, there's a note right there in the SMF manual. Silly me, I just looked at the documentation for the field itself. All it says for Bit 7 is Reserved. I didn't read every word of the SMF manual. 1. If SMF64RIN=X'01', there will be no extended information written for this record (SMF64ESL). For more information, please review APAR OW56162 (for hdz11f0 and hdz11g0 users). For diagnostic purposes, VSAM EOV writes an SMF64 record when there is a record management catalog update request. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barry Merrill Sent: Thursday, November 21, 2013 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF Type 64 - SMF64RIN - Bit 01 on? Change 20.212 Support for APAR OW56162 for SMF type 64 new VSAM EOV SMF VMAC64 that is written when there is a record management catalog Oct 3, 2002 update request. Variable SITUIND='CATALOG UPDATE' is set from SMF64RIN bit 7 for this new event; this record will not contain any extent information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS (UNCLASSIFIED)
IIRC you can get 127 extents for a VSAM dataset but only in the 123rd extent is satisfied with 5 extents CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 740 5459 (tel) | ken.porow...@cit.com This email message and any accompanying materials may contain proprietary, privileged and confidential information of CIT Group Inc. or its subsidiaries or affiliates (collectively, “CIT”), and are intended solely for the recipient(s) named above. If you are not the intended recipient of this communication, any use, disclosure, printing, copying or distribution, or reliance on the contents, of this communication is strictly prohibited. CIT disclaims any liability for the review, retransmission, dissemination or other use of, or the taking of any action in reliance upon, this communication by persons other than the intended recipient(s). If you have received this communication in error, please reply to the sender advising of the error in transmission, and immediately delete and destroy the communication and any accompanying materials. To the extent permitted by applicable law, CIT and others may inspect, review, monitor, analyze, copy, record and retain any communications sent from or received at this email address. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DASDBILL2 Sent: Thursday, November 21, 2013 3:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Extents limit for HFS (UNCLASSIFIED) The limit of 16 extents per volume for a non-VSAM data set dates back to the mid-1960s and release 1 of OS/360. A Format 1 DSCB has space for 3 extent descriptors and a pointer to a Format 3 DSCB, which has space for 13 more extent descriptors AND ALSO a pointer to another Format 3 DSCB. Thus the VTOC was architected to allow an infinite number of extents in one data set, as long as the volume has enough free space for one more Format 3 DSCB. For reasons unknown to me now, but probably due to the smallness and expense of storage in the 1960s, IBM chose to cap a data set's VTOC usage to a maximum of two DSCBs for a non-ISAM data set and three for an ISAM data set. The way VSAM data sets are described in terms of DSCBs is that you start with a Format 1, it points to a Format 3, that F3 can then point to another F3, etc. up to however many F3 DSDBs are needed to hold all the extents that are allowed by some other constraint somewhere in the system software. That is the only reason why a VSAM data set is limited to 123 extents. Nine full Format 3 DSCBs can be used with a 10th Format 3 DSCB having only three of its possible 13 extent descriptor slots filled in. Somewhere else in MVS is the limit of 123 imposed. This limit came about when VSAM was invented along with making OS/360 use virtual storage. The system catalog's internal structure was redesigned at the same time to use VSAM in which to store catalog entries. So the limit of 123 extents, I believe, is related to some part of a VSAM catalog's internal structure. One DEB can have 255 different extent entries in it. They could theoretically all be on the same volume if there weren't the other constraint about 16 extents per volume for one data set. In fact they can be all on the same volume if multiple different data sets, all on one volume, are concatenated. Remember the DEB was invented in the mid-1960s also, long before VSAM came along with the new larger 123 extent limit. I don't know about the limit of 59 volumes per data set. The TIOT's constraint looks like a reasonable explanation. Bill Fairchild Franklin, TN - Original Message - From: Lon A CTR USARMY HRC Storr (US) lon.a.storr@mail.mil To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 21, 2013 1:11:58 PM Subject: Re: Extents limit for HFS (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE According to my personal notes The restriction of 127 extents per volume (device) comes from the DEB: DEBLNGTH is the number of double-words in the DEB (up to 255 === 255 * 8 = 2040; (2040 - 71) / 16 = 123). The restriction of 59 volumes (devices) per DD comes from the TIOT: TIOELNGH is the number of bytes in the TIOT entry (up to 255 === (255 - 16) / 4 = 59) Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DASDBILL2 Sent: Thursday, November 21, 2013 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS I think there was some rational explanation given several years ago. Check the archives, John. Something about how many whatevers could fit within one such-and-such, where both are control blocks within a VSAM catalog structure. I disagree with the other post that mentioned up to five different extents to satisfy the primary size. If this were true, then we wouldn't have a limit of 16 extents for a non-VSAM data set, but rather 12
smf records for updating racf profiles
Which smf records will give detail on creates/updates/deletes for racf discrete/generic profiles Thanks, Tim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VVDS delete
The DEFINE RECATALOG on the VVDS worked. No catalogs specified. On Thu, Nov 21, 2013 at 5:37 PM, Mike Schwab mike.a.sch...@gmail.com wrote: I was cleaning up VVDSs from empty volumes. I did one volume too many. The VSAM datasets are still on the volume (MOBIOUS Linear VSAM). Do I DEFINE RECATALOG the VVDS? Do I need to DEFINE RECATALOG to all the various catalogs? After getting the VVDS reset, do I need to DEFINE RECATALOG the individual datasets? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS
The 16 extents for non-vsam is obvious. The 59 volumes is a limitation of the TIOT. You have the 16 basic bytes of a TIOT entry and then 4 bytes for each UCB pointer. The TIOTLNTH field is a byte long, thus limited to 255. (Zero means end of TIOT.) 255-16=239 239/4=59 Why the 123 extent limit for VSAM? Beats me, but it is probably also related to control block structure limits Chris Blaicher Principal Software Engineer, Software Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8260 | M: 512-627-3803 E: cblaic...@syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DASDBILL2 Sent: Thursday, November 21, 2013 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS I think there was some rational explanation given several years ago. Check the archives, John. Something about how many whatevers could fit within one such-and-such, where both are control blocks within a VSAM catalog structure. I disagree with the other post that mentioned up to five different extents to satisfy the primary size. If this were true, then we wouldn't have a limit of 16 extents for a non-VSAM data set, but rather 12 (16 minus 4). Each of those five extents that might be necessary to fulfill the primary request count towards the total, whether the total is 123 or 16. And, since the primary request could also be fulfilled with only one extent, then there can still be 122 more non-primary extents in a VSAM data set. Bill Fairchild Franklin, TN - Original Message - From: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 21, 2013 11:11:46 AM Subject: Re: Extents limit for HFS Why the magic number of 123 extents per volume? 127 is more plausible. What else is going on here? On 11/21/13, John Eells ee...@us.ibm.com wrote: z/OS DFSMS Using Data Sets, topic 3.9.2.1, Creating HFS Data Sets: ... These data sets can expand to as many as 255 extents of DASD space on multiple volumes (59 volumes maximum with 123 extents per volume). John Gilmore, Ashland, MA 01721 - USA -- 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 ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Extents limit for HFS
What is current limit of extents for DSORG=PO,DSNTYPE=HFS dataset? -- 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 authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Są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.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS
Bill, You're right about the primary extent. I stand corrected My failing memory was confused. An extended format sequential dataset can also have 123 extents, can't it? Could it be that it isn't the primary allocation being able to take up to 5 extents to satisfy the request, but the 123rd extent. I just came across a note that states The last four extents are reserved for extending a data set when the last extent cannot be allocated in one piece. I also just saw a mathematical answer as to why the 123 extents in another post. So maybe the person (I believe a teacher in an IBM class eons ago) who first gave me the reason of the 'multiple physical extents to fulfill a logical extent request' may be an old tale. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DASDBILL2 Sent: Thursday, November 21, 2013 12:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS I think there was some rational explanation given several years ago. Check the archives, John. Something about how many whatevers could fit within one such-and-such, where both are control blocks within a VSAM catalog structure. I disagree with the other post that mentioned up to five different extents to satisfy the primary size. If this were true, then we wouldn't have a limit of 16 extents for a non-VSAM data set, but rather 12 (16 minus 4). Each of those five extents that might be necessary to fulfill the primary request count towards the total, whether the total is 123 or 16. And, since the primary request could also be fulfilled with only one extent, then there can still be 122 more non-primary extents in a VSAM data set. Bill Fairchild Franklin, TN - Original Message - From: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 21, 2013 11:11:46 AM Subject: Re: Extents limit for HFS Why the magic number of 123 extents per volume? 127 is more plausible. What else is going on here? On 11/21/13, John Eells ee...@us.ibm.com wrote: z/OS DFSMS Using Data Sets, topic 3.9.2.1, Creating HFS Data Sets: ... These data sets can expand to as many as 255 extents of DASD space on multiple volumes (59 volumes maximum with 123 extents per volume). John Gilmore, Ashland, MA 01721 - USA -- 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 The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
On Wed, 20 Nov 2013 20:36:15 -0500, Robert A. Rosenberg wrote: One way to handle the already APPLY'ed and now PE PTF issue is to periodically pull the HOLD Data and do an ACCEPT CHECK. That would flag/indicate a PTFs in this state. That's the hard way. It is much easier to receive current hold data and run REPORT ERRORSYSMODS against the target zone. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting a VSAM data set's system timestamp
For a non-VSAM dataset, the last reference date in the F1 DSCB does not mean the dataset was changed on that date, only that it was opened (and closed?), even if only for input. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Robin Atwood :: Sent: Thursday, November 21, 2013 4:48 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Getting a VSAM data set's system timestamp :: :: I want our file server to be able to tell the clients when a data set :: last :: changed. For non-VSAM it's easy (if a bit vague), there's the last :: reference :: date in the F1 DSCB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE According to my personal notes The restriction of 127 extents per volume (device) comes from the DEB: DEBLNGTH is the number of double-words in the DEB (up to 255 === 255 * 8 = 2040; (2040 - 71) / 16 = 123). The restriction of 59 volumes (devices) per DD comes from the TIOT: TIOELNGH is the number of bytes in the TIOT entry (up to 255 === (255 - 16) / 4 = 59) Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DASDBILL2 Sent: Thursday, November 21, 2013 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS I think there was some rational explanation given several years ago. Check the archives, John. Something about how many whatevers could fit within one such-and-such, where both are control blocks within a VSAM catalog structure. I disagree with the other post that mentioned up to five different extents to satisfy the primary size. If this were true, then we wouldn't have a limit of 16 extents for a non-VSAM data set, but rather 12 (16 minus 4). Each of those five extents that might be necessary to fulfill the primary request count towards the total, whether the total is 123 or 16. And, since the primary request could also be fulfilled with only one extent, then there can still be 122 more non-primary extents in a VSAM data set. Bill Fairchild Franklin, TN - Original Message - From: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 21, 2013 11:11:46 AM Subject: Re: Extents limit for HFS Why the magic number of 123 extents per volume? 127 is more plausible. What else is going on here? On 11/21/13, John Eells ee...@us.ibm.com wrote: z/OS DFSMS Using Data Sets, topic 3.9.2.1, Creating HFS Data Sets: ... These data sets can expand to as many as 255 extents of DASD space on multiple volumes (59 volumes maximum with 123 extents per volume). John Gilmore, Ashland, MA 01721 - USA -- 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 Classification: UNCLASSIFIED Caveats: NONE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: smf records for updating racf profiles
Tim Brown wrote: Which smf records will give detail on creates/updates/deletes for racf discrete/generic profiles Others said SMF record type 80, but there are some caveats. By default, you will see only violations. If you want to record successfull attempts too, be sure to specify audit(all(READ)) for your datasets and check out LOGOPTIONS(ALWAYS) for datasets. Also, have a look at SMF record type 60, 61, 64, 65, 17, 18, etc. That is of course that your profiles you intend to audit are not already covered by Global Access Table. Also, you may have no guarantee that Trusted STC with AC=1 will write out such records. HTH! 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
SPLITV on emulated 3290 pcomm screen
Hi This list may not be the correct one to ask this question. However I guess some of listers here may have gone through this problem. I configured IBM personal communication as 3290 - screen size 62x160. Then ISPF works fine and displays the full screen. But when I enter SPLITV from any panel to split the screen vertically, it gives me SPLITV is not active error. Has anyone done this successfully ? Thanks in advance. Regards Al -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: When should we ACCEPT DB2 PTFs?
At 07:30 -0600 on 11/21/2013, Tom Marchant wrote about Re: When should we ACCEPT DB2 PTFs?: On Wed, 20 Nov 2013 20:36:15 -0500, Robert A. Rosenberg wrote: One way to handle the already APPLY'ed and now PE PTF issue is to periodically pull the HOLD Data and do an ACCEPT CHECK. That would flag/indicate a PTFs in this state. That's the hard way. It is much easier to receive current hold data and run REPORT ERRORSYSMODS against the target zone. It has been a while since I was responsible for day to day SMP work. If as you say, REPORT ERRORSYSMODS will indicate that an APPLY'ed SYSMOD is now PE that that would look like a more efficient method than my ACCEPT CHECK one. The important thing is to find (and correct) the ticking timebomb that an APPLY'ed but now PE SYSMOD represents. No matter what method is used, the locating of PE'ed SYSMODs which were already APPLY'ed is IMO a good preventive practice. Hopefully this will not be something that occurs often and the longer you wait between the release of the SYSMODs and when you APPLY them, the more time there will be for the PE indication to occur before you do the APPLY. -- Tom Marchant -- 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: Extents limit for HFS
On Thu, Nov 21, 2013 at 11:30 AM, R.S. r.skoru...@bremultibank.com.plwrote: W dniu 2013-11-21 18:11, John Gilmore pisze: Why the magic number of 123 extents per volume? 127 is more plausible. What else is going on here? Well. Why 59 volumes per volume, why 140 bytes per VTOC records? Why DSN is limited to 44 characters? Why IDE HDD limit was stupidly increased from ~500MB to 8.4GB? Why PC XT was limited to 640kB RAM (ok, it could be 1MB)? Why... (time for my pills) Like the Bursar of the Unseen University, Ankh-Morpork, Diskworld's dried frog pills? ref: http://wiki.lspace.org/mediawiki/index.php/Dried_frog_pills -- 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: VVDS delete
Did you originally delete the VVDS or just uncatalog it (delete noscratch)? If you did not specify a catalog, the VVDS was probably recatalogued in the master catalog. Do you know for a fact that this is the same place it was catalogued before the mistake? (It may matter because VVDSs and catalogs point back and forth to each other.) Do you periodically run Access Methods Services DIAGNOSE commands against your catalogs and VVDSs? If not, it might pay to do both for this VVDS/catalog just to insure everything is still consistent. (Running the EXAMINE command against the catalog might also be reassuring.) :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Mike Schwab :: Sent: Thursday, November 21, 2013 4:18 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: VVDS delete :: :: The DEFINE RECATALOG on the VVDS worked. No catalogs specified. :: :: On Thu, Nov 21, 2013 at 5:37 PM, Mike Schwab mike.a.sch...@gmail.com :: wrote: :: I was cleaning up VVDSs from empty volumes. I did one volume too :: many. The VSAM datasets are still on the volume (MOBIOUS Linear :: VSAM). :: :: Do I DEFINE RECATALOG the VVDS? :: Do I need to DEFINE RECATALOG to all the various catalogs? :: After getting the VVDS reset, do I need to DEFINE RECATALOG the :: individual datasets? :: :: :: -- :: Mike A Schwab, Springfield IL USA :: Where do Forest Rangers go to get away from it all? :: :: :: :: -- :: Mike A Schwab, Springfield IL USA :: Where do Forest Rangers go to get away from it all? :: :: -- :: For IBM-MAIN subscribe / signoff / archive access instructions, :: send email to lists...@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: smf records for updating racf profiles
W dniu 2013-11-21 14:47, Tim Brown pisze: Which smf records will give detail on creates/updates/deletes for racf discrete/generic profiles SMF80 -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS
HFS limits and requirements changed over the time. It seems description below is not up to date since I'm just watching 3270 window and 146 extents is reported by ISPF for the HFS file. What I missed first time (or it wasn't present on the screen?) is + sign right t volume name. Yes, it is 2-volume, SMS-managed HFS. DSORG=PO can be multi-volume ;-) AFAIK it can have up to 255 extents. AFAIK2 only SMS-managed HFSes can be multi-vol. My question was caused because I believed it's single-vol dataset. Regards -- Radoslaw Skorupka Lodz, Poland W dniu 2013-11-21 14:18, Neil Haley pisze: This is from ABCs of z/OS System Programming: Volume 9 (http://www.redbooks.ibm.com/abstracts/sg246989.html) HFS data sets A z/OS UNIX hierarchical file system is contained in a data set type called HFS. An HFS data set can reside on an SMS-managed volume or a non SMS-managed volume. HFS data sets can reside with other z/OS data sets on SMS-managed volumes and non SMS-managed volumes. Multiple systems can share an HFS data set if it is mounted in read-only mode. An HFS data set can have up to 123 extents, and the maximum size of the data set is one physical volume. For a 3390-Model 3, the maximum size is 2.838 GB. HFS data sets only be accessed by z/OS UNIX. Regards, Neil Haley nha...@ca.ibm.com Storage Software Mainframe Support http://www.ibm.com/systems/z/ | http://www.about.me/NeilHaley Office: 1-613-748-2857 | Pager: 1-613-780-3345 | Mobile: 1-613-266-4565 From: R.S. r.skoru...@bremultibank.com.pl To: IBM-MAIN@listserv.ua.edu, Date: 11/21/2013 08:13 Subject:Extents limit for HFS Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu What is current limit of extents for DSORG=PO,DSNTYPE=HFS dataset? -- 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 authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Są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.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- 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 -- 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 authorised to forward it to
SMF Type 64 - SMF64RIN - Bit 01 on?
I am very occasionally seeing (I think - many layers in play here) SMF Type 64 records with Bit 7 (x'01') on in SMF64RIN, the Situation Indicator. The bit is documented as Reserved. Anyone have any idea what it means? Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: smf records for updating racf profiles
On Thu, 21 Nov 2013 08:32:32 -0600, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Tim Brown wrote: Which smf records will give detail on creates/updates/deletes for racf discrete/generic profiles Others said SMF record type 80, but there are some caveats. By default, you will see only violations. If you want to record successfull attempts too, be sure to specify audit(all(READ)) for your datasets and check out LOGOPTIONS(ALWAYS) for datasets. Not quite right, Elardus, if he asked the right question. He asked about creating/updating/deleting *profiles*, not resources. The audit controls for actions against profiles (e.g., via RACF commands) are SETROPTS AUDIT(classname) and SETROPTS SAUDIT. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Type 64 - SMF64RIN - Bit 01 on?
Barry, you're the best! Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barry Merrill Sent: Thursday, November 21, 2013 10:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SMF Type 64 - SMF64RIN - Bit 01 on? Change 20.212 Support for APAR OW56162 for SMF type 64 new VSAM EOV SMF VMAC64 that is written when there is a record management catalog Oct 3, 2002 update request. Variable SITUIND='CATALOG UPDATE' is set from SMF64RIN bit 7 for this new event; this record will not contain any extent information. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, November 21, 2013 12:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF Type 64 - SMF64RIN - Bit 01 on? I am very occasionally seeing (I think - many layers in play here) SMF Type 64 records with Bit 7 (x'01') on in SMF64RIN, the Situation Indicator. The bit is documented as Reserved. Anyone have any idea what it means? Thanks, Charles -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS
This is from ABCs of z/OS System Programming: Volume 9 (http://www.redbooks.ibm.com/abstracts/sg246989.html) HFS data sets A z/OS UNIX hierarchical file system is contained in a data set type called HFS. An HFS data set can reside on an SMS-managed volume or a non SMS-managed volume. HFS data sets can reside with other z/OS data sets on SMS-managed volumes and non SMS-managed volumes. Multiple systems can share an HFS data set if it is mounted in read-only mode. An HFS data set can have up to 123 extents, and the maximum size of the data set is one physical volume. For a 3390-Model 3, the maximum size is 2.838 GB. HFS data sets only be accessed by z/OS UNIX. Regards, Neil Haley nha...@ca.ibm.com Storage Software Mainframe Support http://www.ibm.com/systems/z/ | http://www.about.me/NeilHaley Office: 1-613-748-2857 | Pager: 1-613-780-3345 | Mobile: 1-613-266-4565 From: R.S. r.skoru...@bremultibank.com.pl To: IBM-MAIN@listserv.ua.edu, Date: 11/21/2013 08:13 Subject:Extents limit for HFS Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu What is current limit of extents for DSORG=PO,DSNTYPE=HFS dataset? -- 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 authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Są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.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- 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: Extents limit for HFS (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE I meant The restriction of 123 extents per volume -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Storr, Lon A CTR USARMY HRC (US) Sent: Thursday, November 21, 2013 2:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: NONE According to my personal notes The restriction of 127 extents per volume (device) comes from the DEB: DEBLNGTH is the number of double-words in the DEB (up to 255 === 255 * 8 = 2040; (2040 - 71) / 16 = 123). The restriction of 59 volumes (devices) per DD comes from the TIOT: TIOELNGH is the number of bytes in the TIOT entry (up to 255 === (255 - 16) / 4 = 59) Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DASDBILL2 Sent: Thursday, November 21, 2013 1:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Extents limit for HFS I think there was some rational explanation given several years ago. Check the archives, John. Something about how many whatevers could fit within one such-and-such, where both are control blocks within a VSAM catalog structure. I disagree with the other post that mentioned up to five different extents to satisfy the primary size. If this were true, then we wouldn't have a limit of 16 extents for a non-VSAM data set, but rather 12 (16 minus 4). Each of those five extents that might be necessary to fulfill the primary request count towards the total, whether the total is 123 or 16. And, since the primary request could also be fulfilled with only one extent, then there can still be 122 more non-primary extents in a VSAM data set. Bill Fairchild Franklin, TN - Original Message - From: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, November 21, 2013 11:11:46 AM Subject: Re: Extents limit for HFS Why the magic number of 123 extents per volume? 127 is more plausible. What else is going on here? On 11/21/13, John Eells ee...@us.ibm.com wrote: z/OS DFSMS Using Data Sets, topic 3.9.2.1, Creating HFS Data Sets: ... These data sets can expand to as many as 255 extents of DASD space on multiple volumes (59 volumes maximum with 123 extents per volume). John Gilmore, Ashland, MA 01721 - USA -- 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 Classification: UNCLASSIFIED Caveats: NONE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Classification: UNCLASSIFIED Caveats: NONE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Getting a VSAM data set's system timestamp
I want our file server to be able to tell the clients when a data set last changed. For non-VSAM it's easy (if a bit vague), there's the last reference date in the F1 DSCB. For VSAM you can see a SYSTEM-TIMESTAMP in the LISTCAT output but how do you get that from a program? We currently use IGGCSI00 for VSAM info but there is no field name for the timestamp. The SHOWCAT macro does not seem to show all that much at all. Any ideas out there? I am hoping I have missed something. TIA Robin -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VVDS delete
Retired mainframer and I have had our differences, some of them acrimonious; but this is very good advice. DIAGNOSE and EXAMINE are for routine, periodic, anticipatory use. Don't wait to use them until you are in deep trouble. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VVDS delete
Diagnose and examine are run regularly. The VVDS was still on the volume. Migrating the datasets on the volume worked after the DEFINE RECATALOG. On Thu, Nov 21, 2013 at 7:29 PM, retired mainframer retired-mainfra...@q.com wrote: Did you originally delete the VVDS or just uncatalog it (delete noscratch)? If you did not specify a catalog, the VVDS was probably recatalogued in the master catalog. Do you know for a fact that this is the same place it was catalogued before the mistake? (It may matter because VVDSs and catalogs point back and forth to each other.) Do you periodically run Access Methods Services DIAGNOSE commands against your catalogs and VVDSs? If not, it might pay to do both for this VVDS/catalog just to insure everything is still consistent. (Running the EXAMINE command against the catalog might also be reassuring.) :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Mike Schwab :: Sent: Thursday, November 21, 2013 4:18 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: VVDS delete :: :: The DEFINE RECATALOG on the VVDS worked. No catalogs specified. :: :: On Thu, Nov 21, 2013 at 5:37 PM, Mike Schwab mike.a.sch...@gmail.com :: wrote: :: I was cleaning up VVDSs from empty volumes. I did one volume too :: many. The VSAM datasets are still on the volume (MOBIOUS Linear :: VSAM). :: :: Do I DEFINE RECATALOG the VVDS? :: Do I need to DEFINE RECATALOG to all the various catalogs? :: After getting the VVDS reset, do I need to DEFINE RECATALOG the :: individual datasets? :: :: :: -- :: Mike A Schwab, Springfield IL USA :: Where do Forest Rangers go to get away from it all? :: :: :: :: -- :: Mike A Schwab, Springfield IL USA :: Where do Forest Rangers go to get away from it all? :: :: -- :: For IBM-MAIN subscribe / signoff / archive access instructions, :: send email to lists...@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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS
On Thu, 21 Nov 2013 12:11:46 -0500, John Gilmore wrote: Why the magic number of 123 extents per volume? 127 is more plausible. What else is going on here? Isn't this somewhat akin to my ranting in the past about why the maximum BLKSIZE is 32760 when 32767 is more plausible? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SPLITV on emulated 3290 pcomm screen
In 002501cee703$bbc1ee10$3345ca30$@optusnet.com.au, on 11/22/2013 at 08:50 AM, Al Chu al_chu...@optusnet.com.au said: This list may not be the correct one to ask this question. Is there a list specific to the 3270 simulator that you're using? I configured IBM personal communication as 3290 Apparently not. screen size 62x160. There's more to a 3290 than the screen size. You need support for, e.g., explicit partitions. You also need a logmode that supports Read Partition - Query. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: smf records for updating racf profiles
SMF type 80, cleverly hidden in the RACF Macros and Interfaces manual. :-) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tim Brown Sent: Thursday, November 21, 2013 7:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: smf records for updating racf profiles Which smf records will give detail on creates/updates/deletes for racf discrete/generic profiles Thanks, Tim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: smf records for updating racf profiles
Rex, Your 'hidden' description triggered me: a few years ago I was looking for an SMF record from a product (somewhere in the 90 range, I don't know exactly which anymore). I found nothing in the SMF manual and after consulting IBM, it appeared to be described in the product manuals. I argued that each SMF record should be anchored in *the* SMF manual, at least with a pointer to the real manual. IBM agreed and added a chapter in the SMF manual with a link to the correct manual. The SMF 80 also appears to be nicely documented in the SMF manual with a pointer to the appropriate manual, so it is not hidden from people who try, using common sense, to find this SMF information in the SMF manual. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Thursday, November 21, 2013 15:04 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: smf records for updating racf profiles SMF type 80, cleverly hidden in the RACF Macros and Interfaces manual. :-) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tim Brown Sent: Thursday, November 21, 2013 7:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: smf records for updating racf profiles Which smf records will give detail on creates/updates/deletes for racf discrete/generic profiles Thanks, Tim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Extents limit for HFS
W dniu 2013-11-21 18:11, John Gilmore pisze: Why the magic number of 123 extents per volume? 127 is more plausible. What else is going on here? Well. Why 59 volumes per volume, why 140 bytes per VTOC records? Why DSN is limited to 44 characters? Why IDE HDD limit was stupidly increased from ~500MB to 8.4GB? Why PC XT was limited to 640kB RAM (ok, it could be 1MB)? Why... (time for my pills) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SPLITV on emulated 3290 pcomm screen
Hi Thanks for the explanation. I thought I was emulating 3290 by specifying 62x160. I can now stop wasting my time. Thanks again. Regards A1 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike Sent: Friday, 22 November 2013 9:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SPLITV on emulated 3290 pcomm screen I don't have 3290 as an option when configuring PCOMM. It allows 62X160 but this is for 3270 not 3290. I don't believe PCOMM emulates a 3290. On Fri, Nov 22, 2013 at 8:50 AM, Al Chu al_chu...@optusnet.com.au wrote: Hi This list may not be the correct one to ask this question. However I guess some of listers here may have gone through this problem. I configured IBM personal communication as 3290 - screen size 62x160. Then ISPF works fine and displays the full screen. But when I enter SPLITV from any panel to split the screen vertically, it gives me SPLITV is not active error. Has anyone done this successfully ? Thanks in advance. Regards Al -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wayne V. Bickerdike -- 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: When should we ACCEPT DB2 PTFs?
Cavet: I Know very little about DB2 However the let me say this about SMPE. The author did not go into detail about how their USERMOD's are designed. When I do a usermod it is for a stated level of a mod ie ++pre (). If I go to apply and find out there is conflict I just restore the usermod. I then apply as normal and after the the last PTF is applied I then go in and redo the usermod (with the correct pre's). Having said this I was quite surprised to hear that anyone one would have 20+ usermod's on DB2. When I do anything mass to a system I expect to have to rewrite 20+ usermods and would not find this abnormal. I just can't believe that DB2 was so messed up that it would require that many usermods. Maybe someone can speak up and say whether a typical DB2 site has that many usermods. Ed On Nov 19, 2013, at 9:47 PM, Robert A. Rosenberg wrote: At 03:11 -0600 on 11/19/2013, Alex wrote about When should we ACCEPT DB2 PTFs?: As you know, each DB2 RSU PTF package contains hundreds of PTFs. When we apply those PTFs, we may need to restore some USERMOD and related PTFs first and then proceed with applying task. If your problem is that to restore the USERMOD you must also restore PTFs, there is a solution that may work. If the USERMOD must be restored along with PTFs, you are going to need to rework it to have newer PREs to the new set of PTFs. Why not just create a new USERMOD that SUPs the old one and reapplies its contents. Since the USERMOD is going against a member that being replaced by a the new PTFs there would otherwise be no need to do the RESTORE to override the fact that the USERMOD is not listed as a PRE/SUP in the new PTF. Another solution is to just use UCLIN to delete the USERMOD entry on the module and then APPLY the USERMOD with the updated PRE info. -- 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: Questions about ESTAE(X)
mvsmain From: Kenneth Wilkerson Date: 2013-08-28 22:49 To: IBM-MAIN Subject: Re: Questions about ESTAE(X) I rarely use TERM=YES. I use RTM exits almost exclusively for error reporting and setting a retry. About the only time TERM=YES is used is in the primary driver task for a cross memory server so that its RTM exit can reset the PC services available flag to minimize D6 abends. But I don't even rely on that. I just code the calling interfaces to treat and report D6 abends as unexpected server terminations. I rely on the RTM to cleanup address space and task level resources. The real issue is common resources that are shared system wide or between 2 or more address spaces. For this, I prefer resource managers, particularly address space resource managers. And I know its authorized and probably only necessary for cross memory servers which by definition must be authorized. This may seem off topic but the topic is about cleaning up after a termination event (TERM=YES) such as a CANCEL. Address space resource managers are guaranteed to execute, even if an address space is forced. Consider an address space that has terminated because it has exhausted its memory. If you have anything but the simplest tasks to perform, there may not be storage to do cleanup. My experience is that in serious error conditions, the RTM exit may not be the best way to cleanup common resources. The only advice I have is that if you define an address space resource manager, be sure you have a timer exit to time it out should it go in a loop. This probably will never get used but a loop in an address space resource manager, which runs in the master address space is a non-trivial problem. Do with this information as you wish. But if you are considering TERM=YES for anything but the simplest resource cleanup, consider a resource manager. I rarely use TERM=YES. I prefer resource managers. And I only use resource managers to cleanup common resources. Most of the stuff I write uses neither. Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Wednesday, August 28, 2013 8:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Questions about ESTAE(X) A recovery routine cannot change SDWACLUP (or most of the fields in the SDWA) and have such a change be useful to anything. If you are intended to change it, usually SETRP will let you do so, or it's a field relevant to retry or it's one of the communication fields. SDWACLUP is on not only for TERM=YES but also for all other retryable abends. if I don't issue any ESTAE(X), then *something* gets control on normal ABENDs That's called RTM, regardless of the type of abend. Am I correct that you apparently can't issue an ABEND macro (effectively) in a recovery routine? I would so no but it depends what you mean by effectively. Once termination begins (think cancel) an ESTAE(X) without TERM=YES will not get control, but an ESTAE(X) with TERM=YES will. I think that applies to nested recovery too (a nested recovery routine is a recovery routine set within the ESTAE(X) routine itself). For TERM=YES, normal rules of nested recovery, percolation, and even retry apply (a nested recovery routine can retry back to the recovery routine that created it; it cannot retry back to the mainline). if an ESTAE(X) TERM=YES is chained after an ESTAE(X) TERM=NO, is there any way to get the chained recovery routine to percolate a TERM=YES-type ABEND? I must not be understanding. The chained recovery routine in the sentence above appears to be the TERM=YES routine. It can of course percolate a TERM=YES-type ABEND (in fact it has no choice but to percolate). But when it percolates, the TERM=NO routine will not get control, specifically because it is TERM=NO and this was a TERM=YES-type ABEND. So overall, I really don't know what is confusing. The basic point is if you have nothing to clean up if the job is going to terminate due to the error, then you usually do not need TERM=YES. For example, if you might ordinarily freemain something, but if the system will do so upon job termination (as it will, in effect, do for region subpools) then you might choose not to worry about getting control in recovery for that termination case to do the freemain. Peter Relson z/OS Core Technology Design -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting a VSAM data set's system timestamp
So both you and Lizette are saying that even I can obtain it, the available timestamp is not very useful. We need to synchronise the mainframe data set with its workstation copy and currently use hashes of each file to see if they are different. This is CPU intensive and I had hoped to avoid it by comparing the last write dates. It looks like my scheme won't work in this case (it works fine for libraries of members like PDSs and Endevor). Hmm. Thanks Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of retired mainframer Sent: 22 November 2013 00:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Getting a VSAM data set's system timestamp For a non-VSAM dataset, the last reference date in the F1 DSCB does not mean the dataset was changed on that date, only that it was opened (and closed?), even if only for input. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Robin Atwood :: Sent: Thursday, November 21, 2013 4:48 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Getting a VSAM data set's system timestamp :: :: I want our file server to be able to tell the clients when a data set :: last :: changed. For non-VSAM it's easy (if a bit vague), there's the last :: reference :: date in the F1 DSCB. -- 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: SMF Type 64 - SMF64RIN - Bit 01 on?
Change 20.212 Support for APAR OW56162 for SMF type 64 new VSAM EOV SMF VMAC64 that is written when there is a record management catalog Oct 3, 2002 update request. Variable SITUIND='CATALOG UPDATE' is set from SMF64RIN bit 7 for this new event; this record will not contain any extent information. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, November 21, 2013 12:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SMF Type 64 - SMF64RIN - Bit 01 on? I am very occasionally seeing (I think - many layers in play here) SMF Type 64 records with Bit 7 (x'01') on in SMF64RIN, the Situation Indicator. The bit is documented as Reserved. Anyone have any idea what it means? Thanks, Charles -- 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
