Re: publibz->infocenter->knowledgecenter
On 12/18/2014 7:37 PM, Roger Bolan wrote: I don't think IBM is even creating the kind of bookshelves we're familiar with anymore. At least, not for everything. Knowledge Center is IT from now on, boys and girls. We're not happy about it either. Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How much storage is left?
MVS Programming: Authorized Assembler Services Reference, Volume 4, describes the VSMLIST macro. One of the functions that you can request is "The ranges of private area that are unallocated.' I have never used this macro, but think it will do what you ask. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SRCHFOR within SDSF job queue
I wonder why no one had voted for these suggestions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Suggestion for the ICETOOL SUBSET operator
Thomas, You can use INREC to select the data you want from various parts of the record. It supports padding and all other functions. Why do you want to additional syntax on the toolin and make it complex? Using INREC you have a lot more flexibility. for example. //STEP0100 EXEC PGM=ICETOOL //TOOLMSG DD SYSOUT=* //DFSMSG DD SYSOUT=* //IN DD * A01 B02 C03 D04 E05 F06 G07 H08 I09 J10 K11 L12 M13 N14 //OUT DD SYSOUT=* //TOOLIN DD * SUBSET FROM(IN) TO(OUT) INPUT KEEP RRN(3,12) USING(CTL1) /* //CTL1CNTL DD * INREC BUILD=(01,7, $ COPY 6 BYTES FROM POSITION 01 30,6, $ COPY 7 BYTES FROM POSITION 30 4X, $ PAD 4 SPACES 30,6,ZD,PD,LENGTH=4, $ CONVERT ZD TO PACKED 2X, $ PAD 2 SPACES C' THOMAS ') $ PAD CONSTANT THOMAS AT END /* The output would be something like this C 03 THOMAS D 04 < THOMAS E 05 * THOMAS F 06 % THOMAS G 07 @ THOMAS H 08 THOMAS I 09 THOMAS J 10 THOMAS K 11 THOMAS L 12 THOMAS You just showed an example of 2 fields you want to pick and I am sure others want to expand to "n" number of fields and other functions too. Why re-invent the wheel once again when it is already available? Thanks, Sri Hari Kolusu DFSORT Development IBM Corporation Email: skol...@us.ibm.com Phone: 408-927-2187 Tie Line: 457-2187 IBM Mainframe Discussion List wrote on 12/17/2014 08:52:07 AM: > From: Thomas Berg > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 12/17/2014 09:02 AM > Subject: Suggestion for the ICETOOL SUBSET operator > Sent by: IBM Mainframe Discussion List > > Using the ICETTOOL SUBSET operator I missed a position subselection > option for the FIRST/LAST/RRN parms. > I can of course use other DFSORT operators for this purpose, but > felt that this possibility would fit well in the SUBSET function. > > Example: > > RRN(3,12,(31:22,71:10))or RRN(3,12,31:22,71:10) > > Here only the parts from position 31, length 22, and position 71, > length 10, is selected for the > output record. (The record will contain selected parts concatenated > from pos 1, length 32.) > > Padding spec may also be added. > > > > Best Regards, > Thomas Berg > ___ > Thomas Berg Specialist zOS/RQM/IT Delivery Swedbank AB (Publ) > > -- > 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: Suppress generation of LOGREC records
Anthony Fletcher wrote: >Has anyone heard of a way to suppress generation of LOGREC records? No, not as far as I know. >We recently had a situation where an application was abending repeatedly and >generating LOGREC records. This manifested itself as very HIGH CPU use in >MSTJCL00 but because the LOGREC records are going to the LOGGER they were >being generated so fast that it was impossible to get to look at one. Just stop/cancel the application and have a look at the records using EREP while looking in SYSLOG and joblog at that same same time. >We were wondering whether there was a way to temporarily tell the LOGREC >processor to stop generating records. We did consider switching LOGREC back to >DASD records which would fill up, but suspected that the attempt to create >records would still use a lot of CPU so would prefer a setting that told the >LOGREC writer to not even try. You can create a LARGE LOGREC dataset just for diagnostics (Use EVENT=Y to quickly see what happened) and then switch back to your Log stream. Are you getting thousand records? If so, what type of records? Last question: Are you also getting dumps and dumps? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: publibz->infocenter->knowledgecenter
On 12/19/2014 8:33 AM, Paul Gilmartin wrote: On Fri, 19 Dec 2014 07:08:21 -0700, Steve Comstock wrote: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/library ? OS390? Seriously? But did you follow the link? "Browse Shelves" takes you to a list of pdf bookshelves that include z/OS V2R1. The operant qualifier is "PDF". I must download an entire book in order to read a single paragraph. Then I face the choice of discarding it and refetching if I need it again, or bogarting it. You changed the playing field here, from 'OS390' dismay to 'LookAt' dismay. My point was that OS390 is misleading, that you can find current z/OS in the list. But then, you knew that. :-) -Steve Comstock -- 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: publibz->infocenter->knowledgecenter
On Fri, 19 Dec 2014 07:08:21 -0700, Steve Comstock wrote: >>> >>> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/library >>> ? >> OS390? Seriously? > >But did you follow the link? "Browse Shelves" takes you to a >list of pdf bookshelves that include z/OS V2R1. > The operant qualifier is "PDF". I must download an entire book in order to read a single paragraph. Then I face the choice of discarding it and refetching if I need it again, or bogarting it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: publibz->infocenter->knowledgecenter
I know this is going to sound like a broken record. The "new" tools from IBM are neither as reliable, available, nor as usable as the tools they replace! yeah, now you're talking: and there's a technical term for it too: COGNITIVE LOCKOUT RAGE == just when you've finally mastered all the ins-and-outs of some system, some f&^*%$ clown changes it all (and of course, it's ALWAYS under the guise of "making it better") and you have to start learning new tricks all over from scratch to do the same stuff. there's another word in this context i like too: the German term Schlimmbesserung: an 'improvement' which makes things worse /s/ tuco bonno -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: publibz->infocenter->knowledgecenter
yeah, now you're talking: and there's a technical term for it too: COGNITIVE LOCKOUT RAGE == just when you've finally mastered all the ins-and-outs of some system, some f&^*%$ clown changes it all (and of course, it's ALWAYS under the guise of "making it better") and you have to start learning new tricks all over from scratch to do the same stuff. there's another word in this context i like too: the German term Schlimmbesserung: an 'improvement' which makes things worse /s/ tuco bonno graduate, college of conflict management, university of southeast asia "i partied on the Ho Chi Minh trail -- tiến len !!! " -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hobart Spitz Sent: Friday, 19 December, 2014 09:34 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: publibz->infocenter->knowledgecenter Yes. If you've tried the new doc site and know how hard it is to get information from it, you wouldn't be asking. I am still amazed how often people restructure documents, web sites, etc. in the name of improvement without taking into account all the people who have learned to deal with the existing system. Oh, and the new system is frequently no better than the old one. On Fri, Dec 19, 2014 at 8:09 AM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > On Thu, 18 Dec 2014 16:04:01 -0500, Hobart Spitz wrote: > > >Have you tried > > > >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/library > > > >? > > > OS390? Seriously? > > --gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- OREXXMan -- 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: publibz->infocenter->knowledgecenter
Yes. If you've tried the new doc site and know how hard it is to get information from it, you wouldn't be asking. I am still amazed how often people restructure documents, web sites, etc. in the name of improvement without taking into account all the people who have learned to deal with the existing system. Oh, and the new system is frequently no better than the old one. On Fri, Dec 19, 2014 at 8:09 AM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > On Thu, 18 Dec 2014 16:04:01 -0500, Hobart Spitz wrote: > > >Have you tried > > > >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/library > > > >? > > > OS390? Seriously? > > --gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- OREXXMan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: publibz->infocenter->knowledgecenter
On 12/19/2014 6:09 AM, Paul Gilmartin wrote: On Thu, 18 Dec 2014 16:04:01 -0500, Hobart Spitz wrote: Have you tried http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/library ? OS390? Seriously? But did you follow the link? "Browse Shelves" takes you to a list of pdf bookshelves that include z/OS V2R1. -Steve Comstock --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: I want to add data of 30 VSAM files to one PS flat file.
> And I think I can safely say I have never seen a DD NULLDATASET command ;-)) I'm sure you haven't. Neither have I ever seen a DD NULLFILE command. ;-)) touché ;-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
Of course, they could just place a hard cap on the offending lpar to limit the damage until a better solution is reached. The hardcap could be set higher than the weight for the lpar for WLM.. Thus limiting the damage that can be done. Rob Schramm On Dec 19, 2014 6:13 AM, "Martin Packer" wrote: > Well there IS code before we "hop on the enclave". Authorisation code and > the like. Not being that good a DB2 faker :-) I don't know if there are > user exits involved. > > But, yes, it's possible the code in DIST other than Enclave is > significant. You can always tell for Type 30: TCB and SRB vs Enclave SRB > (part of TCB as it's Preemptible-Class). > > I'm just aware that this would in my experience (FWIW) be a first: > Non-enclave in DIST being a problem. But life is full of firsts. :-) > > Cheers, Martin > > Martin Packer, > zChampion, Principal Systems Investigator, > Worldwide Banking Center of Excellence, IBM > > +44-7802-245-584 > > email: martin_pac...@uk.ibm.com > > Twitter / Facebook IDs: MartinPacker > Blog: > https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker > > > > From: Shane Ginnane > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 19/12/2014 03:43 > Subject:Re: MIPS, CEC, LPARs, PRISM, WLM > Sent by:IBM Mainframe Discussion List > > > > On Wed, 17 Dec 2014 16:12:31 +, Martin Packer wrote: > > >Sounds like you also need to familiarise yourself with how DIST works - > >meaning enclaves that run the actual DDF SQL. As I say, unlikely DIST > >itself but rather more likely the DDF is "in play". > > Hmmm - that might be the common lore. > DIST may indeed be the culprit rather than DDF enclaves. > Where I have seen this there is a *LOT* of enclaves being created - I > presumed (without a lot of hard evidence) that the cost of setup/teardown > was appearing in DIST. And, of course, DIST is an important address space, > and runaway CPU consumption there hurts (almost) everyone else. > > The OP indicated cancelling a single thread relieves the situation - > should be easy enough to track down the likely suspect. > > Shane .. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Suppress generation of LOGREC records
On Thu, 18 Dec 2014 11:09:53 -0600, Anthony Fletcher wrote: >We recently had a situation where an application was abending repeatedly >and generating LOGREC records. What kind of an application? I can't say for sure, but I don't remember seeing records written to LOGREC for normal application abends. >This manifested itself as very HIGH CPU use in MSTJCL00 but because >the LOGREC records are going to the LOGGER they were being generated >so fast that it was impossible to get to look at one. Couldn't you cancel the address space that was abending? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: publibz->infocenter->knowledgecenter
On Thu, 18 Dec 2014 16:04:01 -0500, Hobart Spitz wrote: >Have you tried > >http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/library > >? > OS390? Seriously? --gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: MIPS, CEC, LPARs, PRISM, WLM
Well there IS code before we "hop on the enclave". Authorisation code and the like. Not being that good a DB2 faker :-) I don't know if there are user exits involved. But, yes, it's possible the code in DIST other than Enclave is significant. You can always tell for Type 30: TCB and SRB vs Enclave SRB (part of TCB as it's Preemptible-Class). I'm just aware that this would in my experience (FWIW) be a first: Non-enclave in DIST being a problem. But life is full of firsts. :-) Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Shane Ginnane To: IBM-MAIN@LISTSERV.UA.EDU Date: 19/12/2014 03:43 Subject:Re: MIPS, CEC, LPARs, PRISM, WLM Sent by:IBM Mainframe Discussion List On Wed, 17 Dec 2014 16:12:31 +, Martin Packer wrote: >Sounds like you also need to familiarise yourself with how DIST works - >meaning enclaves that run the actual DDF SQL. As I say, unlikely DIST >itself but rather more likely the DDF is "in play". Hmmm - that might be the common lore. DIST may indeed be the culprit rather than DDF enclaves. Where I have seen this there is a *LOT* of enclaves being created - I presumed (without a lot of hard evidence) that the cost of setup/teardown was appearing in DIST. And, of course, DIST is an important address space, and runaway CPU consumption there hurts (almost) everyone else. The OP indicated cancelling a single thread relieves the situation - should be easy enough to track down the likely suspect. Shane .. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
