Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainframe - Forbes
Paul Gilmartin wrote: (We need a new group, alt.ibm-main.nostalgia, or the like.) and Tony's Outlook via Mozilla wrote: We've got one, it's called IBM-MAIN, :-) My oh my! ;-) That famous list contains: OT, nostalgia, OT, trivia, OT, discussion about any computers except mainframes, flaming bickering amongst members, jokes, puns, ads, more and more OT, etc. Uhmmm, I think I should perhaps add 'mainframe (including z/OS) discussions', just to be fair... ;-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: DB2 V11 STCK
On Mon, 30 Mar 2015 12:09:17 +0200, Arie Kremer wrote: 2015-03-24 14:34:27.567264 - STCK converted to the local time 2015-03-24 14:53:31.792324 - the value of TIMESTAMP column set to CURRENT TIMESTAMP Which is correct according to a good wristwatch or smartphone? What does the TIME macro return? (LOCAL and GMT) What does STCK followed by STCKCONF return (what time zone are you in?) Is it possible that your (E)TOD clock is running unregulated but an operator has compensated with a command that adjusts CVTLDTO but does not adjust the (E)TOD clocl? What are the contents (hex) of CVTLDTO and CVTLSO? Does DB2 have its own internal time offset? (I should hope not.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Hallo All, I noticed in the HSM startup the following error messages: ARC0037I DFSMSHSM PROBLEM DETERMINATION OUTPUT DATA 679 ARC0037I (CONT.) SETS SWITCHED, ARCPDOX=HSM.HSMPDOXC, ARC0037I (CONT.) ARCPDOY=HSM.HSMPDOYC IEC145I 413-04,IFG0194A,DFHSMC,DFHSMC,ARCPDOX,8612,SYS226, HSM.HSMPDOXC ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM 682 ARC0036E (CONT.) DETERMINATION OUTPUT DATA SET, REAS= 3 I checked the error message for ARC0036E and it says the following : A failure occurred while attempting to open the ARCPDOX data set It doesn't tell me very much. I noticed that the dsn is at 16 extents. Could this be the cause of the problem? If so, I will have to enlargen both PDA dsns. Could someone shed some light on this? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...
On Mon, Mar 30, 2015 at 8:07 AM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On Mon, 30 Mar 2015 06:54:57 -0500, John McKown wrote: To me, one of the biggest pluses is the hardware memory key. As now used by z/OS, it really helps with reliability because, properly used, it enforces separation of authority (ability to write) by major OS subsystem. E.g. JES2 code can't step on VTAM memory in common storage. Certainly an effective accommodation to the single address space limitation of its time. but consider the gyrations the TSO TMP performs to run a mixture of privileged and unprivileged tasks in a single address space. (It might be better if all authorized programs had the discipline to obtain storage only in system key and unauthorized were restricted to user key, and if instead of JSCBAUTH there were a similar flag, but with TCB rather than job step scope so subtasks could be dispatched in suitable PSW keys. Alas, no one anticipated,) Well, with APF code, you could create a new JSCB to be used with the ATTACHX macro. The new JSCB would be associated with the new TCB and have the JSCBAUTH bit OFF. Unfortunately, this still has a security hole due to the fact that the APF code and the non-APF code are running in the same address space and likely both going to be running in key 8. And so the unauthorized code could possibly corrupt (perhaps maliciously) the memory of the APF code, causing it to do bad things. This is one main reason why I prefer the UNIX fork() philosophy rather than threading. At least when the other code is not under my personal control. Too bad that creating a new z/OS address space is so expensive compared to something like Linux. Of course, one reason is due to the fact that a z/OS address space has a lot of system level TCBs set up inside it before the user code is even looked at. Which explains the use of the BPXAS UNIX initiator address spaces. Nowadays, isn't segment protection with multiple address spaces a better approach? That doesn't protect memory in COMMON storage such as ECSA. It is significantly better than MVT's use of different keys 1..15 to separate memory for regions in real memory. Of course, IBM has done some really good things to reduce use of COMMON storage, such as dual address space, and especially AR mode. But I still like the isolation of protect keys. Maybe I'm just old fashioned in this regard . -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...
On Mon, 30 Mar 2015 06:54:57 -0500, John McKown wrote: On Mon, Mar 30, 2015 at 4:36 AM, Ed Finnell wrote: Good, bad or indifferent IBM-Main is coming up on 29 yrs( in June). Only 29? I thought OS/MVT/ASP, the focus of the drift, was quite obsolescent 29 years ago. Let's all thank Mark Post for supplying interesting, relevant, timely information. Be interesting to see a survey of biggest advances, or biggest blunders since we started. Channeling gil: EBCDIC! The classic: http://www.bobbemer.com/P-BIT.HTM (I wonder who has been maintaining the site for the last 11 years?) To me, one of the biggest pluses is the hardware memory key. As now used by z/OS, it really helps with reliability because, properly used, it enforces separation of authority (ability to write) by major OS subsystem. E.g. JES2 code can't step on VTAM memory in common storage. Certainly an effective accommodation to the single address space limitation of its time. but consider the gyrations the TSO TMP performs to run a mixture of privileged and unprivileged tasks in a single address space. (It might be better if all authorized programs had the discipline to obtain storage only in system key and unauthorized were restricted to user key, and if instead of JSCBAUTH there were a similar flag, but with TCB rather than job step scope so subtasks could be dispatched in suitable PSW keys. Alas, no one anticipated,) Nowadays, isn't segment protection with multiple address spaces a better approach? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DB2 V11 STCK
Many thanks Paul for the fast reply. As I wrote, this z/OS and DB2 V11 instance was generated for my playing with IFI :), and so the timing was probably not configured correct. So, the only thing I must have known is: whether in a real production DB2 instance this situation may have happened. In any case, the TIMESTAMP column contains the correct local time, exactly as the time printed on the operator console, and this is the TIME return. STCK in the Log Structure is UTC of course, and I converted it to the local time to compare. Unregulated (E)TOD may be the interesting direction... Btw, I have another question I tried to use WQALMODL request (LRSN DELTA) of IFI 306. I understand that without the Data Sharing this request has no sense. In any case, wanted to see what will happen. IFI returned an undocumented reason 00E60877. Is it correct? What this reason means? Best Regards and Many Thanks Arie Kremer On Mon, Mar 30, 2015 at 2:38 PM, Paul Gilmartin 000433f07816-dmarc-requ...@listserv.ua.edu wrote: On Mon, 30 Mar 2015 12:09:17 +0200, Arie Kremer wrote: 2015-03-24 14:34:27.567264 - STCK converted to the local time 2015-03-24 14:53:31.792324 - the value of TIMESTAMP column set to CURRENT TIMESTAMP Which is correct according to a good wristwatch or smartphone? What does the TIME macro return? (LOCAL and GMT) What does STCK followed by STCKCONF return (what time zone are you in?) Is it possible that your (E)TOD clock is running unregulated but an operator has compensated with a command that adjusts CVTLDTO but does not adjust the (E)TOD clocl? What are the contents (hex) of CVTLDTO and CVTLSO? Does DB2 have its own internal time offset? (I should hope not.) -- 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: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainframe - Forbes
EE, you made me laugh out loud this morning. For the record let's add PDSE jihads, semantics jousting, SMPE rules of engagement, what constitutes an empty file sparring, and revision of revisionist history revision. On 3/30/2015 3:00 AM, Elardus Engelbrecht wrote: Paul Gilmartin wrote: (We need a new group, alt.ibm-main.nostalgia, or the like.) and Tony's Outlook via Mozilla wrote: We've got one, it's called IBM-MAIN, :-) My oh my! ;-) That famous list contains: OT, nostalgia, OT, trivia, OT, discussion about any computers except mainframes, flaming bickering amongst members, jokes, puns, ads, more and more OT, etc. Uhmmm, I think I should perhaps add 'mainframe (including z/OS) discussions', just to be fair... ;-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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...
On Mon, 30 Mar 2015 08:07:02 -0500, Paul Gilmartin paulgboul...@aim.com wrote: To me, one of the biggest pluses is the hardware memory key. As now used by z/OS, it really helps with reliability because, properly used, it enforces separation of authority (ability to write) by major OS subsystem. E.g. JES2 code can't step on VTAM memory in common storage. Certainly an effective accommodation to the single address space limitation of its time. but consider the gyrations the TSO TMP performs to run a mixture of privileged and unprivileged tasks in a single address space. (It might be better if all authorized programs had the discipline to obtain storage only in system key and unauthorized were restricted to user key, and if instead of JSCBAUTH there were a similar flag, but with TCB rather than job step scope so subtasks could be dispatched in suitable PSW keys. Alas, no one anticipated,) Nowadays, isn't segment protection with multiple address spaces a better approach? Yes, but only to a certain extent as different address spaces still have some common areas. Moreover application servers ( CICS, WAS ) running transactions on behalf of multiple users in the same address space are conceptually not that different from MVT. Mohammad -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Lizette, I checked last week's STC there is no record of the logs being swapped. I stumbled on some procedures and the first last step in it is to do a HSEND SETSYS PDA(ON) and the last step is to do a HSEND SETSYS PDA(OFF) I assume that the PDA is set to OFF when the STC starts up. The dsns are written on DASD. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
The problem is the S413-04 abend. Basically this says that there is a problem opening with HSM.HSMPDOCX. In particular not all volumes can be mounted. What volume is this DSN catalogued on? Is that volume on-line to your system? We had a similar problem when some accidentally did a VARY ,OFFLINE and the volume was 'PENDING OFFLINE' in the D U display. A simple VARY ,ONLINE fixed the problem for us. Hopefully it is as simple for you. On Mon, Mar 30, 2015 at 8:15 AM, willie bunter 001409bd2345-dmarc-requ...@listserv.ua.edu wrote: Hallo All, I noticed in the HSM startup the following error messages: ARC0037I DFSMSHSM PROBLEM DETERMINATION OUTPUT DATA 679 ARC0037I (CONT.) SETS SWITCHED, ARCPDOX=HSM.HSMPDOXC, ARC0037I (CONT.) ARCPDOY=HSM.HSMPDOYC IEC145I 413-04,IFG0194A,DFHSMC,DFHSMC,ARCPDOX,8612,SYS226, HSM.HSMPDOXC ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM 682 ARC0036E (CONT.) DETERMINATION OUTPUT DATA SET, REAS= 3 I checked the error message for ARC0036E and it says the following : A failure occurred while attempting to open the ARCPDOX data set It doesn't tell me very much. I noticed that the dsn is at 16 extents. Could this be the cause of the problem? If so, I will have to enlargen both PDA dsns. Could someone shed some light on this? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainframe - Forbes
And then there is the topic/subject Hijack... Pulling from history, I got assigned to work on a Univac/Varian/DEC project to support the Space shuttle over at the Goddard Space Flight Center for NASA Ultimately required that I put some diodes together with some resistors... Got the 16bit DEC to talk with the 36bit Univac Finally had to write two different checkout compilers. Meanwhile they had a S/360-195 Yeah, right. On 03/30/2015 09:21 AM, Tony's Outlook via Mozilla wrote: EE, you made me laugh out loud this morning. For the record let's add PDSE jihads, semantics jousting, SMPE rules of engagement, what constitutes an empty file sparring, and revision of revisionist history revision. On 3/30/2015 3:00 AM, Elardus Engelbrecht wrote: Paul Gilmartin wrote: SNIPPAGE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Lizette, Sorry I forgot to answer the question about the size of the dsns. This is what it is at: Organization . . . : PS Current Utilization Record format . . . : VB Used cylinders . . : 158 Record length . . . : 1024Used extents . . . : 16 Block size . . . . : 27652 1st extent cylinders: 128 Secondary cylinders : 2 Dates -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Our site have been running into this problem for months. You can only have 2 *.HSMPDO* datasets on one volume. When one fills ups, HSM switches datasets (via a rename) and a task is submitted to write out the full one to *.PDA GDG PS dataset. If one dataset fills up before the other one is emptied, the writing to the HSMPDO datasets is stopped and you get this list of messages. The only solution is to increase the size of the HSMPDO datasets until you don't get this message any more. Suggested sizing per IBM manual is 1-3 hours of output per HSMPDO. The problem comes during migration periods where it is filling and swapping every few minutes until it completes. On Mon, Mar 30, 2015 at 8:15 AM, willie bunter 001409bd2345-dmarc-requ...@listserv.ua.edu wrote: Hallo All, I noticed in the HSM startup the following error messages: ARC0037I DFSMSHSM PROBLEM DETERMINATION OUTPUT DATA 679 ARC0037I (CONT.) SETS SWITCHED, ARCPDOX=HSM.HSMPDOXC, ARC0037I (CONT.) ARCPDOY=HSM.HSMPDOYC IEC145I 413-04,IFG0194A,DFHSMC,DFHSMC,ARCPDOX,8612,SYS226, HSM.HSMPDOXC ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM 682 ARC0036E (CONT.) DETERMINATION OUTPUT DATA SET, REAS= 3 I checked the error message for ARC0036E and it says the following : A failure occurred while attempting to open the ARCPDOX data set It doesn't tell me very much. I noticed that the dsn is at 16 extents. Could this be the cause of the problem? If so, I will have to enlargen both PDA dsns. Could someone shed some light on this? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainframe - Forbes
In 20150329212721.GB25599@dlc-dt, on 03/29/2015 at 05:27 PM, David L. Craig dlc@gmail.com said: Schmuel That's Shmuel. And don't forget Tom Kern. are any neurons being triggered Giss could only run VM on the 470V/6; when they shipped that to GMSF at GSFC, they were left running a single instance of SSS, albeit on a very fast machine. GISS submitted jobs to us (GMSF) over the telephone, and was racking up a sizable telephone bill. They asked us whether we could support a tie line[1], which would cost less than the long distance charges. We told them that it looks like any other dial connection, so we wouldn't neeed to change a thing. Comes the day, a technician from CP]2] wants to know where to install the 208-A[3[6]]. You mean 208-B[4]. No, 208-A. It seems that some smart feller in procurement had asked GISS wheat numbers they would be calling, and when he heard that it was always the same number he changed the PO to a lease line, but couldn't be bothered to ask whether it would actually work[5]. Fortunately we had a spare lease line adaptor on our Memorex 1270[6], but I was still ready to burn the procurement monkey at the stake. [1] A fixed long distant connection to a remote local office. Calls are billed based on teir relationship to the remote end. [2] Now part of Verizon (ptui!). [3] 4800 bps synchronous 4-wire modem for leased line. [4] 4800 bps synchronous 2-wire modem for dialup. [5] Not with a dialup adapter, it wouldn't. [6] There's another 208-A story for another day. Tom probably remembers it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
I verified the volumes are ONLINE for the PDA dsns. Something also very strange. I was under the impression that the HSM.HSMPDOXC the HSM.HSMPDOYC were never re-allocated and were reused everytime HSM STC was started up. For some reason I noticed that the dsns were on different volumes the week previous. I will have to check the SMF records to fine the reson. Do both the HSM.HSMPDOXC HSM.HSMPDOyC have to reside on the same volume? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...
In 39bc7.33e0233e.424a7...@aol.com, on 03/30/2015 at 05:36 AM, Ed Finnell 000248cce9f3-dmarc-requ...@listserv.ua.edu said: Be interesting to see a survey of biggest advances, or biggest blunders since we started. Sometimes they're the same, e.g., Project Stretch may have been the most profitable failure IBM ever had. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Yes. From the Fine Manual: DFSMShsm Implementation and Customization Guide Version 2 Release 1 PP 41-42_ SC23-6869-01 (z/OS 2.1) quote Storage guidance: Both the ARCPDOX and ARCPDOY data sets must be on the same volume. The amount and type of storage you use for your PDA log data sets depends on how much trace history you want to keep. To determine the amount and type of storage, you can use either the short-term work sheet found in “Problem determination aid log data set size work sheet—Short-term trace history” on page 388 or the long-term work sheet found in “Problem determination aid log data set size work sheet—Long-term trace history” on page 390. /quote I doubt this is a new requirement. It has most likely been there for eons… snip Do both the HSM.HSMPDOXC HSM.HSMPDOyC have to reside on the same volume? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Willie, How often do you swap PDA and LOGs for HSM. You should have a process that will offload them when a B37 occurs. Is this DASD or TAPE datasets? If DASD, what is the size/space used? Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Monday, March 30, 2015 6:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM Hallo All, I noticed in the HSM startup the following error messages: ARC0037I DFSMSHSM PROBLEM DETERMINATION OUTPUT DATA 679 ARC0037I (CONT.) SETS SWITCHED, ARCPDOX=HSM.HSMPDOXC, ARC0037I (CONT.) ARCPDOY=HSM.HSMPDOYC IEC145I 413-04,IFG0194A,DFHSMC,DFHSMC,ARCPDOX,8612,SYS226, HSM.HSMPDOXC ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM 682 ARC0036E (CONT.) DETERMINATION OUTPUT DATA SET, REAS= 3 I checked the error message for ARC0036E and it says the following : A failure occurred while attempting to open the ARCPDOX data set It doesn't tell me very much. I noticed that the dsn is at 16 extents. Could this be the cause of the problem? If so, I will have to enlargen both PDA dsns. Could someone shed some light on this? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: GPMSERVE - Trace Option
Jake, IIRC trace is off by default at startup. Additionally, in my GPMSERVE proc SYSPRINT and SYSOUT are set to dummy and GPMSRV00 I set DEBUG_LEVEL(0). Christian -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Jake Anderson Gesendet: Montag, 30. März 2015 13:24 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: GPMSERVE - Trace Option Hello, Can we permanently disable the Trace option instead of F GPMSERVE,TRACEOFF ? I am not finding any clue in the manual to do the permanent TRACEOFF. Any suggestion or advise ? Jake -- 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: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Willie - Do you have automation in place so that when the PDA gets a D37 it swaps the log? http://www-01.ibm.com/support/docview.wss?uid=isg3T1012687 IEC031I D37-04,IFG0554P,HSM,HSM,ARCPDOX,3099,HSMP05,MYHSM.LPAR7.HSMPDOX OPS1181O HSM OPSS (*Local*) MVS N/A MESSAGE.ARC0037I START OPSSJOB,N=PDALPAR7 START OPSSJOB,N=PDALPAR7 ARC0037I HSM PROBLEM DETERMINATION OUTPUT DATA 968 ARC0037I (CONT.) SETS SWITCHED, ARCPDOX=MYHSM.LPAR7.HSMPDOX, ARC0037I (CONT.) ARCPDOY=MYHSM.LPAR7.HSMPDOY Mine at 1500 cylinders each Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Willie Bunter Sent: Monday, March 30, 2015 7:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM Lizette, I checked last week's STC there is no record of the logs being swapped. I stumbled on some procedures and the first last step in it is to do a HSEND SETSYS PDA(ON) and the last step is to do a HSEND SETSYS PDA(OFF) I assume that the PDA is set to OFF when the STC starts up. The dsns are written on DASD. -- 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: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...
In caajsdjhwaswhnq89sqoebd5bny1eccsiqrizzyyfg1rgkz3...@mail.gmail.com, on 03/30/2015 at 06:54 AM, John McKown john.archie.mck...@gmail.com said: To me, one of the biggest pluses is the hardware memory key. Better than nothing, and available before S/360 supported virtual memory, but inferior to other mechanisms. I'll take segment/ring-based protection any day. Even block relocation is arguably better. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
GPMSERVE - Trace Option
Hello, Can we permanently disable the Trace option instead of F GPMSERVE,TRACEOFF ? I am not finding any clue in the manual to do the permanent TRACEOFF. Any suggestion or advise ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainfra...
On Mon, Mar 30, 2015 at 4:36 AM, Ed Finnell 000248cce9f3-dmarc-requ...@listserv.ua.edu wrote: Good, bad or indifferent IBM-Main is coming up on 29 yrs( in June). Be interesting to see a survey of biggest advances, or biggest blunders since we started. Channeling gil: EBCDIC! To me, one of the biggest pluses is the hardware memory key. As now used by z/OS, it really helps with reliability because, properly used, it enforces separation of authority (ability to write) by major OS subsystem. E.g. JES2 code can't step on VTAM memory in common storage. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outstanding DAF S0C4's
Michael, Any update to your update plans? _ Dave Jousma Assistant Vice President, Mainframe Engineering david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Michael Cleary Sent: Saturday, February 28, 2015 11:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Outstanding DAF S0C4's Greetings, I am working on an update to DAF and want to correct this issue. 1) What level of DAF are you running? 2) Does it always S0C4 or is it intermittent ? Any patterns? 3) Can you send me the entire job output from the S0C4, excluding the dump. Thanks... Michael Cleary -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Allan, No, they both do not reside on the same volume. I think someone moved the dsns to different volumes. I will check the SMF records to find out more details. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Non sequitur cartoon that applies to us.
http://www.arcamax.com/thefunnies/nonsequitur/s-1630199 This reminds me of some of our discussions on the list. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Lizette, I scanned through the whole output but there was no IEC031I D37-04. However I remember in the past seeing those messages especially when I was migrating volumes. Unfortunately the STC output is only available for the past 2 startups and both do not have the IEC031I D37-04 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Additional Information: The HSMPDO datasets are expected to be re-used by DFhsm. The HSMPDOX/Y datasets are toggled as needed. I would allocate them a some specific size w/no secondary extents. When HSMPDOX is filled, HSM will automatically switch to HSMPDOY. When HSMPDOY is filled, HSM will automatically switch back to HSMPDOX. HTH, From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Monday, March 30, 2015 9:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM Yes. From the Fine Manual: DFSMShsm Implementation and Customization Guide Version 2 Release 1 PP 41-42_ SC23-6869-01 (z/OS 2.1) quote Storage guidance: Both the ARCPDOX and ARCPDOY data sets must be on the same volume. The amount and type of storage you use for your PDA log data sets depends on how much trace history you want to keep. To determine the amount and type of storage, you can use either the short-term work sheet found in “Problem determination aid log data set size work sheet—Short-term trace history” on page 388 or the long-term work sheet found in “Problem determination aid log data set size work sheet—Long-term trace history” on page 390. /quote I doubt this is a new requirement. It has most likely been there for eons… snip Do both the HSM.HSMPDOXC HSM.HSMPDOyC have to reside on the same volume? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Alan, Thanks for the tip. I will reallocate the dsns on the same volume with a larger space. Thanks for the tip. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Non sequitur cartoon that applies to us.
And in color: http://assets.amuniversal.com/cdddeb80b4a70132d1fb005056a9545d Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, March 30, 2015 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Non sequitur cartoon that applies to us. http://www.arcamax.com/thefunnies/nonsequitur/s-1630199 This reminds me of some of our discussions on the list. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- 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: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainframe - Forbes
JES2 was a half ASP project. --- dlc@gmail.com wrote: From: David L. Craig dlc@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainframe - Forbes Date: Mon, 30 Mar 2015 11:38:59 -0400 On 15Mar29:1833-0400, David L. Craig wrote: It's interesting to see how it's been marked up to note the differences since the application was migrated to the 3081 running MVS. Nancy is Nancy L. Palm who is the sysprog I'm trying to track down. It's unclear to me from the listings if it's ASP or HASP--whatever it was was highly modded, IIRC. ;-) Nancy (now Assistant Chief) confirmed the 91 did not use ASP. So I was wrong. Where's my ceremonial sword? Hopefully I won't get that wrong. ;-) -- not cent from sell May the LORD God bless you exceedingly abundantly! Dave_Craig__ So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe. __--from_Nightfall_by_Asimov/Silverberg_ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainframe - Forbes
On 15Mar29:1833-0400, David L. Craig wrote: It's interesting to see how it's been marked up to note the differences since the application was migrated to the 3081 running MVS. Nancy is Nancy L. Palm who is the sysprog I'm trying to track down. It's unclear to me from the listings if it's ASP or HASP--whatever it was was highly modded, IIRC. ;-) Nancy (now Assistant Chief) confirmed the 91 did not use ASP. So I was wrong. Where's my ceremonial sword? Hopefully I won't get that wrong. ;-) -- not cent from sell May the LORD God bless you exceedingly abundantly! Dave_Craig__ So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe. __--from_Nightfall_by_Asimov/Silverberg_ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Non sequitur cartoon that applies to us.
Love it, dude On Monday, March 30, 2015, Nims,Alva John (Al) ajn...@ufl.edu wrote: And in color: http://assets.amuniversal.com/cdddeb80b4a70132d1fb005056a9545d Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU javascript:;] On Behalf Of John McKown Sent: Monday, March 30, 2015 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU javascript:; Subject: Non sequitur cartoon that applies to us. http://www.arcamax.com/thefunnies/nonsequitur/s-1630199 This reminds me of some of our discussions on the list. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; 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: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainframe - Forbes
Hey David, Nobody's perfect dude On Monday, March 30, 2015, Richard Pinion rpin...@netscape.com wrote: JES2 was a half ASP project. --- dlc@gmail.com javascript:; wrote: From: David L. Craig dlc@gmail.com javascript:; To: IBM-MAIN@LISTSERV.UA.EDU javascript:; Subject: Re: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainframe - Forbes Date: Mon, 30 Mar 2015 11:38:59 -0400 On 15Mar29:1833-0400, David L. Craig wrote: It's interesting to see how it's been marked up to note the differences since the application was migrated to the 3081 running MVS. Nancy is Nancy L. Palm who is the sysprog I'm trying to track down. It's unclear to me from the listings if it's ASP or HASP--whatever it was was highly modded, IIRC. ;-) Nancy (now Assistant Chief) confirmed the 91 did not use ASP. So I was wrong. Where's my ceremonial sword? Hopefully I won't get that wrong. ;-) -- not cent from sell May the LORD God bless you exceedingly abundantly! Dave_Craig__ So the universe is not quite as you thought it was. You'd better rearrange your beliefs, then. Because you certainly can't rearrange the universe. __--from_Nightfall_by_Asimov/Silverberg_ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; with the message: INFO IBM-MAIN _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu javascript:; 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: Structure resizing for CICS LOG lostreams
Eileen, Not what the CICS sysprog wanted, I guess. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen Sent: Monday, March 30, 2015 12:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Structure resizing for CICS LOG lostreams If you have so many CICS logs, why not use DASDONLY for the logs instead of the coupling facility? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Monday, March 30, 2015 12:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Structure resizing for CICS LOG lostreams I have a coworker that wants to increase the LOGSNUM value of the structure defined for numerous CICS DFHLOG logstreams. Can this be done dynamically and will we have to make sure that all regions are down and delete/define with the larger value. I have tried RTFM but it was not intuitively obvious. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Structure resizing for CICS LOG lostreams
From what I can see, the entire log stream structure would have to be deleted and redefined in order to increase LOGSNUM. According to this from z/os, it looks like the log streams would have to be disconnected in order to update LOGSNUM. But CICS TS 5.1 will not let you disconnect the main journal DFHLOG. And I do not even see any option in IXGINVNT (Z/OS 1.13) to update LOGSNUM. REQUEST=UPDATE option of IXGINVNT z/OS MVS Programming: Assembler Services Reference IAR-XCT SA22-7607-17 The IXGINVNT macro with the UPDATE parameter allows a program to update a log stream entry in the LOGR policy for a coupling facility or DASD-only log stream. Except for the RETPD and AUTODELETE parameters, note that you cannot update a log stream while there are active connections to it. And this from CICS DOC: 2.You cannot update AVGBUFSIZE, like other structure definition attributes such as MAXBUFSIZE and LOGSNUM, unless you first delete the log streams in the structure definition. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Monday, March 30, 2015 12:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Structure resizing for CICS LOG lostreams I have a coworker that wants to increase the LOGSNUM value of the structure defined for numerous CICS DFHLOG logstreams. Can this be done dynamically and will we have to make sure that all regions are down and delete/define with the larger value. I have tried RTFM but it was not intuitively obvious. Bob -- 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: OT: Digital? Cloud? Modern And Cost-Effective? Surprise! It's The Mainframe - Forbes
David L. Craig wrote: Nancy (now Assistant Chief) confirmed the 91 did not use ASP. So I was wrong. Where's my ceremonial sword? Hopefully I won't get that wrong. ;-) Ok, just lay for me nice and easy flat while I sharpen my sword. sharpening . sharpening more sharpening Ops. Too much sharpening, I now have a little pocket knife. Ok David, today I will spare your life... ;-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: Structure resizing for CICS LOG lostreams
If you have so many CICS logs, why not use DASDONLY for the logs instead of the coupling facility? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Monday, March 30, 2015 12:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Structure resizing for CICS LOG lostreams I have a coworker that wants to increase the LOGSNUM value of the structure defined for numerous CICS DFHLOG logstreams. Can this be done dynamically and will we have to make sure that all regions are down and delete/define with the larger value. I have tried RTFM but it was not intuitively obvious. Bob -- 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: Structure resizing for CICS LOG lostreams
Richards, Robert B. wrote: Not what the CICS sysprog wanted, I guess. Ok. For what does he wants for the CICS Logstreams? I mean, for what is the purpose of those logstreams? Why does he wants an increase of LOGSNUM? Or what are you trying to solve? 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
Structure resizing for CICS LOG lostreams
I have a coworker that wants to increase the LOGSNUM value of the structure defined for numerous CICS DFHLOG logstreams. Can this be done dynamically and will we have to make sure that all regions are down and delete/define with the larger value. I have tried RTFM but it was not intuitively obvious. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF ISF121I message
Examine your IEFUSI exit. That'll have the final vote for virtual storage sizes for your non-authorized address spaces. BTW, 1MB for MEMLIMIT is very small. A reasonable size is more on the order of 4GB. Mark Jacobs Neal Eckhardt mailto:neckha...@cnyric.org March 30, 2015 at 2:34 PM We converted to z/OS 2.1 this past weekend. Since then, we are seeing message ISF121I Module IDFSM64 was unable to obtain _ bytes of storage (1 segment). Check MEMLIMIT value. The only MEMLIMIT value we can find is in SMFPRMxx, and that is already set to 1M as suggested in the documentation. It seems the MEMLIMIT would have no effect since a TSO user always has a REGION specified when they sign on. The funny thing is that the systems programmers do not seem to get this message. Has anybody run into this and what was the solution? Thanks, Neal -- 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: SDSF ISF121I message
Ok then. I still think that 1MB is way too small for MEMLIMIT. Is there a reason why you selected that value? Mark Jacobs Neal Eckhardt mailto:neckha...@cnyric.org March 30, 2015 at 3:08 PM We do not provide an IEFUSI exit. The standard IBM supplied dummy exit is all that there is in SYS1.LPALIB. -- 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: SDSF ISF121I message
Paraphrasing the JCL Reference manual: MEMLIMIT parameter specifies the limit on the total size of usable virtual storage *above the bar* in a single address space. REGION is for below the bar, MEMLIMIT is for 64-bit addresses above the bar. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Neal Eckhardt Sent: Monday, March 30, 2015 3:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SDSF ISF121I message OH, no reason. It's been that way forever. Since we specify region on all the jobs, we kind of considered that parameter obsolete if you know what I mean since it never affected anything. We will probably change it. Since the TSO address spaces always have a region, I wouldn't think that changing MEMLIMIT in SMFPRMxx would have no effect. Neal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION : ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM
Just for completeness, here is the technote. http://www-01.ibm.com/support/docview.wss?uid=isg3T1012687 On Mon, Mar 30, 2015 at 8:15 AM, willie bunter 001409bd2345-dmarc-requ...@listserv.ua.edu wrote: Hallo All, I noticed in the HSM startup the following error messages: ARC0037I DFSMSHSM PROBLEM DETERMINATION OUTPUT DATA 679 ARC0037I (CONT.) SETS SWITCHED, ARCPDOX=HSM.HSMPDOXC, ARC0037I (CONT.) ARCPDOY=HSM.HSMPDOYC IEC145I 413-04,IFG0194A,DFHSMC,DFHSMC,ARCPDOX,8612,SYS226, HSM.HSMPDOXC ARC0036E I/O INHIBITED FOR DFSMSHSM PROBLEM 682 ARC0036E (CONT.) DETERMINATION OUTPUT DATA SET, REAS= 3 I checked the error message for ARC0036E and it says the following : A failure occurred while attempting to open the ARCPDOX data set It doesn't tell me very much. I noticed that the dsn is at 16 extents. Could this be the cause of the problem? If so, I will have to enlargen both PDA dsns. Could someone shed some light on this? Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF ISF121I message
My apologies to Mark and all the others. MEMLIMIT in SMFPRMxx IS for above the bar storage. The documentation that somebody put in SMFPRMxx for the parameter was incorrect about the usage. I will change that parameter and hope for the best, but I think that will solve it. Next time RTFM and don't believe what somebody types in a member. Neal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Redbook on DFHSM and PDSEs Control datasets
http://www.redbooks.ibm.com/redpieces/pdfs/redp5160.pdf -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF ISF121I message
We do not provide an IEFUSI exit. The standard IBM supplied dummy exit is all that there is in SYS1.LPALIB. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Structure resizing for CICS LOG lostreams
These particular ones are for test regions. He wants to increase the number from 70 to 100. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, March 30, 2015 1:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Structure resizing for CICS LOG lostreams Richards, Robert B. wrote: Not what the CICS sysprog wanted, I guess. Ok. For what does he wants for the CICS Logstreams? I mean, for what is the purpose of those logstreams? Why does he wants an increase of LOGSNUM? Or what are you trying to solve? 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF ISF121I message
OH, no reason. It's been that way forever. Since we specify region on all the jobs, we kind of considered that parameter obsolete if you know what I mean since it never affected anything. We will probably change it. Since the TSO address spaces always have a region, I wouldn't think that changing MEMLIMIT in SMFPRMxx would have no effect. Neal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Structure resizing for CICS LOG lostreams
I thought so too, but want to ask if something had changed since the last time I increased the number of structures. At least there, you can switch between CFRM datasets. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barkow, Eileen Sent: Monday, March 30, 2015 1:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Structure resizing for CICS LOG lostreams From what I can see, the entire log stream structure would have to be deleted and redefined in order to increase LOGSNUM. According to this from z/os, it looks like the log streams would have to be disconnected in order to update LOGSNUM. But CICS TS 5.1 will not let you disconnect the main journal DFHLOG. And I do not even see any option in IXGINVNT (Z/OS 1.13) to update LOGSNUM. REQUEST=UPDATE option of IXGINVNT z/OS MVS Programming: Assembler Services Reference IAR-XCT SA22-7607-17 The IXGINVNT macro with the UPDATE parameter allows a program to update a log stream entry in the LOGR policy for a coupling facility or DASD-only log stream. Except for the RETPD and AUTODELETE parameters, note that you cannot update a log stream while there are active connections to it. And this from CICS DOC: 2.You cannot update AVGBUFSIZE, like other structure definition attributes such as MAXBUFSIZE and LOGSNUM, unless you first delete the log streams in the structure definition. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richards, Robert B. Sent: Monday, March 30, 2015 12:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Structure resizing for CICS LOG lostreams I have a coworker that wants to increase the LOGSNUM value of the structure defined for numerous CICS DFHLOG logstreams. Can this be done dynamically and will we have to make sure that all regions are down and delete/define with the larger value. I have tried RTFM but it was not intuitively obvious. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF ISF121I message
Thank you Peter, we didn't know about the MEMLIMIT JCL parameter. That points us in a direction that might actually solve the problem. Now we just have to figure out how to specify it for TSO regions. Thanks for the help and giving us a missing piece of the puzzle. Neal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SDSF ISF121I message
We converted to z/OS 2.1 this past weekend. Since then, we are seeing message ISF121I Module IDFSM64 was unable to obtain _ bytes of storage (1 segment). Check MEMLIMIT value. The only MEMLIMIT value we can find is in SMFPRMxx, and that is already set to 1M as suggested in the documentation. It seems the MEMLIMIT would have no effect since a TSO user always has a REGION specified when they sign on. The funny thing is that the systems programmers do not seem to get this message. Has anybody run into this and what was the solution? Thanks, Neal -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDSF ISF121I message
If you have a spare logon proc, specify a larger MEMLIMIT and see it you can use SDSF without seeing the error. Bob Shannon Rocket Software Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscr...@rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: SDSF ISF121I message
Paraphrasing the JCL Reference manual: MEMLIMIT parameter specifies the limit on the total size of usable virtual storage *above the bar* in a single address space. REGION is for below the bar, MEMLIMIT is for 64-bit addresses above the bar. And there is the (maybe) unexpected and (IMHO) unlucky relationship that REGION=0K or 0M implies MEMLIMIT=NOLIMIT. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
