Re: multi-volume SMS file allocation
Greg Shirey wrote: It's actually VOLUME COUNT in the DATACLAS definition. From the (1.12) HELP panel: Use the VOLUME COUNT field to specify the maximum number of volumes you expect to use to store a data set in this Data Class. For example, to reserve five volumes per data set, specify: Volume Count . . . . . . 5 (1 to 255 or blank) Very well ... it still doesn't behave like what was said on this thread (that unused primary extents would not be allocated at all). One primary extent for each volume in the volume count is allocated at allocation time (before ever writing the file). Then, at close time, RLSE will purge unused space on the last USED extent (the one active at close time) but not on possible further (unused) extents. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PassTicket usage logical flaw?
For this case, there is a "NO REPLAY PROTECTION" option availabel. Check the APPLDATA field of your PTKTDATA profile. See chapter 7, Secured Signon Function of RACF Security Administrators Guide for details. Cheers Michael Von:Charles Mills An: IBM-MAIN@LISTSERV.UA.EDU Datum: 2012-11-12 20:21 Betreff:PassTicket usage logical flaw? Gesendet von: IBM Mainframe Discussion List 1. A given PassTicket may only be used once (source http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom . ibm.cics.ts31.doc%2Fdfht5%2Ftopics%2Fdfht516.htm) 2. The PassTicket algorithm is deterministic: given the same time of day (resolution one second), the same userid, the same application ID, and the same secured signon application key, the algorithm will always produce the same PassTicket (experimentation reveals this to be true). Consider a distributed application. Some large number of automated clients sign on to some service at quasi-random intervals. A perfect application for PassTickets, right? But if a second client tries to log on within the same TOD second as an earlier client, the sign-on will be rejected because the generated PassTicket has already been used. What is the client to do? The obvious answer is "wait a second and try again" but that approach has some obvious shortcomings, one of which being there is no guarantee that THAT PassTicket has not already been used. Yes, one solution would be a unique userid for each client, but suppose this is some "mass image rollout" application or there is some other reason why unique userids are not desirable. What to do? 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
Re: multi-volume SMS file allocation
I did not read the entire thread, so my remark may be totally inapplicable, but what you describe (all extents on all volumes are created at allocation time) applies only if you specify Guaranteed Space? Then this is exactly what Guaranteed Space is intended for. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DEBERT Jean-Louis Sent: Tuesday, November 13, 2012 10:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: multi-volume SMS file allocation Greg Shirey wrote: It's actually VOLUME COUNT in the DATACLAS definition. From the (1.12) HELP panel: Use the VOLUME COUNT field to specify the maximum number of volumes you expect to use to store a data set in this Data Class. For example, to reserve five volumes per data set, specify: Volume Count . . . . . . 5 (1 to 255 or blank) Very well ... it still doesn't behave like what was said on this thread (that unused primary extents would not be allocated at all). One primary extent for each volume in the volume count is allocated at allocation time (before ever writing the file). Then, at close time, RLSE will purge unused space on the last USED extent (the one active at close time) but not on possible further (unused) extents. -- 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: multi-volume SMS file allocation
Vernooij, CP - SPLXM wrote: I did not read the entire thread, so my remark may be totally inapplicable, but what you describe (all extents on all volumes are created at allocation time) applies only if you specify Guaranteed Space? Then this is exactly what Guaranteed Space is intended for. You may be right. But if use a storage class with Guaranteed Space = NO, only the 1st volume extent is ever allocated, and I get abend D37 when it fills up, even if I use a DATACLAS with Dynamic Volume Count = 5 and Space Constraint Relief = YES. Go figure ... How can I have extents (apart from the first) be allocated only when they are actually used, and preferably on different volumes ? This was the original question in the thread. Thanks for your input anyway. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Highly used Coupling Facility blocks Sysplex
We had an outage cause by an overloaded Coupling Facility. It’s in a parallel sysplex with eight Images and z/OS 1.13 RSU1206 and DB2 10. All images are on Z196, also the CF, with CFCC 17. What happened is that a DB2 CF structure (a group buffer pool) was flooded by applications doing tablespace scan. A lot of directory reclaims occurred. The CF was not able to handle this high number of GBP requests which resulted in increased CPU activity for this structure. The CPU Utilization of the CF got up to 75%. The application has requested more and more GBP entries which slowed down the whole sysplex. Also applications using other structures in the CF had been nearly blocked. Did some experience similar problems with overloaded CF’s ? Brgds Markus Haselbach -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-volume SMS file allocation
Sounds like a straight forward problem. I will read the thread today or tomorrow. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DEBERT Jean-Louis Sent: Tuesday, November 13, 2012 11:55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: multi-volume SMS file allocation Vernooij, CP - SPLXM wrote: I did not read the entire thread, so my remark may be totally inapplicable, but what you describe (all extents on all volumes are created at allocation time) applies only if you specify Guaranteed Space? Then this is exactly what Guaranteed Space is intended for. You may be right. But if use a storage class with Guaranteed Space = NO, only the 1st volume extent is ever allocated, and I get abend D37 when it fills up, even if I use a DATACLAS with Dynamic Volume Count = 5 and Space Constraint Relief = YES. Go figure ... How can I have extents (apart from the first) be allocated only when they are actually used, and preferably on different volumes ? This was the original question in the thread. Thanks for your input anyway. -- 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: Highly used Coupling Facility blocks Sysplex
Curious if this was a single processor CF? We have never had an outage due to a CF even though we have had one fail and structures rebuild into another. I have seen performance "opportunities" that were solved by operating our production data sharing CF's as 2 processor rather than 1 too improve parallel operations with DB2. We made this change circa z9 hardware and subsequently even though engines have continued to get faster will not operate a production CF with less 1 ICF engine. Best Regards, Sam Knutson, GEICO System z Team Leader mailto:sknut...@geico.com (office) 301.986.3574 (cell) 301.996.1318 "Think big, act bold, start simple, grow fast..." -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Markus Haselbach Sent: Tuesday, November 13, 2012 6:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Highly used Coupling Facility blocks Sysplex We had an outage cause by an overloaded Coupling Facility. It’s in a parallel sysplex with eight Images and z/OS 1.13 RSU1206 and DB2 10. All images are on Z196, also the CF, with CFCC 17. What happened is that a DB2 CF structure (a group buffer pool) was flooded by applications doing tablespace scan. A lot of directory reclaims occurred. The CF was not able to handle this high number of GBP requests which resulted in increased CPU activity for this structure. The CPU Utilization of the CF got up to 75%. The application has requested more and more GBP entries which slowed down the whole sysplex. Also applications using other structures in the CF had been nearly blocked. Did some experience similar problems with overloaded CF’s ? Brgds Markus Haselbach This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Beyond RAID: IBM adds big data friendly, affordable servers to line up
z not mentioned in article. Article is basically how this now "ports" this type of storage to the small enterprise "x" server environment. As opposed to being "embedded" into large enterprise storage DASD arrays. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets® 9151 Boulevard 26 • N. Richland Hills • TX 76010 (817) 255-3225 phone • john.mck...@healthmarkets.com • www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Paul Gilmartin > Sent: Monday, November 12, 2012 11:27 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Beyond RAID: IBM adds big data friendly, affordable > servers to line up > > On Mon, 12 Nov 2012 22:56:32 -0600, Ed Gould wrote: > > > > http://www.zdnet.com/beyond-raid-ibm-adds-big-data-friendly- > affordable-servers-to-line-up-707218/ > >[ URL wrap repaired -- gil ] > > > So, of course, the topical question: Does z/OS support it? Is its > interface CKD? FBA? Other (specify)? > > -- gil > > -- > 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: multi-volume SMS file allocation
Another approach: instead of working with multi volume extents of 1 dataset, why not allocate as many single volume datasets as needed? Kees. -Original Message- From: Vernooij, CP - SPLXM Sent: Tuesday, November 13, 2012 13:39 To: IBM Mainframe Discussion List Subject: RE: multi-volume SMS file allocation Sounds like a straight forward problem. I will read the thread today or tomorrow. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of DEBERT Jean-Louis Sent: Tuesday, November 13, 2012 11:55 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: multi-volume SMS file allocation Vernooij, CP - SPLXM wrote: I did not read the entire thread, so my remark may be totally inapplicable, but what you describe (all extents on all volumes are created at allocation time) applies only if you specify Guaranteed Space? Then this is exactly what Guaranteed Space is intended for. You may be right. But if use a storage class with Guaranteed Space = NO, only the 1st volume extent is ever allocated, and I get abend D37 when it fills up, even if I use a DATACLAS with Dynamic Volume Count = 5 and Space Constraint Relief = YES. Go figure ... How can I have extents (apart from the first) be allocated only when they are actually used, and preferably on different volumes ? This was the original question in the thread. Thanks for your input anyway. -- 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: multi-volume SMS file allocation
Vernooij, CP - SPLXM wrote: Another approach: instead of working with multi volume extents of 1 dataset, why not allocate as many single volume datasets as needed? Thanks for the idea, but no ... I am working on an existing application, where the single-dataset property is important (because the DSN has to be stored somewhere) and where the multi-volume property is seen as one way to overcome the 65,535 tracks limit (that is, allowing a bigger file) when reading the file with BSAM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highly used Coupling Facility blocks Sysplex
Hello, in our production sysplex (where the issue took place) we have two CF's each with five dedicted processors. best regards Markus Haselbach -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PassTicket usage logical flaw?
I have no view of the usefulness of physical RNGs for game playing, dance-move generation, and the like. They are, however, all but useless in programs, where they have a long, highly problematic usage history. IBM's first models of the circa-1958 SAGE version of MIT's Whirlwind computer were equipped with shot-noise-based physical RNGs, but they were discarded early on. The sequence of values generated by a physical RNG is not reproducible, and programs that use one are for this reason all but impossible to test and debug. Note also that the acronym PRNG, in wide use in the gaming community, is better avoided. Its initial P is ambiguous, can be interpreted as standing for either 'physical' or 'pseudo-'; one of my very young students even guessed that it stood for 'programmed'. 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
"New" way to do UCB lookups
Hi Folks, Please refer to yesterday's post with this title. I made a small mistake in determining the end of the ULUT (UCB Lookup Table) entries. This was fixed this morning. Anyone who downloaded Files 731, 046, and 035 yesterday, from the Updates page of www.cbttape.org, should reload them today. Sorry. We live and learn. The mistake was not too serious, but I don't want anyone to learn the wrong way of doing things. All the best of everything to all of you. Sincerely,Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DS8300 HMC WEBUI logon is forced closed
Greetings, I am trying to remotely connect to my DS8300 using the WEBUI and IE 9.0 and my session is being forced closed after 20 seconds. The message being displayed is: Your session, logged on as user customer, was forcibly disconnected on Nov 12, 2012 at 8:33:21 AM for the reason shown below: Connectivity to the console failed. Contact your support personnel to determine if your browser is configured properly to connect to the console. It's frustrating because I can remotely connect to my DS8100 but not my newly installed but used DS8300 (2424/932). My question to the List is: To whom do I direct my problem to when I open an PMR? I can't find a reference to the DS8300 HMC software. I tried opening a Hardware Request but I was told that they could not help me and referred me back to my CE. I would like to open a Service Request but don't know who to direct the problem/question to. Thank you for your patience. Wayne Schroeder MAINFRAME STORAGE ADMINISTRATOR T 254.399.5070 M 254.644.8534 E wschroe...@txfb-ins.com 7420 Fish Pond Rd. Waco, TX 76710 WWW.TXFB-INS.COM CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in error, do not read it. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PassTicket usage logical flaw?
Aha! Thanks. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of michael.klaesc...@deutscherring-leben.de Sent: Tuesday, November 13, 2012 1:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PassTicket usage logical flaw? For this case, there is a "NO REPLAY PROTECTION" option availabel. Check the APPLDATA field of your PTKTDATA profile. See chapter 7, Secured Signon Function of RACF Security Administrators Guide for details. Cheers Michael Von:Charles Mills An: IBM-MAIN@LISTSERV.UA.EDU Datum: 2012-11-12 20:21 Betreff:PassTicket usage logical flaw? Gesendet von: IBM Mainframe Discussion List 1. A given PassTicket may only be used once (source http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom . ibm.cics.ts31.doc%2Fdfht5%2Ftopics%2Fdfht516.htm) 2. The PassTicket algorithm is deterministic: given the same time of day (resolution one second), the same userid, the same application ID, and the same secured signon application key, the algorithm will always produce the same PassTicket (experimentation reveals this to be true). Consider a distributed application. Some large number of automated clients sign on to some service at quasi-random intervals. A perfect application for PassTickets, right? But if a second client tries to log on within the same TOD second as an earlier client, the sign-on will be rejected because the generated PassTicket has already been used. What is the client to do? The obvious answer is "wait a second and try again" but that approach has some obvious shortcomings, one of which being there is no guarantee that THAT PassTicket has not already been used. Yes, one solution would be a unique userid for each client, but suppose this is some "mass image rollout" application or there is some other reason why unique userids are not desirable. What to do? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DS8300 HMC WEBUI logon is forced closed
Hello, I went through this a few weeks ago myself. Problem appears to have come in with HMC V7R3.4.0. A lot of faffing about trawling through ibm & some google's before i got to the answer which is down to the port firewall settings on the Ds8300 lan adaptor panel. Ports in question are 443, 8443 and 9960. Have a look at the Hardware Management console V7 Redbook which should give you some useful input. I believe the specific port with the problem is 9960, but you do need all three firewall configured. We don't have direct hmc access to the lan firewall settings on our boxes (only have the customer id) so had to raise calls with ibm for them to dial in and correct. Each affected DS8xxx H.M.C needs to be rebooted after. Once they did that, the problem's gone. Good Luck! Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DS8300 HMC WEBUI logon is forced closed
Thank you Dave, I knew somebody had seen this problem before! Wayne Schroeder MAINFRAME STORAGE ADMINISTRATOR T 254.399.5070 M 254.644.8534 E wschroe...@txfb-ins.com 7420 Fish Pond Rd. Waco, TX 76710 WWW.TXFB-INS.COM CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in error, do not read it. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you.-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Devine Sent: Tuesday, November 13, 2012 9:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DS8300 HMC WEBUI logon is forced closed Hello, I went through this a few weeks ago myself. Problem appears to have come in with HMC V7R3.4.0. A lot of faffing about trawling through ibm & some google's before i got to the answer which is down to the port firewall settings on the Ds8300 lan adaptor panel. Ports in question are 443, 8443 and 9960. Have a look at the Hardware Management console V7 Redbook which should give you some useful input. I believe the specific port with the problem is 9960, but you do need all three firewall configured. We don't have direct hmc access to the lan firewall settings on our boxes (only have the customer id) so had to raise calls with ibm for them to dial in and correct. Each affected DS8xxx H.M.C needs to be rebooted after. Once they did that, the problem's gone. Good Luck! Dave -- 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
HFS zFS and IDCAMS Alias
With HFS you could run IDCAMS with RELATE to create an alias. With zFS being a linear VSAM dataset that does not work. I understand that indirect volume cataloging with SYMBOLICRELATE is available at z/OS V1.12 and above (which we are at) So is there a way to create an alias with zFS or is the indirect catalog the only path. Thanks Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: switching to new shared sms commds
Hello, I appreciate the advice from folks who responded but my question remains unanswered. Will there be any problems (on the other lpars) if I do the setsms commds to point to a new commds for the first lpar? Thank you. -- Date:Wed, 7 Nov 2012 08:23:04 + From:Richard Marchant mailto:richard.march...@shoden.co.za>> Subject: Re: switching to new shared sms commds Dennis, Make sure you allocate a new COMMDS do not try using an existing one. Richard Hello, I want to switch to new sms commds on current environment that has same commds shared by 3 lpars. I come from an older sms environment where each lpar had their own set of cds's so this is different. Will there be any problems (on the other lpars) if I do the setsms commds to point to a new commds for the first lpar? I believe I will need to issue the same setsms on all lpars to point to new commds. We are z/os 1.13. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HFS zFS and IDCAMS Alias
Sure, I've done it with other types of VSAM files. It just _seems_ weird. Make
a PATH:
DEF PATH(NAME('alias.name') -
PATHENTRY('real.name'))
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets®
9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john.mck...@healthmarkets.com • www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets® is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA
Life and Health Insurance Company.SM
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lizette Koehler
> Sent: Tuesday, November 13, 2012 10:36 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: HFS zFS and IDCAMS Alias
>
> With HFS you could run IDCAMS with RELATE to create an alias.
>
> With zFS being a linear VSAM dataset that does not work. I understand
> that indirect volume cataloging with SYMBOLICRELATE is available at
> z/OS V1.12 and above (which we are at)
>
> So is there a way to create an alias with zFS or is the indirect
> catalog the only path.
>
> Thanks
>
> Lizette
>
> --
> 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
"New" way to do UCB lookups
Hi Folks, Alex Brodsky was kind enough to point out to me that the ULUT has to be serialized, and he referred me to the SETLOCK macro, which talks about this. However, it seems to me that serialization is necessary only if you want to change something in the ULUT, and not if you just want to look up real UCB addresses without having to be authorized. In other words, my programs UCBDASD (CBT File 731), which just displays online DASD UCB's, and the other program PACKRATU (CBT File 046), whose BACKENDU module only has to find the UCB for the DASD unit that you want to scratch datasets on, don't need a lock, because you're just DISPLAYING the UCB's (UCBDASD) or finding their address initially (BACKENDU), and not changing anything. So you don't need a lock, because you're not changing anything, and therefore you don't have to get authorized in order to obtain any lock. Alex himself pointed this out as well, but I wanted to bring it to your attention, since some of you might want to write programs which scan UCB's using this method. If you need to change something in the ULUT itself, it needs to be serialized and the program has to be APF-authorized to do that (I think). But if you're just doing lookups, it doesn't seem to matter. Again, I want to point out that this is an "undocumented interface" because it changes, and anyone who uses it, is obligated to keep track of the changes. As long as you query the "type" field in the ULUT, which is a one-byte field right after the "ULUT" eyecatcher, at ULUT+4, and you account for the layout of that particular ULUT "type", it seems that you're going to be OK. All the best of everything to all of you. Sincerely, Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: switching to new shared sms commds
When we expanded the COMMDS, we did not have any issues with any LPARS while we were switching over to the new one. Thus, I doubt that it will be a problem. Regards, Hervey -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Leong, Dennis, ITD Sent: Tuesday, November 13, 2012 11:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: switching to new shared sms commds Hello, I appreciate the advice from folks who responded but my question remains unanswered. Will there be any problems (on the other lpars) if I do the setsms commds to point to a new commds for the first lpar? Thank you. -- Date:Wed, 7 Nov 2012 08:23:04 + From:Richard Marchant mailto:richard.march...@shoden.co.za>> Subject: Re: switching to new shared sms commds Dennis, Make sure you allocate a new COMMDS do not try using an existing one. Richard Hello, I want to switch to new sms commds on current environment that has same commds shared by 3 lpars. I come from an older sms environment where each lpar had their own set of cds's so this is different. Will there be any problems (on the other lpars) if I do the setsms commds to point to a new commds for the first lpar? I believe I will need to issue the same setsms on all lpars to point to new commds. We are z/os 1.13. Thank you. -- 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: HFS zFS and IDCAMS Alias
On Nov 13, 2012, at 09:50, McKown, John wrote:
> Sure, I've done it with other types of VSAM files. It just _seems_ weird.
> Make a PATH:
>
> DEF PATH(NAME('alias.name') -
> PATHENTRY('real.name'))
>
Why does this _have_ to be different from DEFINE ALIAS?
(And why did they overload/misuse the prevalent UNIX term
"path"?)
Are there any gotchas if I use this to create an alias^H^H^H^H^H
(I mean PATH) to an SMP/E CSI?
Thanks,
gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DS8300 HMC WEBUI logon is forced closed
Hey Dave, I guess I am going to have to go through IBM because my version 7.3.4.0.0 does not have the option of changing the Firewall settings. Who did you choose to ask about HMC questions? Thank you, Wayne Schroeder MAINFRAME STORAGE ADMINISTRATOR T 254.399.5070 M 254.644.8534 E wschroe...@txfb-ins.com 7420 Fish Pond Rd. Waco, TX 76710 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Schroeder, Wayne Sent: Tuesday, November 13, 2012 10:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DS8300 HMC WEBUI logon is forced closed Thank you Dave, I knew somebody had seen this problem before! Wayne Schroeder MAINFRAME STORAGE ADMINISTRATOR T 254.399.5070 M 254.644.8534 E wschroe...@txfb-ins.com 7420 Fish Pond Rd. Waco, TX 76710 WWW.TXFB-INS.COM CONFIDENTIALITY STATEMENT: The foregoing message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2521, and is CONFIDENTIAL. If you believe that it has been sent to you in error, do not read it. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you.-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Devine Sent: Tuesday, November 13, 2012 9:59 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DS8300 HMC WEBUI logon is forced closed Hello, I went through this a few weeks ago myself. Problem appears to have come in with HMC V7R3.4.0. A lot of faffing about trawling through ibm & some google's before i got to the answer which is down to the port firewall settings on the Ds8300 lan adaptor panel. Ports in question are 443, 8443 and 9960. Have a look at the Hardware Management console V7 Redbook which should give you some useful input. I believe the specific port with the problem is 9960, but you do need all three firewall configured. We don't have direct hmc access to the lan firewall settings on our boxes (only have the customer id) so had to raise calls with ibm for them to dial in and correct. Each affected DS8xxx H.M.C needs to be rebooted after. Once they did that, the problem's gone. Good Luck! Dave -- 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: PassTicket usage logical flaw?
CEX cards support a hardware random number generator. Rob Schramm Senior Systems Consultant Imperium Group On Tue, Nov 13, 2012 at 10:20 AM, Charles Mills wrote: > Aha! > > Thanks. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of michael.klaesc...@deutscherring-leben.de > Sent: Tuesday, November 13, 2012 1:44 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: PassTicket usage logical flaw? > > For this case, there is a "NO REPLAY PROTECTION" option availabel. Check > the > APPLDATA field of your PTKTDATA profile. See chapter 7, Secured Signon > Function of RACF Security Administrators Guide for details. > > Cheers > Michael > > > > Von:Charles Mills > An: IBM-MAIN@LISTSERV.UA.EDU > Datum: 2012-11-12 20:21 > Betreff:PassTicket usage logical flaw? > Gesendet von: IBM Mainframe Discussion List > > > > 1. A given PassTicket may only be used once (source > http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom > . > ibm.cics.ts31.doc%2Fdfht5%2Ftopics%2Fdfht516.htm) > > 2. The PassTicket algorithm is deterministic: given the same time of day > (resolution one second), the same userid, the same application ID, and the > same secured signon application key, the algorithm will always produce the > same PassTicket (experimentation reveals this to be true). > > Consider a distributed application. Some large number of automated clients > sign on to some service at quasi-random intervals. A perfect application > for > PassTickets, right? But if a second client tries to log on within the same > TOD second as an earlier client, the sign-on will be rejected because the > generated PassTicket has already been used. What is the client to do? The > obvious answer is "wait a second and try again" but that approach has some > obvious shortcomings, one of which being there is no guarantee that THAT > PassTicket has not already been used. > > Yes, one solution would be a unique userid for each client, but suppose > this > is some "mass image rollout" application or there is some other reason why > unique userids are not desirable. > > What to do? > > -- > 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: HFS zFS and IDCAMS Alias
Why? Hey, you're asking the wrong person! . I've never run into any
problems using the PATH name anywhere that I would have used the CLUSTER name.
The VSAM use of PATH predated z/OS UNIX. So why would the IBM DFP developers
even care about what UNIX used? As to why the name PATH? Well, it is usually
the name of the _path_ used to get from an AIX to a CLUSTER. I guess. And it's
easier to write PATH than something like TRAIL or ROAD or (for greater speed
access) EXPRESSWAY. I guess if it were extra cost, they could have used
TOLLWAY. But I'm getting a little silly.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets(r) is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The
MEGA Life and Health Insurance Company.SM
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Tuesday, November 13, 2012 11:32 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: HFS zFS and IDCAMS Alias
>
> On Nov 13, 2012, at 09:50, McKown, John wrote:
>
> > Sure, I've done it with other types of VSAM files. It just _seems_
> weird. Make a PATH:
> >
> > DEF PATH(NAME('alias.name') -
> > PATHENTRY('real.name'))
> >
> Why does this _have_ to be different from DEFINE ALIAS?
>
> (And why did they overload/misuse the prevalent UNIX term
> "path"?)
>
> Are there any gotchas if I use this to create an alias^H^H^H^H^H (I
> mean PATH) to an SMP/E CSI?
>
> Thanks,
> gil
>
> --
> 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
metareply (Re: HFS zFS and IDCAMS Alias)
On Tue, 13 Nov 2012 10:50:53 -0600, McKown, John wrote: >U3VyZSwgSSd2ZSBkb25lIGl0IHdpdGggb3RoZXIgdHlwZXMgb2YgVlNBTSBmaWxlcy4gSXQganVz >dCBfc2VlbXNfIHdlaXJkLiBNYWtlIGEgUEFUSDoNCg0KREVGIFBBVEgoTkFNRSgnYWxpYXMubmFt > Why does this happen when I try to Reply and quote your message via the HTML interface? I was able to Reply OK via email. Relevant headers: MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" I had no such problem with one of my own messages with headers: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Is LISTSERV base64-hostile? Is there any way to report LISTSERV bugs to LSoft? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: metareply (Re: HFS zFS and IDCAMS Alias)
On Tue, 13 Nov 2012 11:48:49 -0600, Paul Gilmartin wrote: >On Tue, 13 Nov 2012 10:50:53 -0600, McKown, John wrote: > >>U3VyZSwgSSd2ZSBkb25lIGl0IHdpdGggb3RoZXIgdHlwZXMgb2YgVlNBTSBmaWxlcy4gSXQganVz >>dCBfc2VlbXNfIHdlaXJkLiBNYWtlIGEgUEFUSDoNCg0KREVGIFBBVEgoTkFNRSgnYWxpYXMubmFt >> >Why does this happen when I try to Reply and quote your message via the >HTML interface? I was able to Reply OK via email. Relevant headers: > >MIME-Version: 1.0 >Content-Transfer-Encoding: base64 >Content-Type: text/plain; charset="utf-8" > >I had no such problem with one of my own messages with headers: > >Mime-Version: 1.0 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/plain; charset="UTF-8" > >Is LISTSERV base64-hostile? Is there any way to report LISTSERV bugs >to LSoft? > I have the same problem with R.S.'s posts. Well, the same symptoms, I've never looked via email because I am set to NOMAIL. -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-volume SMS file allocation
How about SPACE=(CYL,(273,273),RLSE) (4095 Tracks per extent, 65520 Tracks per 16 extents) with VOLCNT=10 on the storage group to allow up to 10 volumes). The extents on secondary volumes is the secondary size. Primary extent could be satified in 5 extents, and goes to another volume if the secondary space can't be satisfied (or would exceed the maximum data set size on a volume for that data set organization / type). Alternatively, SPACE=(CYL,(4369,4369),RLSE) (65535 Tracks per extent, up to 5 extents to satisfy the primary allocation on each volume, with VOLCNT=10 on the storage group to allow up to 10 volumes). Compared to the previous example, some volumes might not qualify due to the larger requirement for the primary extent. The DSORG=PS limits the dataset to the 64K Tracks, and goes to the next volume if the next extent would exceed that value. On Tue, Nov 13, 2012 at 7:38 AM, DEBERT Jean-Louis wrote: > Vernooij, CP - SPLXM wrote: > > Another approach: instead of working with multi volume extents of 1 dataset, > why not allocate as many single volume datasets as needed? > > > Thanks for the idea, but no ... I am working on an existing application, > where the single-dataset property is important (because the DSN has to be > stored somewhere) and where the multi-volume property is seen as one way to > overcome the 65,535 tracks limit (that is, allowing a bigger file) when > reading the file with BSAM. > -- 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: "New" way to do UCB lookups
> Alex Brodsky was kind enough to point out to me that the ULUT has > to be serialized, and he referred me to the SETLOCK macro, which talks > about this. > > However, it seems to me that serialization is necessary only if you > want to change something in the ULUT, and not if you just want to look > up real UCB addresses without having to be authorized. In other words, > my programs UCBDASD (CBT File 731), which just displays online DASD > UCB's, and the other program PACKRATU (CBT File 046), whose BACKENDU > module only has to find the UCB for the DASD unit that you want to > scratch datasets on, don't need a lock, because you're just DISPLAYING > the UCB's (UCBDASD) or finding their address initially (BACKENDU), and > not changing anything. So you don't need a lock, because you're not > changing anything, and therefore you don't have to get authorized in > order to obtain any lock. > > Alex himself pointed this out as well, but I wanted to bring it to > your attention, since some of you might want to write programs which > scan UCB's using this method. If you need to change something in the > ULUT itself, it needs to be serialized and the program has to be > APF-authorized to do that (I think). But if you're just doing lookups, > it doesn't seem to matter. > > Again, I want to point out that this is an "undocumented interface" > because it changes, and anyone who uses it, is obligated to keep track > of the changes. As long as you query the "type" field in the ULUT, > which is a one-byte field right after the "ULUT" eyecatcher, at ULUT+4, > and you account for the layout of that particular ULUT "type", it seems > that you're going to be OK. Keep in mind that programs which access data structures without the intended serialization may function incorrectly when the operating system changes the data structures. The ULUT, and UCBs, can be modified by the operating system when a new IODF is dynamically activated. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "New" way to do UCB lookups
Jim Mulder's point is very well taken indeed. Traversing a dynamic list without serialization on the assumption that since you do not plan to change it no one else will is a mug's game. 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: "New" way to do UCB lookups
If your code is only reading from a control block structure and you do not serialize, there is the danger that other code might serialize and update the control block structure in a way that could cause your code to behave incorrectly. I do not know the structure or use of the UCB lookup table (ULUT) as used now in z/OS. But I remember the lookup table scheme in MVT and the queue of UCBs that we used to have in between MVT and z/OS. The other code might change the UCB that you have found and are reading-only, in which case your code needs to withstand the possibility that any or all of the fields may change while you are looking at it. Possibly a UCB might be deleted, in which case even a lookup table can not prevent your code's attempting to accessing freshly FREEMAINed storage. Perhaps even the entire ULUT could be freed and replaced with a whole new ULUT at a different virtual address. Only those who have studied the code that accesses the ULUT can know exactly how safe it is to use the ULUT without first serializing. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Tuesday, November 13, 2012 3:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "New" way to do UCB lookups Jim Mulder's point is very well taken indeed. Traversing a dynamic list without serialization on the assumption that since you do not plan to change it no one else will is a mug's game. 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: "New" way to do UCB lookups
Bill Fairchild writes: Only those who have studied the code that accesses the ULUT can know exactly how safe it is to use the ULUT without first serializing. and thus makes my point better than I did. In this OCO period we cannot know. We must therefore assume that accessing a dynamic list, q On 11/13/12, Bill Fairchild wrote: > If your code is only reading from a control block structure and you do not > serialize, there is the danger that other code might serialize and update > the control block structure in a way that could cause your code to behave > incorrectly. I do not know the structure or use of the UCB lookup table > (ULUT) as used now in z/OS. But I remember the lookup table scheme in MVT > and the queue of UCBs that we used to have in between MVT and z/OS. The > other code might change the UCB that you have found and are reading-only, in > which case your code needs to withstand the possibility that any or all of > the fields may change while you are looking at it. Possibly a UCB might be > deleted, in which case even a lookup table can not prevent your code's > attempting to accessing freshly FREEMAINed storage. Perhaps even the entire > ULUT could be freed and replaced with a whole new ULUT at a different > virtual address. Only those who have studied the code that accesses the > ULUT can know exactly how safe it is to use the ULUT without first > serializing. > > Bill Fairchild > Programmer > Rocket Software > 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA > t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: > www.rocketsoftware.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of John Gilmore > Sent: Tuesday, November 13, 2012 3:38 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: "New" way to do UCB lookups > > Jim Mulder's point is very well taken indeed. > > Traversing a dynamic list without serialization on the assumption that since > you do not plan to change it no one else will is a mug's game. > > 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 > -- John Gilmore, Ashland, MA 01721 - USA t. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "New" way to do UCB lookups
I think Sam has been around long enough to understand the caveats to traversing the control blocks without serializing. I'm sure there are some monitoring the list that don't understand, so the discussion is good. For the general use case, it's "good enough" as long as you understand the caveat and are willing to live with it. One of the most popular and widely used freeware tools on this platform - ShowMVS (ShowzOS), has the same caveat with many of the displays the program provides. But most of us use it or have used it anyway and it still is a valuable tool. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "New" way to do UCB lookups
Bill Fairchild writes: Only those who have studied the code that accesses the ULUT can know exactly how safe it is to use the ULUT without first serializing. making my point better than I did. In this OCO period, we cannot study this code; ergo, we must serialize. --jg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "New" way to do UCB lookups
Couldn't the owner of the program just put a statement in the title and thus eliminating the whole issue? Ed On Nov 13, 2012, at 4:04 PM, John Gilmore wrote: Bill Fairchild writes: Only those who have studied the code that accesses the ULUT can know exactly how safe it is to use the ULUT without first serializing. and thus makes my point better than I did. In this OCO period we cannot know. We must therefore assume that accessing a dynamic list, q On 11/13/12, Bill Fairchild wrote: If your code is only reading from a control block structure and you do not serialize, there is the danger that other code might serialize and update the control block structure in a way that could cause your code to behave incorrectly. I do not know the structure or use of the UCB lookup table (ULUT) as used now in z/OS. But I remember the lookup table scheme in MVT and the queue of UCBs that we used to have in between MVT and z/ OS. The other code might change the UCB that you have found and are reading-only, in which case your code needs to withstand the possibility that any or all of the fields may change while you are looking at it. Possibly a UCB might be deleted, in which case even a lookup table can not prevent your code's attempting to accessing freshly FREEMAINed storage. Perhaps even the entire ULUT could be freed and replaced with a whole new ULUT at a different virtual address. Only those who have studied the code that accesses the ULUT can know exactly how safe it is to use the ULUT without first serializing. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of John Gilmore Sent: Tuesday, November 13, 2012 3:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: "New" way to do UCB lookups Jim Mulder's point is very well taken indeed. Traversing a dynamic list without serialization on the assumption that since you do not plan to change it no one else will is a mug's game. 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 -- John Gilmore, Ashland, MA 01721 - USA t. -- 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: "New" way to do UCB lookups
This issue has anyway, I think, been exhausted. We have two different, opposed views; neither camp is likely to change its position; moreover, there does not appear to be a substantive issue dividing us. Both camps are aware that the absence of serialization can have disagreeable consequences. The question whether these disagreeable consequences are tolerable is a judgment call. Sam and others think they are. I think not. So be it. 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: "New" way to do UCB lookups
And I for at least for one, am very likely to know when a dynamic IODF (or other major such change) is happening and therefore expect that I will get different results before, during and afterward if I am using one of the valuable tools :) at the same time. Dave Gibney Information Technology Services Washington State University > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mark Zelden > Sent: Tuesday, November 13, 2012 2:09 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: "New" way to do UCB lookups > > I think Sam has been around long enough to understand the caveats to > traversing the control blocks without serializing. I'm sure there are some > monitoring the list that don't understand, so the discussion is good. For > the general use case, it's "good enough" as long as you understand the > caveat and are willing to live with it. > > One of the most popular and widely used freeware tools on this platform - > ShowMVS (ShowzOS), has the same caveat with many of the displays > the program provides. But most of us use it or have used it anyway > and it still is a valuable tool. > > Mark > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS > mailto:m...@mzelden.com > Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html > Systems Programming expert at http://expertanswercenter.techtarget.com/ > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multi-volume SMS file allocation
Mike Schwab wrote: The DSORG=PS limits the dataset to the 64K Tracks, and goes to the next volume if the next extent would exceed that value. Are you sure of that (that it would force a change of volume when exceeding 64k tracks or whatever the limit per volume is) ??? If true, yes, I could depend simply on secondary allocation, and not have the problem with RLSE on allocated-but-non-used primary extents. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
"New" way to do UCB lookups
Hi Folks, Somebody please enlighten me. If you're trying to scratch a dataset on a pack, and somebody else is in the middle of doing an IODF change at the time, what is the difference if you are obtaining a copy of the UCB (to determine what's on the disk pack), or the real UCB itself? I'm not expecting a complete answer from somebody, but I'd at least like a reference to a manual or manuals where the perspective and advantages/disadvantages of copied, (and captured) UCB's is explained, as opposed to the real UCB's. I want to read about it. Please show me where. Thanks. All the best Sam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
