AW: Re: AW: Re: codepage restrictions on IBM applications
>>I doubt this is still correct information. After all, even z/OS base >>components issue WTOs in mixed case. ZFS is one that comes to my mind, and >>I'm pretty sure there are more but I can't name them without looking up. >> >What about WTOR? You mention ZFS (ITYM zFS; they're not the same.) >and UNIX filesystems are case-sensitive. Yep, zFS not ZFS, although the address space I'm takling about is named ZFS not zFS. And UNIX case sensitivity is not involved here. It is a z/OS program writing mixed case messages using WTOs (and possibly WTORs). Some other components writeing mixed mode messages to syslog: - SMS PDSE support, e.g. IGW040I - z/OS Message Flood Automaiton, CNZZ messages - z/OS SDSF, ISF messages - CICS V4, e.g. DFH0100 -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>> Thanks. What I do not yet understand: The TRNE address is 231A7800, >> where as the address in R15 231A7BB8. Why the difference? > >TRNE is a copy of Translation-Exception Identification, which is >defined in Principles Of Operation. I usually do read the manuals before posting, and I did in this case as well. Unfotunately, I was searching the PoOp (offline in the PDF) for "Translation exception" but got no hint. The missing dash makes the difference. Argrrr Understood now. Slowly derusting my debugging skills. Thanks for all the help with this. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE V2 MaxGen Limit Query
Please have a look at APAR OA43951 and the corresponding solution: > Add a new field to the DFA DFAMAXGN which contains the > maximum number of generations this system supports. With this information it should be possible to access the field in the DFA from REXX. HTH. Klaus Stanislawiak -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dyck, Lionel B. (TRA) Sent: Tuesday, July 26, 2016 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PDSE V2 MaxGen Limit Query Is there a way to query the current MAXGENS_LIMIT from the SMS configuration in either REXX or ISPF? I'm looking for a way to prevent a user from specifying a larger maxgen than is allowed in a dialog I'm working on. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>Tiny chance, tiny, tiny, of runtime/compiler problem if you are on V5+. Nice >to know, just to know whether to discount it completely. We're on the way to Cobol V5 but production is still V4. >With the COBOL program and the record causing the failure, it would be >possible to identify the issue. Of course, it is not always possible to supply >these things. Yes, this is what I have asked the developer to do. However, there are two possible inhibitor: a) We're not given permission to move the record from prod to test, and b) the problem does not occur in test with even that record, because the data on the data base is different. I have little hope so far they will succeed to reproduce the problem in test before we know more about the cause (chicken or egg problem). >For the first, using compiler option SSRANGE (with LE Runtime option CHECK(ON) >if you are before V5) will help. Yes, but again, easy in test, impossible in prod. >I don't look at programs the way a Sysprog does, and that's probably true vice >versa. What is easy for me to say and do, is probably as much like moon-dust >to you as a lot on this list is to me :-) Fortuntately, I've been doing application programming a lot in my career as well, so I know both sides very well. What I'm pretty ignorant at is Cobol. I'm mainly a PL/I, Assembler and REXX programmer. But I'm learning -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
For the few that know how to use FAMS (IGWFAMS) it's a matter of extracting the "MAXGENS" field data. As the returned data is similar to IGGCSI00 maybe IBM can be nice and provide a FAMS function for these fields. Dan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF Parms
Andy, You may want to look at the Last post by Alan Field where he changed the defaults in ISFPARMS https://groups.google.com/forum/#!topic/bit.listserv.ibm-main/tWUq3r6uC80 Thanks, Kolusu From: "Pesce, Andy" To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/26/2016 02:03 PM Subject:SDSF Parms Sent by:IBM Mainframe Discussion List I have been searching for this and cannot seem to find it. On my z/OS 1.13 system, if I am in the "DA OJOB" screen. I can sit and hit "Enter" and it continuously updates the info for jobs running. I can also go into auto-update with a &5 to update the screen every 5 seconds on its own. I have now upgraded z/OS to 2.2. If I am in the "DA OJOB" screen and I hit the "Enter" button, it goes back to the main menu. The only way to look at things is to go into auto-update mode. Anyone else run across this? I was thinking that I ran across this going from z/OS 1.9 to z/OS 1.13. I thought there was a "default" of something that I had to change. If anyone knows what I am talking about, please email me. Andy Pesce andy.pe...@autozone.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: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
On 7/26/2016 4:21 PM, Peter Hunkeler wrote: In (late) response to Jim Mulder's comment: How about the TRNE and BEA fields in that same XSB? > XSBBEA and XSBTRNE confirm what I said before. The BASSM was executed. The target address in R15 was in a page of storage that was not GETMAINed at that time, resulting in a 0C4-11 abend. Since the dumping program subsequently dumped that page, the page must have been GETMAINed after the 0C4-11 abend, presumably by the exception handling/dumping processing. Thanks. What I do not yet understand: The TRNE address is 231A7800, where as the address in R15 231A7BB8. Why the difference? Described in Principles of Operation under "assigned memory locations" (A8-AF). Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
S0C4-11 abend caused by BASSM to address with all X'00' bytes
For a COBOL program to produce an exotic abend (removing the current record and having a clean run points a pretty big finger at the COBOL program) then it is a storage overlay. Tiny chance, tiny, tiny, of runtime/compiler problem if you are on V5+. Nice to know, just to know whether to discount it completely. With the COBOL program and the record causing the failure, it would be possible to identify the issue. Of course, it is not always possible to supply these things. Two main things cause storage overlays in COBOL. Wild "subscripts" (which includes reference-modifiers) and parameter mismatches on CALLs. For the first, using compiler option SSRANGE (with LE Runtime option CHECK(ON) if you are before V5) will help. For the CALLs, it is down to "inspection" of the code. Since "pointers" have been available in COBOL, those have to be taken into consideration as well. Look for any "manipulation" of pointers, especially with 'rithmatic, and especially on definitions which are not COMP-5 (or TRUNC(BIN)). I don't look at programs the way a Sysprog does, and that's probably true vice versa. What is easy for me to say and do, is probably as much like moon-dust to you as a lot on this list is to me :-) You're on the right track. Deleting the record shows that. S0CA is interesting, but you don't get many of those in a COBOL program either. Perhaps the same cause? For this type of problem (removing the record "fixes" it) there are two things to look for: what is it about that current record?; is there any "crosstalk" possible with a previous record. Yes, even for a COBOL programmer a SYSUDUMP would help. Oldschool, anyway. Shoot anyone who suggests firing up a debugger :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SDSF Parms
I have been searching for this and cannot seem to find it. On my z/OS 1.13 system, if I am in the "DA OJOB" screen. I can sit and hit "Enter" and it continuously updates the info for jobs running. I can also go into auto-update with a &5 to update the screen every 5 seconds on its own. I have now upgraded z/OS to 2.2. If I am in the "DA OJOB" screen and I hit the "Enter" button, it goes back to the main menu. The only way to look at things is to go into auto-update mode. Anyone else run across this? I was thinking that I ran across this going from z/OS 1.9 to z/OS 1.13. I thought there was a "default" of something that I had to change. If anyone knows what I am talking about, please email me. Andy Pesce andy.pe...@autozone.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
> Thanks. What I do not yet understand: The TRNE address is 231A7800, > where as the address in R15 231A7BB8. Why the difference? TRNE is a copy of Translation-Exception Identification, which is defined in Principles Of Operation. Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. 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: AW: Re: codepage restrictions on IBM applications
On Tue, 26 Jul 2016 22:04:42 +0200, Peter Hunkeler wrote: > >>It's worse than that. One may safely use those characters that are called >>in manuals Alphabetic, Numeric, or Special. They're enumerated. all others >>are considered Invalid. Alphabetic does *not* include lower case. > >I doubt this is still correct information. After all, even z/OS base >components issue WTOs in mixed case. ZFS is one that comes to my mind, and I'm >pretty sure there are more but I can't name them without looking up. > What about WTOR? You mention ZFS (ITYM zFS; they're not the same.) and UNIX filesystems are case-sensitive. And I believe any NFS is required to have an all-majuscule handle, useful for little besides operator commands. And I still wonder about those pesky half-Katakana or half-Cyrillic terminals. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>> In (late) response to Jim Mulder's comment: >>>How about the TRNE and BEA fields in that same XSB? > >XSBBEA and XSBTRNE confirm what I said before. The BASSM was >executed. The target address in R15 was in a page of storage >that was not GETMAINed at that time, resulting in a 0C4-11 abend. >Since the dumping program subsequently dumped that page, the page >must have been GETMAINed after the 0C4-11 abend, presumably by >the exception handling/dumping processing. Thanks. What I do not yet understand: The TRNE address is 231A7800, where as the address in R15 231A7BB8. Why the difference? -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
> In (late) response to Jim Mulder's comment: > >How about the TRNE and BEA fields in that same XSB? XSBBEA and XSBTRNE confirm what I said before. The BASSM was executed. The target address in R15 was in a page of storage that was not GETMAINed at that time, resulting in a 0C4-11 abend. Since the dumping program subsequently dumped that page, the page must have been GETMAINed after the 0C4-11 abend, presumably by the exception handling/dumping processing. Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. 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
AW: Re: codepage restrictions on IBM applications
>It's worse than that. One may safely use those characters that are called >in manuals Alphabetic, Numeric, or Special. They're enumerated. all others >are considered Invalid. Alphabetic does *not* include lower case. I doubt this is still correct information. After all, even z/OS base components issue WTOs in mixed case. ZFS is one that comes to my mind, and I'm pretty sure there are more but I can't name them without looking up. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
When to use TRNE in the XSB? (was: S0C4-11 abend caused by BASSM to address...)
>>>What are the full contents of the 128-bit PSW? What's the 64-bit TEA value? >> >> I got a CEEDUMP and an analysis from StartTool DA. Both tell me the >> failing PSW is478D0400 A31A7BB8 Looking at the SVC dump at the PRB/ >> XSB which is now producing the SVC dump (WLIC is 00020033), I see: >> XSB+00E0 PSW16 47850400 8000 231A7BB8 > >How about the TRNE and BEA fields in that same XSB? The XSB has: TRNE. 231A7800 BEA.. 24D90BE0 This translation exception address does not seem to match where he PSW NSI points to. From the previous discussion the conclusion was that it is most likely the storage pointed to by PSW NSI had not yet been getmained at the time of the original error, but later during recove3ry processing but before the dump was taken. But shouldn't I expect to see the PSW NIS address in the TRNE field of the XSB? In other words, what does the TRNE field tell me a) in general, and b) in this case. When is the TRNE field in the XSB updated? The corresponding PRB seems to contain similar contradicting information in fields RTPSW1 and RTPSW2: RTPSW1... 478D0400 A31A7BB8 RTPSW2... 00020011 231A7800 What can I learn from this? How do I properly use these fields in dump analysis? More information from the dumps can be found in the attachement (same as attched in the original discussion). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN *** CEEDUMP information follows * CEE3DMP V2 R1.0: Condition processing resulted in the unhandled condition. 07/15/16 12:12:28 AM ASID: 0159 Job ID: J0274722 Job name: P07W04UA Step name: DB2RUN UserID: TWSP0A CEE3845I CEEDUMP Processing started. Information for enclave ZTVXXX00 Information for thread 8000 Traceback: DSA Entry E Offset Statement Load Mod Program Unit Service Status 1 CEEHDSP +4A4C CEEPLPKA CEEHDSP UI90017 Call 2 -01BE8FAE HRDRFREA Exception 3 HRDRFREA+4396 HRDRFREA HRDRFREA Call 4 IGZCFCC +02FC IGZCPAC IGZCFCC UI19860 Call 5 HRDDBLNK+9C92 HRDDBLNK HRDDBLNK Call ... 14IGZCFCC +02FC IGZCPAC IGZCFCC UI19860 Call 15ZTVXXX00+0A10 ZTVXXX00 ZTVXXX00 Call DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile Attributes 1 23117AE0 08DA2B60 08DA2B60 +4A4C 20150130 CEL 2 0001 24D90B66 24D90B66 -01BE8FAE 3 231176E8 24D85D48 24D85D48 +4396 20130225 COBOL 4 231174F0 20EDB610 20EDB610 +02FC 20140722 LIBRARY 5 23117078 235F6400 235F6400 +9C92 20160624 COBOL ... 1423115258 20EDB610 20EDB610 +02FC 20140722 LIBRARY 1523115030 23100428 23100428 +0A10 20100129 COBOL Condition Information for Active Routines Condition Information for (DSA address 0001) CIB Address: 231181B0 Current Condition: CEE0198S The termination of a thread was signaled due to an unhandled condition. Original Condition: CEE3204S The system detected a protection exception (System Completion Code=0C4). Location: Program Unit: Entry: Statement: Offset: -01BE8FAE Machine State: ILC. 0002Interruption Code. 0004 PSW. 478D0400 A31A7BB8 GPR0. _24BD7528 GPR1. _DDF4 GPR2. _24D96690 GPR3. _0004 GPR4. _23145460 GPR5. _77FC GPR6. _0001 GPR7. _DC20 GPR8. _009B7028 GPR9. _24BD73A8 GPR10 _009B7008 GPR11 _009B7E88 GPR12 _24D90B40 GPR13 _0001 GPR14 _A4D90BE2 GPR15 _A31A7BB8 FPC.. FPR0. 4EE6ED27 D6668000FPR1. 487F FF00 FPR2. 4264 FPR3. FPR4. 40326E64 05A0FPR5. FPR6. FPR7. FPR8. FPR9. FPR10
AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>You told us that the instruction address where the BASSM goes is correct. No, I told that the address fetched into R15 matches where the BASSM jumped to and matches what is seem in the PSW. >What happens, if you switch off LE dump processing by LE option TRAP(OFF)? I don't dare to ask for this. As said there is Smart/Restart and with my current (limited) understanding of what this does and what it depends on, this would be risky. The application depends on the tool to coordinate sequential file processing with DB2 processing in the case of abends and restarts. I'm hoping for the SYSMDUMP. If that fails, I will take the burden and ask for a SLIP. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>[snip] I would take a closer look at the call position of the COBOL module at >level 3, at position 4396. >The name is HRDRFREA. >>maybe this is all misleading ... I agree with your findings. Module HRDRFREA is calling DSNHLI at this offset. So far nothing special. However, the job runs under control of Smart/Restart that intercepts just about anything, and probably needs to, in order to fullfill it's duties to make the job restartable. I don't know much about the internals or Smart/Restart, but from another case I had to invesitgate, I learned that it is intercepting SVCs like open, close, as well as BSAM/QSAM read/write routines, etc., etc. What makes it worse is the fact that we also use StarTool DA which should be a help in diagnosing appliation problems. Smart/Restart is the first to learn about an exception (or is it after LE?), it recognized StarTools DA is also part of the game. The former then advises the later to take an SVC dump. The later has unfortunate dump options built in its code that request only mininmal content (not TRT, etc.) and forces system dump options to be ignored. Result of all that is misleading information in the dumps. Lack of a system trace, I'm unable to see the real events that happened. I only wanted to understand why a S0C4-11 was reported when I had expected a S0C1. I did not talk about the following so far for that reason. Based on what I know so far, I'm convinced the problem seen is a delayed effect of a storage overlay somewhere else in the Cobol code. Support people identified the current input record, removed it from the input file and the job runs fine. Happened to more times so far. This why I suspect that something with that record leads to false behabiour of the code, such as writing beyond the end of a table. What I also did not mention to anyone so far: I see a single line message from Smart/Restart that says a S0CA (Decimal Overflow) has happended. Not indication where, no dump at this time. Nothing but silence. This was just a bit before the S0C4-11 messages start to show up. I'm hoping for a system trace in the SYSMDUMP that I was requesting to be added to the job (mentioned in a previous post). Kind of seems to be a case liek the one Skip Robinson mentione (S0C7). We'll see. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
When looking some time longer at this, all seems ok; the 2nd DSA contains the informations that result from the exception, and the exception is because the BASSM jumps to a place where the machine instructions have been overwritten by zeroes (wild guess). You told us that the instruction address where the BASSM goes is correct. That should give 0C1, not 0C4; could it be that the 0C1 is covered by a 0C4 which happens while LE tries to do its dump processing? What happens, if you switch off LE dump processing by LE option TRAP(OFF)? (used to be called NOSPIE,NOSTAE some ten years ago). Kind regards Bernd Bernd Oppolzer schrieb: IMO, the DSA address of the 2nd Save Area is not resonable: DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile Attributes 1 23117AE0 08DA2B60 08DA2B60 +4A4C 20150130 CEL 2 0001 24D90B66 24D90B66 -01BE8FAE 3 231176E8 24D85D48 24D85D48 +4396 20130225 COBOL 4 231174F0 20EDB610 20EDB610 +02FC 20140722 LIBRARY 5 23117078 235F6400 235F6400 +9C92 20160624 COBOL ... 1423115258 20EDB610 20EDB610 +02FC 20140722 LIBRARY 1523115030 23100428 23100428 +0A10 20100129 COBOL I would take a closer look at the call position of the COBOL module at level 3, at position 4396. The name is HRDRFREA. What is called there, and why does the called module build a save area at such a strange place 0001? The informations contained there seem wrong, too. That is the save area and register information printed; maybe this is all misleading ... Kind regards Bernd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Boulder and Rochester Servers
Thanks John. Got bitten doing a CHANGE ALL on my JCL and changing a bit too much :) All fixed again. HOLDDATA downloading as I type. Alan Field Systems Engineer Principal Blue Cross Blue Shield of MN 651.662.3546 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: Tuesday, July 26, 2016 1:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Boulder and Rochester Servers From the guy who manages the servers: "The URL https://urldefense.proofpoint.com/v2/url?u=https-3A__eccgw01.boulder.ibm.com_service_projects_ecc_ws_&d=CwICAw&c=zjLIypOkeQKJfe4BYrJ5J55pYA-45JElRiaMoh2hP7Q&r=SaL11MvL9LWz-4CkTmMYltgrRR9mrR4t5HY7AKmOSPE&m=FRTzyJIghJ3bB2Bul_HKpFSe5xVFRynf_9h3gTgevks&s=y-NWB-dx1TjmggM6q1gN0yBmji6zMoXH-KRNnA8Wg0A&e= has a typo in it. It should be "services" and it works." Richards, Robert B. wrote: > I could not get to that either, but to get HOLDDATA nightly, I > normally use: public.dhe.ibm.com > > It worked four hours ago. > > Bob > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Field, Alan > Sent: Monday, July 25, 2016 10:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Boulder and Rochester Servers > > Trying to download HOLDDATA. Same job I've used for years. > > GIM69195S ** RECEIVE PROCESSING HAS FAILED. THE SERVER AT > > https://urldefense.proofpoint.com/v2/url?u=https-3A__eccgw01.boulder.ibm.com_service_projects_ecc_ws_&d=CwICAw&c=zjLIypOkeQKJfe4BYrJ5J55pYA-45JElRiaMoh2hP7Q&r=SaL11MvL9LWz-4CkTmMYltgrRR9mrR4t5HY7AKmOSPE&m=FRTzyJIghJ3bB2Bul_HKpFSe5xVFRynf_9h3gTgevks&s=y-NWB-dx1TjmggM6q1gN0yBmji6zMoXH-KRNnA8Wg0A&e= > DETECTED > AN ERROR: 404 - Not Found. > > Does IBM have a problem or did something change and I missed the notification? -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you must not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Boulder and Rochester Servers
From the guy who manages the servers: "The URL https://eccgw01.boulder.ibm.com/service/projects/ecc/ws/ has a typo in it. It should be "services" and it works." Richards, Robert B. wrote: I could not get to that either, but to get HOLDDATA nightly, I normally use: public.dhe.ibm.com It worked four hours ago. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Field, Alan Sent: Monday, July 25, 2016 10:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Boulder and Rochester Servers Trying to download HOLDDATA. Same job I've used for years. GIM69195S ** RECEIVE PROCESSING HAS FAILED. THE SERVER AT https://eccgw01.boulder.ibm.com/service/projects/ecc/ws/ DETECTED AN ERROR: 404 - Not Found. Does IBM have a problem or did something change and I missed the notification? -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
IMO, the DSA address of the 2nd Save Area is not resonable: DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile Attributes 1 23117AE0 08DA2B60 08DA2B60 +4A4C 20150130 CEL 2 0001 24D90B66 24D90B66 -01BE8FAE 3 231176E8 24D85D48 24D85D48 +4396 20130225 COBOL 4 231174F0 20EDB610 20EDB610 +02FC 20140722 LIBRARY 5 23117078 235F6400 235F6400 +9C92 20160624 COBOL ... 1423115258 20EDB610 20EDB610 +02FC 20140722 LIBRARY 1523115030 23100428 23100428 +0A10 20100129 COBOL I would take a closer look at the call position of the COBOL module at level 3, at position 4396. The name is HRDRFREA. What is called there, and why does the called module build a save area at such a strange place 0001? The informations contained there seem wrong, too. That is the save area and register information printed; maybe this is all misleading ... Kind regards Bernd Peter Hunkeler schrieb: As expected, having the dump information inline did not work out. I'm reposting with an attachement. Hopefully this will work better. In (late) response to Jim Mulder's comment: How about the TRNE and BEA fields in that same XSB? and Tom Marchant's comment: If you show the exact information from the dump, rather than your interpretation of that data, there is a better chance that someone will be able to see something that you didn't. I'm posting some raw information from the CEEDUMP as well as from IPCS. I have added a few lines of comment starting with "***". In the CEEDUMP part I have shortened the trace back list by deleting some intermediate call information (entries 6-13). I don't want to add an futher interpretation from me. If you still find some time to have a look and post whatever information you might find useful, I would very much appreciate. Thanks Peter -- Peter Hunkeler -- 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
Looking for an assembler sample of HTTP/HTTPS protocol enabler
co-posted to ibm-main & tcp-l I am looking for a sample asm sample code that demonstrate the use of z/os http protocol enabler. If you have code to share, it will be (very) helpful ;-) Thanks in advance, ITschak Mugzach -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E packaging question
Subject: SMP/E packaging question From: "Way, Richard" Reply-To: IBM Mainframe Discussion List eply I need to provide SMP service to an existing released product to fix the binder control cards (only) due to some missing load module ALIASes. Can someone assist with identifying the steps we'd follow to accomplish this, please? I know what changes I want to make to the binder control cards, but I am not versed in SMP/E (obviously). I believe we'd just need to update the JCLIN and get them to RECEIVE/APPLY/ACCEPT the resultant PTF, but I am unclear on the details. Thanks! Rich Way HPE Security - Data Security You might want to look at a sample usermod that comes with High Level Assembler to add an alias IEV90 to ASMA90. It is documented in the Inastallation and Customization Guide chapter 4 (SC26-3494), and is distributed as member ASMAIEV in ASM.SASMSAM1. The trick is to include a ++MOD for a module from the target library (LKLIB). When I last installed this on z/OS 2.1 the binder output report showed an include for SASMMOD1(ASMA90), effectively replacing the load module with itself. Hope this helps! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
Thank you
--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI&T Service Delivery & Engineering
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Tuesday, July 26, 2016 10:34 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
So we use OPS/MVS to capture the output from a D SMS,OPTIONS Command. That
goes into a dataset (uacc READ)
Then if needed, I can execio to the file and extract the data I need. Should
work for most users.
If you have automation, you can place the output into a file for later use
Lizette
PS I voted for your RFE, just wish I could vote more than once.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Dyck, Lionel B. (TRA)
> Sent: Tuesday, July 26, 2016 8:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
>
> Liz - that works for a user with console command authority which does
> not apply to 99% of most users. Same for viewing sys1.parmlib. I've
> opened a RFE to IBM for a sysvar or mvsvar variable :-)
>
>
> --
>
> Lionel B. Dyck (TRA Contractor)
> Mainframe Systems Programmer
> Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T
> Service Delivery & Engineering
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Lizette Koehler
> Sent: Tuesday, July 26, 2016 9:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
>
> The D SMS,OPTIONS command will contain the maxgen limit in the display.
>
> So either an ISFEXEC for the MVS Command or going into OPER in REXX
> could work.
>
> Not sure if there is a control block you could parse through to get that info.
>
> CA_RECLAIM = {NONE | DATACLAS}
> PS_EXT_VERSION ={1|2}
> HONOR_DSNTYPE_PDSE = NO PDSE_VERSION = 1
> SUPPRESS_SMSMSG = IGD17054I(NO ) IGD17227I(NO ) IGD17395I(NO )
> MAXGENS_LIMIT = maxgenlimit USER_ACSVAR = (value1,value2,value3)
> PDSE_PENDING_DELETE_INTERVAL =
>
> Of course this would be dependent on the level of z/OS Running. This
> display is from z/OS V2.2
>
> Lizette
>
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dyck, Lionel B. (TRA)
> > Sent: Tuesday, July 26, 2016 7:06 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: PDSE V2 MaxGen Limit Query
> >
> > Is there a way to query the current MAXGENS_LIMIT from the SMS
> > configuration in either REXX or ISPF?
> >
> > I'm looking for a way to prevent a user from specifying a larger
> > maxgen than is allowed in a dialog I'm working on.
> >
> > Thanks
> >
> >
> > --
> >
> > Lionel B. Dyck (TRA Contractor)
> > Mainframe Systems Programmer
> > Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA
> > OI&T Service Delivery & Engineering
>
--
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: System symbols in batch JCL
>And, further, I ask myself, Why must the facility be controlled? >And I answer myself with a couple possible reasons: >o Some system symbols might have sensitive values (passwords? > the CIO's personal phone number?) which must be concealed. Can't be that one. The symbols and their values are in non-fetch-protected common storage. 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
Re: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
So we use OPS/MVS to capture the output from a D SMS,OPTIONS Command. That goes
into a dataset (uacc READ)
Then if needed, I can execio to the file and extract the data I need. Should
work for most users.
If you have automation, you can place the output into a file for later use
Lizette
PS I voted for your RFE, just wish I could vote more than once.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dyck, Lionel B. (TRA)
> Sent: Tuesday, July 26, 2016 8:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
>
> Liz - that works for a user with console command authority which does not
> apply to 99% of most users. Same for viewing sys1.parmlib. I've opened a RFE
> to IBM for a sysvar or mvsvar variable :-)
>
>
> --
> Lionel B. Dyck (TRA Contractor)
> Mainframe Systems Programmer
> Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T Service
> Delivery & Engineering
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Tuesday, July 26, 2016 9:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
>
> The D SMS,OPTIONS command will contain the maxgen limit in the display.
>
> So either an ISFEXEC for the MVS Command or going into OPER in REXX could
> work.
>
> Not sure if there is a control block you could parse through to get that info.
>
> CA_RECLAIM = {NONE | DATACLAS}
> PS_EXT_VERSION ={1|2}
> HONOR_DSNTYPE_PDSE = NO PDSE_VERSION = 1
> SUPPRESS_SMSMSG = IGD17054I(NO ) IGD17227I(NO ) IGD17395I(NO ) MAXGENS_LIMIT =
> maxgenlimit USER_ACSVAR = (value1,value2,value3) PDSE_PENDING_DELETE_INTERVAL
> =
>
> Of course this would be dependent on the level of z/OS Running. This display
> is from z/OS V2.2
>
> Lizette
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Dyck, Lionel B. (TRA)
> > Sent: Tuesday, July 26, 2016 7:06 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: PDSE V2 MaxGen Limit Query
> >
> > Is there a way to query the current MAXGENS_LIMIT from the SMS
> > configuration in either REXX or ISPF?
> >
> > I'm looking for a way to prevent a user from specifying a larger
> > maxgen than is allowed in a dialog I'm working on.
> >
> > Thanks
> >
> > --
> >
> > Lionel B. Dyck (TRA Contractor)
> > Mainframe Systems Programmer
> > Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T
> > Service Delivery & Engineering
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 since z/OS 2.1
>in 2.1, the low 8K is “PSA”, not just 4K. It has been 8K for z/Architecture, not since 2.1 >You can’t update it even if you are key zero. This is not correct for "8K" or "4K". Only a section of the PSA is subject to Low Address Protection which is what prevents modifications even from key 0. 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
Re: PDSE V2 MaxGen Limit Query
I had the same thought but haven't followed through (yet).
I needed another project :-)
--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI&T Service Delivery & Engineering
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jesse 1 Robinson
Sent: Tuesday, July 26, 2016 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
In the meantime you might write a routine--executed early in IPL--to set an
installation-defined symbolic. A command-parsing STC run SUB=MSTR should
execute before any user jobs that would make use of the symbolic. "Life is too
short to wait for RFEs."
We set a number of symbolics that are all prefixed with our SHARE code, pretty
much guaranteeing that they will never collide with IBM names.
.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Dyck, Lionel B. (TRA)
Sent: Tuesday, July 26, 2016 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
Liz - that works for a user with console command authority which does not apply
to 99% of most users. Same for viewing sys1.parmlib. I've opened a RFE to IBM
for a sysvar or mvsvar variable :-)
--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T Service
Delivery & Engineering
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Tuesday, July 26, 2016 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
The D SMS,OPTIONS command will contain the maxgen limit in the display.
So either an ISFEXEC for the MVS Command or going into OPER in REXX could work.
Not sure if there is a control block you could parse through to get that info.
CA_RECLAIM = {NONE | DATACLAS}
PS_EXT_VERSION ={1|2}
HONOR_DSNTYPE_PDSE = NO PDSE_VERSION = 1
SUPPRESS_SMSMSG = IGD17054I(NO ) IGD17227I(NO ) IGD17395I(NO ) MAXGENS_LIMIT =
maxgenlimit USER_ACSVAR = (value1,value2,value3) PDSE_PENDING_DELETE_INTERVAL =
Of course this would be dependent on the level of z/OS Running. This display
is from z/OS V2.2
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Dyck, Lionel B. (TRA)
> Sent: Tuesday, July 26, 2016 7:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: PDSE V2 MaxGen Limit Query
>
> Is there a way to query the current MAXGENS_LIMIT from the SMS
> configuration in either REXX or ISPF?
>
> I'm looking for a way to prevent a user from specifying a larger
> maxgen than is allowed in a dialog I'm working on.
>
> Thanks
>
> --
>
> Lionel B. Dyck (TRA Contractor)
> Mainframe Systems Programmer
> Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T
> Service Delivery & Engineering
--
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: PDSE V2 MaxGen Limit Query
In the meantime you might write a routine--executed early in IPL--to set an
installation-defined symbolic. A command-parsing STC run SUB=MSTR should
execute before any user jobs that would make use of the symbolic. "Life is too
short to wait for RFEs."
We set a number of symbolics that are all prefixed with our SHARE code, pretty
much guaranteeing that they will never collide with IBM names.
.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Dyck, Lionel B. (TRA)
Sent: Tuesday, July 26, 2016 8:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
Liz - that works for a user with console command authority which does not apply
to 99% of most users. Same for viewing sys1.parmlib. I've opened a RFE to IBM
for a sysvar or mvsvar variable :-)
--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T Service
Delivery & Engineering
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Tuesday, July 26, 2016 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
The D SMS,OPTIONS command will contain the maxgen limit in the display.
So either an ISFEXEC for the MVS Command or going into OPER in REXX could work.
Not sure if there is a control block you could parse through to get that info.
CA_RECLAIM = {NONE | DATACLAS}
PS_EXT_VERSION ={1|2}
HONOR_DSNTYPE_PDSE = NO PDSE_VERSION = 1
SUPPRESS_SMSMSG = IGD17054I(NO ) IGD17227I(NO ) IGD17395I(NO ) MAXGENS_LIMIT =
maxgenlimit USER_ACSVAR = (value1,value2,value3) PDSE_PENDING_DELETE_INTERVAL =
Of course this would be dependent on the level of z/OS Running. This display
is from z/OS V2.2
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Dyck, Lionel B. (TRA)
> Sent: Tuesday, July 26, 2016 7:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: PDSE V2 MaxGen Limit Query
>
> Is there a way to query the current MAXGENS_LIMIT from the SMS
> configuration in either REXX or ISPF?
>
> I'm looking for a way to prevent a user from specifying a larger
> maxgen than is allowed in a dialog I'm working on.
>
> Thanks
>
> --
>
> Lionel B. Dyck (TRA Contractor)
> Mainframe Systems Programmer
> Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T
> Service Delivery & Engineering
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' by...
.txt only attachments are permitted. Don't remember max lines. In a message dated 7/26/2016 6:14:47 A.M. Central Daylight Time, p...@gmx.ch writes: Does IBM-MAIN allow attachments? Can't remember, but will try. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
Liz - that works for a user with console command authority which does not apply
to 99% of most users. Same for viewing sys1.parmlib. I've opened a RFE to IBM
for a sysvar or mvsvar variable :-)
--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)
VA OI&T Service Delivery & Engineering
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Lizette Koehler
Sent: Tuesday, July 26, 2016 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: PDSE V2 MaxGen Limit Query
The D SMS,OPTIONS command will contain the maxgen limit in the display.
So either an ISFEXEC for the MVS Command or going into OPER in REXX could work.
Not sure if there is a control block you could parse through to get that info.
CA_RECLAIM = {NONE | DATACLAS}
PS_EXT_VERSION ={1|2}
HONOR_DSNTYPE_PDSE = NO PDSE_VERSION = 1
SUPPRESS_SMSMSG = IGD17054I(NO ) IGD17227I(NO ) IGD17395I(NO ) MAXGENS_LIMIT =
maxgenlimit USER_ACSVAR = (value1,value2,value3) PDSE_PENDING_DELETE_INTERVAL =
Of course this would be dependent on the level of z/OS Running. This display
is from z/OS V2.2
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Dyck, Lionel B. (TRA)
> Sent: Tuesday, July 26, 2016 7:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: PDSE V2 MaxGen Limit Query
>
> Is there a way to query the current MAXGENS_LIMIT from the SMS
> configuration in either REXX or ISPF?
>
> I'm looking for a way to prevent a user from specifying a larger
> maxgen than is allowed in a dialog I'm working on.
>
> Thanks
>
> --
>
> Lionel B. Dyck (TRA Contractor)
> Mainframe Systems Programmer
> Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T
> Service Delivery & Engineering
--
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: PDSE V2 MaxGen Limit Query
The D SMS,OPTIONS command will contain the maxgen limit in the display.
So either an ISFEXEC for the MVS Command or going into OPER in REXX could work.
Not sure if there is a control block you could parse through to get that info.
CA_RECLAIM = {NONE | DATACLAS}
PS_EXT_VERSION ={1|2}
HONOR_DSNTYPE_PDSE = NO PDSE_VERSION = 1
SUPPRESS_SMSMSG = IGD17054I(NO ) IGD17227I(NO ) IGD17395I(NO )
MAXGENS_LIMIT = maxgenlimit
USER_ACSVAR = (value1,value2,value3)
PDSE_PENDING_DELETE_INTERVAL =
Of course this would be dependent on the level of z/OS Running. This display is
from z/OS V2.2
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Dyck, Lionel B. (TRA)
> Sent: Tuesday, July 26, 2016 7:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: PDSE V2 MaxGen Limit Query
>
> Is there a way to query the current MAXGENS_LIMIT from the SMS configuration
> in either REXX or ISPF?
>
> I'm looking for a way to prevent a user from specifying a larger maxgen than
> is allowed in a dialog I'm working on.
>
> Thanks
>
> --
> Lionel B. Dyck (TRA Contractor)
> Mainframe Systems Programmer
> Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T Service
> Delivery & Engineering
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
I was once tasked with debugging a mysterious S0C4 in an old COBOL program. I set a SLIP for the failing job without specifying an abend code. Turned out that the original abend was a garden variety S0C7 that was mishandled by an ancient STAE routine, leading to a wild branch into some PLPA module. Sometimes omitting abend code can be quite illuminating. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Binyamin Dissen Sent: Tuesday, July 26, 2016 5:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes On Tue, 26 Jul 2016 14:29:06 +0200 Peter Hunkeler wrote: :> :>>It seems that you branched to a location that is fetch protected and not in :>>key 8. :>That would lead to a S0C4-4 not S0C4-11, wouldn't it? Program Unit: Entry: Statement: Offset: -01BE8FAE Machine State: ILC. 0002Interruption Code. 0004 :>>What do you expect to find at 231A7BB8? My guess is that the LE formatter is :>>showing all zeroes since it cannot access it. :>The storage is available, otherwise it would be marked as "inaccessible storage". I don't know what to expect at that address, it is not my application, I was merely asked if I could help debugging what seems to be a storage overlay problem. I don't know how LE plays that game. A SLIP of the 0C4 would have true contents. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
On 7/26/2016 7:20 AM, Peter Hunkeler wrote: Thanks, Ed, I wasn't aware of the *trailing* whilte space behaviour. However, I think apart from that Listserv removes all leading space (and multiple spaces?) and thus also makes reading the dump output difficult. It does nothing of the kind! I and many others have posted numerous code and dump fragments over the years. (As long as there is no trailing whitespace as per the email formatting RFC(s), all should be good.) Here is one I was looking at over the weekend. Tell me if it looks bad to you: SEARCH ARGUMENT ABSTRACT RIDS/EJESDJ3#L RIDS/EJESSUBS AB/S0DC2 PRCS/5C003F20 REGS/C3136 Symptom Description --- --- RIDS/EJESDJ3#L Load module name: EJESDJ3 RIDS/EJESSUBS Csect name: EJESSUBS AB/S0DC2System abend code: 0DC2 PRCS/5C003F20 Abend reason code: 5C003F20 REGS/C3136 Register/PSW difference for R0C:-3136 Time of Error Information PSW: 47045000 8000 018B77BA Instruction length: 02 Interrupt code: 000D Failing instruction text: 00181610 0A0D010E B24D001C Breaking event address: _0D176BA6 AR/GR 0-1/_8400 /_84DC2000 AR/GR 2-3/_ /_ AR/GR 4-5/_01DF9000 /_9EF2 AR/GR 6-7/_02697000 /0048_9EEF0001 AR/GR 8-9/_ /_7F2DA250 AR/GR 10-11 /_7F2D8000 /_0800 AR/GR 12-13 /_018BA8F0 /_01DFB178 AR/GR 14-15 /_01DFB000 /_5C003F20 Home ASID: 007CPrimary ASID: 007CSecondary ASID: 007C PKM: AX: EAX: 0002 This SRB'S PURGEDQ ASID/TCB: 007C/00AE12D0 RTM was entered because an SVC was issued in an improper mode. The error occurred while an SRB routine was in control. No locks were held. No super bits were set. RECOVERY ENVIRONMENT Recovery routine type: Functional Recovery Routine (FRR) PSW at entry to FRR: 470C 8D02E3F4 LSED address when FRR was established: 01F291B8 FRR parameter area on entry to FRR: +00 7F308100 NO DATA EXISTS IN THE VARIABLE RECORDING AREA IEA24013I FORMATTING COMPLETED SUCCESSFULLY. CPU STATUS: PSW=47045000 8000 018B77BA (Running in AR, key 0, AMODE 31, DAT ON, SUPERVISOR STATE) Enabled for PER I/O EXT MCH ASID(X'007C') 018B77BA. IEANUC01.IAXV6+079A IN READ ONLY NUCLEUS ASCB124 at FA2100, JOB(EDJX2), for the home ASID ASXB124 at AFD000 for the home ASID. No block is dispatched HOME ASID: 007C PRIMARY ASID: 007C SECONDARY ASID: 007C General purpose register values 0-1 _8400 _84DC2000 2-3 _ _ 4-5 _01DF9000 _9EF2 6-7 _02697000 0048_9EEF0001 8-9 _ _7F2DA250 10-11 _7F2D8000 _0800 12-13 _018BA8F0 _01DFB178 14-15 _01DFB000 _5C003F20 Access register values 0-3 4-7 8-11 12-15 Control register values 0-1 0082_DF8EE660 _E3950007 2-3 _1FFB9040 0001_007C 4-5 0001_007C _1F37DF00 6-7 _0200 _E3950007 8-9 _0002 _0400 10-11 _ _ 12-13 _9DC5AE4B _E3950007 14-15 _DF89F37B _01F292E0 -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>:>That would lead to a S0C4-4 not S0C4-11, wouldn't it? > >Program Unit: Entry: Statement: Offset: -01BE8FAE >Machine State: >ILC. 0002Interruption Code. 0004 Thanks. I was mislead by the fact the the failure was reported as S0C4 reason 11 in the joblog. Also LE as well as IPCS show the content of the memory at the address in R15 / PSW NSI, and this is key 8 storage. *But* the main purpose of my post was to under how the job can fail with a S0C4-xx when I can see the storage in the dump. The conclusion was (see previous thread) that the "little helpers" must have getmained and gotten storage that was not there (or not in key 8) at the time if the initial error. >I don't know how LE plays that game. A SLIP of the 0C4 would have true >contents. System Trace would also help with this information but it is not in the dump produced by the "little"helpers". Setting a SLIP in production is a not so short adventure trip; and SLIPping for a 0C4 is not trivial as long as I don't have more information what actually happens. I have asked that the job be changed to switch off the 'little helpers' and a SYSMDUMP DD be added. Hopefully I will have more information next time it fails. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
Thanks, Ed, I wasn't aware of the *trailing* whilte space behaviour. However, I think apart from that Listserv removes all leading space (and multiple spaces?) and thus also makes reading the dump output difficult. --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDSE V2 MaxGen Limit Query
Can't think of anything other than parsing the output of a D SMS,OPTIONS command. Regards, Leo -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dyck, Lionel B. (TRA) Sent: Tuesday, July 26, 2016 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PDSE V2 MaxGen Limit Query Is there a way to query the current MAXGENS_LIMIT from the SMS configuration in either REXX or ISPF? I'm looking for a way to prevent a user from specifying a larger maxgen than is allowed in a dialog I'm working on. Thanks -- Lionel B. Dyck (TRA Contractor) Mainframe Systems Programmer Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T Service Delivery & Engineering -- 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
RFE for a SYSVAR for PDSE V2 MAXGENS_LIMIT - please vote
Can I get y'all to consider voting for my RFE to provide a SYSVAR variable with the current MAXGENS_LIMIT value. The url is: https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=90635 -- Lionel B. Dyck (TRA Contractor) Mainframe Systems Programmer Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T Service Delivery & Engineering -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PDSE V2 MaxGen Limit Query
Is there a way to query the current MAXGENS_LIMIT from the SMS configuration in either REXX or ISPF? I'm looking for a way to prevent a user from specifying a larger maxgen than is allowed in a dialog I'm working on. Thanks -- Lionel B. Dyck (TRA Contractor) Mainframe Systems Programmer Enterprise Infrastructure Support (Station 200) (005OP6.3.10) VA OI&T Service Delivery & Engineering -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
On 7/26/2016 4:08 AM, Peter Hunkeler wrote: PS: If the data below is too much unreadable after going through the ListServ, I'd be happy to send it as attachement to anyone interested. *** CEEDUMP data folows: CEE3DMP V2 R1.0: Condition processing resulted in the unhandled condition. 07/15/16 12:12:28 AMASID: 0159 Job ID: J0274722 Job name: P07W04UA Step name: DB2RUN UserID: TWSP0A CEE3845I CEEDUMP Processing started. Information for enclave ZTVXXX00 Information for thread 8000 This ugly wrapping of textual information is standard email behavior (detailed in an RFC) and occurs because you posted information with trailing whitespace. You must remove ALL trailing whitespace before you paste the dump text into your email. I use UltraEdit under Windows 10. In that editor it's Alt+T+G to do this. I'm sure other PC editors do similar things. If all else fails, you should be able to save the text into a variable-length data set in ISPF and use FTP with ASCII transfer to copy to your workstation... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT DYNALLOC/DYNAPCT question
What I do for my very large DB2 SAS Processes is use the following //DFSPARM DD DISP=SHR,DSN=SYSS.DFSORT.CNTLLIB(DFSORT) In the DFSORT member I just have coded OPTION DYNALLOC=(,32) I have removed all SORTWKxx or variation (you may be using SASSWKxx) in the SAS Proc or MXG Proc. Now I just let DFSORT figure out what it needs. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Vernooij, CP (ITOPT1) - KLM > Sent: Monday, July 25, 2016 11:25 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFSORT DYNALLOC/DYNAPCT question > > Hi Dave, > > Thanks for the explanation. > We sometimes have problems with very large sorts from SAS 9.2, which known to > provide DFSORT with incorrect information about the amount of data to be > sorted. DFSORT then tries to recover from B37 abend which is mostly but not > always successful. > So I think I will raise DYNALLOC to 6 and also set DYNAPCT to 100, to help > DFSORT to handle large sorts that were provided with incorrect size info. > > Regards, > Kees. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of David Betten > Sent: 26 July, 2016 8:12 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFSORT DYNALLOC/DYNAPCT question > > The dynamic allocation space calculations are going to be based on the > DYNALLOC number. As a simple example, if DFSORT calculates that it needs > 6,000 cylinders of work space, and DYNALLOC=4 with DYNAPCT=50, it will need > 4 volumes with at least 1500 cylinders of free space. But with DYNALLOC=6 and > DYNAPCT=10, it will need 6 volumes with at least 1,000 cylinders of free > space. The work data sets allocated for DYNAPCT are not factored into the > initial work space allocation. Rather they are allocated with zero space and > only extended later on if the sort unexpectedly requires more space and the > initial DYNALLOC work data sets have been exhausted. So my suggestion would > be to increase DYNALLOC to 6. > > > > Have a nice day, > Dave Betten > z/OS Performance Specialist > Cloud and Systems Performance > IBM Corporation > email: bet...@us.ibm.com > > > IBM Mainframe Discussion List wrote on > 07/25/2016 04:30:16 AM: > > > From: "Vernooij, CP (ITOPT1) - KLM" > > To: IBM-MAIN@LISTSERV.UA.EDU > > Date: 07/25/2016 04:31 AM > > Subject: DFSORT DYNALLOC/DYNAPCT question Sent by: IBM Mainframe > > Discussion List > > > > Hello DFSORT experts, > > > > The DYNALLOC description says that the default number of SORTWKs is > > 4 and not to specify an unnecessary high number. > > The DYNAPCT parameter allocates an extra number of SORTWKs to be used > > in case the DYNALLOC number of SORTWKs appears to be not enough. > > > > I can: > > > > a. raise the DYNALLOC default to 6 SORTWKs > > > > b. set the DYNAPCT value to 50 > > In each case 6 SORTWKs are allocated. What is the difference and what > > is advisable? > > > > Kees. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
On Tue, 26 Jul 2016 14:29:06 +0200 Peter Hunkeler wrote: :> :>>It seems that you branched to a location that is fetch protected and not in :>>key 8. :>That would lead to a S0C4-4 not S0C4-11, wouldn't it? Program Unit: Entry: Statement: Offset: -01BE8FAE Machine State: ILC. 0002Interruption Code. 0004 :>>What do you expect to find at 231A7BB8? My guess is that the LE formatter is :>>showing all zeroes since it cannot access it. :>The storage is available, otherwise it would be marked as "inaccessible storage". I don't know what to expect at that address, it is not my application, I was merely asked if I could help debugging what seems to be a storage overlay problem. I don't know how LE plays that game. A SLIP of the 0C4 would have true contents. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>It seems that you branched to a location that is fetch protected and not in >key 8. That would lead to a S0C4-4 not S0C4-11, wouldn't it? >What do you expect to find at 231A7BB8? My guess is that the LE formatter is >showing all zeroes since it cannot access it. The storage is available, otherwise it would be marked as "inaccessible storage". I don't know what to expect at that address, it is not my application, I was merely asked if I could help debugging what seems to be a storage overlay problem. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
Peter Hunkeler wrote: >As expected, having the dump information inline did not work out. I'm >reposting with an attachement. Hopefully this will work better. I could see both attachments from IBM-MAIN web site. Thanks, it is working well including formatting too inside those attachments. Your first attempt was horrrible! ;-D 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: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
It seems that you branched to a location that is fetch protected and not in key 8. What do you expect to find at 231A7BB8? My guess is that the LE formatter is showing all zeroes since it cannot access it. On Tue, 26 Jul 2016 13:22:54 +0200 Peter Hunkeler wrote: :> :> :>As expected, having the dump information inline did not work out. I'm reposting with an attachement. Hopefully this will work better. :> :> :>In (late) response to Jim Mulder's comment: :> :> :>>How about the TRNE and BEA fields in that same XSB? :> :> :>and Tom Marchant's comment: :> :> :>>If you show the exact information from the dump, rather than your interpretation of that data, there is a better chance that someone will be able to see something that you didn't. :> :> :> :> :>I'm posting some raw information from the CEEDUMP as well as from IPCS. I have added a few lines of comment starting with "***". :> :>In the CEEDUMP part I have shortened the trace back list by deleting some intermediate call information (entries 6-13). :> :> :>I don't want to add an futher interpretation from me. If you still find some time to have a look and post whatever information you might find useful, I would very much appreciate. :> :> :> :>Thanks :>Peter :> :> -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
As expected, having the dump information inline did not work out. I'm reposting with an attachement. Hopefully this will work better. In (late) response to Jim Mulder's comment: >How about the TRNE and BEA fields in that same XSB? and Tom Marchant's comment: >If you show the exact information from the dump, rather than your >interpretation of that data, there is a better chance that someone will be >able to see something that you didn't. I'm posting some raw information from the CEEDUMP as well as from IPCS. I have added a few lines of comment starting with "***". In the CEEDUMP part I have shortened the trace back list by deleting some intermediate call information (entries 6-13). I don't want to add an futher interpretation from me. If you still find some time to have a look and post whatever information you might find useful, I would very much appreciate. Thanks Peter -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN *** CEEDUMP information follows * CEE3DMP V2 R1.0: Condition processing resulted in the unhandled condition. 07/15/16 12:12:28 AM ASID: 0159 Job ID: J0274722 Job name: P07W04UA Step name: DB2RUN UserID: TWSP0A CEE3845I CEEDUMP Processing started. Information for enclave ZTVXXX00 Information for thread 8000 Traceback: DSA Entry E Offset Statement Load Mod Program Unit Service Status 1 CEEHDSP +4A4C CEEPLPKA CEEHDSP UI90017 Call 2 -01BE8FAE HRDRFREA Exception 3 HRDRFREA+4396 HRDRFREA HRDRFREA Call 4 IGZCFCC +02FC IGZCPAC IGZCFCC UI19860 Call 5 HRDDBLNK+9C92 HRDDBLNK HRDDBLNK Call ... 14IGZCFCC +02FC IGZCPAC IGZCFCC UI19860 Call 15ZTVXXX00+0A10 ZTVXXX00 ZTVXXX00 Call DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile Attributes 1 23117AE0 08DA2B60 08DA2B60 +4A4C 20150130 CEL 2 0001 24D90B66 24D90B66 -01BE8FAE 3 231176E8 24D85D48 24D85D48 +4396 20130225 COBOL 4 231174F0 20EDB610 20EDB610 +02FC 20140722 LIBRARY 5 23117078 235F6400 235F6400 +9C92 20160624 COBOL ... 1423115258 20EDB610 20EDB610 +02FC 20140722 LIBRARY 1523115030 23100428 23100428 +0A10 20100129 COBOL Condition Information for Active Routines Condition Information for (DSA address 0001) CIB Address: 231181B0 Current Condition: CEE0198S The termination of a thread was signaled due to an unhandled condition. Original Condition: CEE3204S The system detected a protection exception (System Completion Code=0C4). Location: Program Unit: Entry: Statement: Offset: -01BE8FAE Machine State: ILC. 0002Interruption Code. 0004 PSW. 478D0400 A31A7BB8 GPR0. _24BD7528 GPR1. _DDF4 GPR2. _24D96690 GPR3. _0004 GPR4. _23145460 GPR5. _77FC GPR6. _0001 GPR7. _DC20 GPR8. _009B7028 GPR9. _24BD73A8 GPR10 _009B7008 GPR11 _009B7E88 GPR12 _24D90B40 GPR13 _0001 GPR14 _A4D90BE2 GPR15 _A31A7BB8 FPC.. FPR0. 4EE6ED27 D6668000FPR1. 487F FF00 FPR2. 4264 FPR3. FPR4. 40326E64 05A0FPR5. FPR6. FPR7. FPR8. FPR9. FPR10 FPR11 FPR12 FPR13 FPR14 FPR15 Storage dump near condition, beginning at location: 231A7BA8 +00 231A7BA8 || *** IPCS Data follows **
Re: Boulder and Rochester Servers
I could not get to that either, but to get HOLDDATA nightly, I normally use: public.dhe.ibm.com It worked four hours ago. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Field, Alan Sent: Monday, July 25, 2016 10:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Boulder and Rochester Servers Trying to download HOLDDATA. Same job I've used for years. GIM69195S ** RECEIVE PROCESSING HAS FAILED. THE SERVER AT https://eccgw01.boulder.ibm.com/service/projects/ecc/ws/ DETECTED AN ERROR: 404 - Not Found. Does IBM have a problem or did something change and I missed the notification? Alan Field Systems Engineer Principal Blue Cross Blue Shield of MN 651.662.3546 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you must not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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
DFSORT DYNALLOC/DYNAPCT question
OK, but you don't have to do it for everything. Most things aren't giving you a problem. Small files aren't the same issue as larger ones. Diversion between actual amount of data and estimated amount of data affects performance, not just workspace allocation. I'd ask IBM DFSORT to look at one of the big SAS processes and see what they can suggest. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
Oopps, I was afraid of that. Does IBM-MAIN allow attachements? Can't remember, but will try. -- Peter Hunkeler *** CEEDUMP data folows: CEE3DMP V2 R1.0: Condition processing resulted in the unhandled condition. 07/15/16 12:12:28 AMASID: 0159 Job ID: J0274722 Job name: P07W04UA Step name: DB2RUN UserID: TWSP0A CEE3845I CEEDUMP Processing started. Information for enclave ZTVXXX00 Information for thread 8000 Traceback:DSA Entry E Offset Statement Load Mod Program Unit Service Status1 CEEHDSP +4A4C CEEPLPKA CEEHDSPUI90017 Call 2 -01BE8FAE HRDRFREA Exception3 . -- Peter Hunkeler -- 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
AW: Re: AW: Re: AW: Re: S0C4-11 abend caused by BASSM to address with all X'00' bytes
>> It will be cleared to X'00' by MVS. > >YMMV on that... > >"When you obtain storage, the system clears the requested storage to >zeros if you obtain either: > >8192 bytes or more from a pageable, private storage subpool. >4096 bytes or more from a pageable, private storage subpool, >with BNDRY=PAGE specified. I stand corrected. Thanks for remembering me. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes
Warning, long post. In (late) response to Jim Mulder's comment: >How about the TRNE and BEA fields in that same XSB? and Tom Marchant's comment: >If you show the exact information from the dump, rather than your >interpretation of that data, there is a better chance that someone will be >able to see something that you didn't. I'm posting some raw information from the CEEDUMP as well as from IPCS. I have added a few lines of comment starting with "***". In the CEEDUMP part I have shortened the trace back list by deleting some intermediate call information (entries 6-13). I don't want to add an futher interpretation from me. If you still find some time to have a look and post whatever information you might find useful, I would very much appreciate. Thanks Peter PS: If the data below is too much unreadable after going through the ListServ, I'd be happy to send it as attachement to anyone interested. *** CEEDUMP data folows: CEE3DMP V2 R1.0: Condition processing resulted in the unhandled condition. 07/15/16 12:12:28 AMASID: 0159 Job ID: J0274722 Job name: P07W04UA Step name: DB2RUN UserID: TWSP0A CEE3845I CEEDUMP Processing started. Information for enclave ZTVXXX00 Information for thread 8000 Traceback:DSA Entry E Offset Statement Load Mod Program Unit Service Status1 CEEHDSP +4A4C CEEPLPKA CEEHDSPUI90017 Call 2 -01BE8FAE HRDRFREA Exception3 HRDRFREA+4396 HRDRFREA HRDRFREACall4 IGZCFCC +02FC IGZCPAC IGZCFCC UI19860 Call5 HRDDBLNK+9C92 HRDDBLNK HRDDBLNKCall...14IGZCFCC +02FC IGZCPAC IGZCFCC UI19860 Call15ZTVXXX00+0A10 ZTVXXX00 ZTVXXX00Call DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile Attributes1 23117AE0 08DA2B60 08DA2B60 +4A4C 20150130 CEL2 0001 24D90B66 24D90B66 -01BE8FAE 3 231176E8 24D85D48 24D85D48 +4396 20130225 COBOL4 231174F0 20EDB610 20EDB610 +02FC 20140722 LIBRARY5 23117078 235F6400 235F6400 +9C92 20160624 COBOL ...1423115258 20EDB610 20EDB610 +02FC 20140722 LIBRARY 1523115030 23100428 23100428 +0A10 20100129 COBOL Condition Information for Active RoutinesCondition Information for (DSA address 0001) CIB Address: 231181B0 Current Condition: CEE0198S The termination of a thread was signaled due to an unhandled condition. Original Condition:CEE3204S The system detected a protection exception (System Completion Code=0C4). Location: Program Unit: Entry: Statement: Offset: -01BE8FAE Machine State: ILC. 0002Interruption Code. 0004PSW. 478D0400 A31A7BB8 GPR0. _24BD7528 GPR1. _DDF4 GPR2. _24D96690 GPR3. _0004GPR4. _23145460 GPR5. _77FC GPR6. _0001 GPR7. _DC20GPR8. _009B7028 GPR9. _24BD73A8 GPR10 _009B7008 GPR11 _009B7E88 GPR12 _24D90B40 GPR13 _0001 GPR14 _A4D90BE2 GPR15 _A31A7BB8 FPC.. FPR0. 4EE6ED27 D6668000FPR1. 487F FF00 FPR2. 4264 FPR3. FPR4. 40326E64 05A0FPR5. FPR6. FPR7. FPR8. FPR9. FPR10 FPR11 FPR12 FPR13 FPR14 FPR15 Storage dump near condition, beginning at location: 231A7BA8 +00 231A7BA8 || ** IPCS Data follows ** SELECTED BY: CURRENTJOBNAME P07W04UA ASCB 00F63B80 NEXT 00F5FE80 PREV 00F62880 ASID 0159 TCB 009FDD40 NEXT 009FD040 PREV COMP TCB 009FD040 NEXT 009FF6C8 PREV 009FDD40 COMP TCB 009FF6C8 NEXT 009F8680 PREV 009FD0
Re: DFSORT DYNALLOC/DYNAPCT question
I see your point, but this is unachievable. We have thousands of SAS jobs, lots of them existing of complex SAS programs, doing multiple PROC SORTs, sorting data that varies in size over the jobs and days depending on how much data must be processed. One central setting to help DFSORT recover from incorrect info more often than it does now, is simpler. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Woodger Sent: 26 July, 2016 11:31 To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFSORT DYNALLOC/DYNAPCT question Which is why I'm suggesting providing additional information on the DFSPARM DD. Because if DFSORT is not reading the data, it doesn't know so much. You can fill in some gaps for it. Allowing DFSORT to do the allocations better is probably an advantage over allowing DFSORT to complete allocations however they are specified. -- 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
DFSORT DYNALLOC/DYNAPCT question
Which is why I'm suggesting providing additional information on the DFSPARM DD. Because if DFSORT is not reading the data, it doesn't know so much. You can fill in some gaps for it. Allowing DFSORT to do the allocations better is probably an advantage over allowing DFSORT to complete allocations however they are specified. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSORT DYNALLOC/DYNAPCT question
The problem is not that SAS does not provide DFSORT with info about the data to be sorted, it provides DFSORT with incorrect info. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Bill Woodger Sent: 26 July, 2016 11:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFSORT DYNALLOC/DYNAPCT question You could look at using DFSPARM in your SAS steps, https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.icea100/dfsparm.htm When invoked from another program, and when that other program is reading/providing the data to DFSORT, you can help DFSORT out by providing things like an estimate of the number of records to expect, average record-length. Look at the sysout from any failures you can still locate and see if there are any indicative messages. This doesn't just apply to SAS, but to all programmatic invocations of DFSORT. Performance and stability can be improved through the appropriate use of DFSPARM. You can contact DFSORT directly (Kolusu posts the email address from time to time) if you have such issues and want expert advice. It is good to see things here, as it spreads information around, but I suspect the direct approach is quicker for immediate issues. -- 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
DFSORT DYNALLOC/DYNAPCT question
You could look at using DFSPARM in your SAS steps, https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.icea100/dfsparm.htm When invoked from another program, and when that other program is reading/providing the data to DFSORT, you can help DFSORT out by providing things like an estimate of the number of records to expect, average record-length. Look at the sysout from any failures you can still locate and see if there are any indicative messages. This doesn't just apply to SAS, but to all programmatic invocations of DFSORT. Performance and stability can be improved through the appropriate use of DFSPARM. You can contact DFSORT directly (Kolusu posts the email address from time to time) if you have such issues and want expert advice. It is good to see things here, as it spreads information around, but I suspect the direct approach is quicker for immediate issues. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
