Re: Health Checker for z/OS checks - to check or not to check, now is the..
> After using Health Checker for z/OS for several months now, I'm having > doubts about some checks, so please feel free to comment :) I just cannot resist. But first: Have you checked the archives? Most of the checks you talk about here I have complained about in the past. Documented in the archives. > Check: ASM_LOCAL_SLOT_USAGE > We're using 4 page data sets in our test LPAR's, which are ~540k > tracks. Adding additional is always an option, but is it worth it? > Maybe to change the warning threshold? Thoughts? The way I had set it up was to only let the check put out its message once and then only once per day for the life of the IPL. Several discussions on ibmmain have shown that the old 30% recommendation has never been withdrawn. I felt it important enough to have the check active. Eventually I ended up with a whole lot of 'storage' reporting that I used to fight for more real storage for the lpars that needed it. > Check: GRS_CONVERT_RESERVES > Comment: Still haven't used the GRS ENQ/DEQ/RESERVE Monitor to check > what reserves our systems are using. I was wondering has anyone tried > to convert all RESERVEs to ENQs? Were any applications problematic? I deleted that check. We share two catalogs outside the sysplex, and in that case you *must not* convert reserves. In my opinion, since GRS *knows* that those catalogs are shared (after all, there is a certain construct detailed in the GRS planning manual to be put into the RNLs), this check should have the intelligence to turn itself off without customer intervention. > Check: XCF_SIG_STR_SIZE > Comment: This one just a raised a wonder in my head. It's not showing > an exception rather a few warnings in the text of the check - that our > signaling structures can't support the configuration specified with > MAXSYSTEM. This is beacuse the sysplex where this occurs was big once, > but now it's just a few LPARs. How could one reduce the MAXSYSTEM > value while preserving other data in the CDSs? If I format a new CDS > with a smaller MAXSYSTEM number, it won't play nice with the existing > ones. As Mike said (I am always glad when someone remembers my posts) there is NO WAY to decrease MAXSYSTEM dynamically, for integrity reasons. That is even described in one of the books. If you want to decrease MAXSYSTEM, you have to really cold-start the full sysplex on fresh couple data sets. Be aware though, that with a design change in z/OS 1.9 IBM now *requires* all couple data sets in the sysplex to have the *same* value of MAXSYSTEM, as that no longer denotes the capacity of the sysplex but functions as an index. We cold-started on sysplex and CFRM CDSs twice a year, so other than discovering the hard way about that design change, I was able to run that check. If you're happy with your signalling structures, on the other hand, just delete the check. The requirement Mike mentioned will NOT help you with this check, though. If it ever gets implemented. Even if you could clean up old systems from the CDSs, that would only address the indexing issue, but it would still not reduce MAXSYSTEM, which is what this check uses for computing the SIG_STR_SIZE on the assumption that you really want to have this number of systems in your plex. > Check: IXGLOGR_ENTRYTHRESHOLD > Comment: Another "regular" check that pops up. Almost always from the > RRS MAIN logstream. Whenever I see this, I check the CF structure > which always shows around 40-60% entries in use. Also, the structure > is stuck at the inital size and AUTOALTER is disabled (by some > recommendation, I think..). Will RRS structure auto expand if needed > without z/OS (AUTOALT) intervention? Any best practices to recommend > here? Also, sometimes when I check the "Count" column in the checks > text, it's empty (no number is shown), but the exception is there... > O.o ? Disabling AUTOALTER for list structures was probably my recommendation: I had a case where AUTOALTER changed the ratio of entries-to-elements in a signalling structure (when one system was shutdown for immediate reIPL) so that at reIPL time my sysplex didn't have full connectivity anymore. I was fairly badly attacked by IBM and Cheryl Watson for this recommendation, Cheryl Watson not even citing the full reasoning when she cited. I still feel it is better not to have XES make my sysplex loose full connectivity so AUTOALTER was turned off. Whenever I checked for stalled offloads (which is essentially what this LOGR check tries to warn about) the 'real mechanism' that does offload had kicked in and done the offload. Given that logger itself has a lot of 'red' messages warning about stalled offloads, I just deleted this check. > Check: RRS_MUROFFLOADSIZE > This seems just fine, but I'm getting an error, not a warning that the > change will be effective upon the new offload data set allocation. > What's wrong here? (LOGR CDS FORMAT LEVEL: HBB6603) No clue. I had deleted all of the RRS checks, as they appeared to
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
According to the "official" history: History In the mid-1960's a small group of IBM employees working at the Manned Spacecraft Center in Houston worked on a program called HASP (please see next section for "How HASP got its name") which eventually was made available as an FDP. Its popularity and use expanded such that by February 1971 IBM released HASP II Version 3.0 as a Type III product with Class A support. This HASP ran as an optional extension to OS/MVT, performing the peripheral functions associated with job processing. In March of 1973 IBM released the SVS (i.e. OS/VS2 Release 1) operating system using a new version of HASP referred to as Version 4.0 HASP II Version 4.0 was not a System Control Program (SCP). It was still optionally available to replace OS/VS2 Release 1 readers and writers and continued to be a Class A service. With the availability of OS/VS2 Release 2 (MVS), HASP's name was changed to JES2. On Mar 21, 2013, at 3:56 PM, Bob Rutledge wrote: Day 1 was somewhat earlier than 1975. We installed HASP at CMU in the preceding decade. Bob Staller, Allan wrote: Maybe so, but JES2/HASP has done this since day 1 (circa 1975). -- 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: Lost datagrams on z/OS 1.12?
Some of you asked for updates. Update: the problem has reappeared after a while in the "version 1.3" code. I got a packet trace and it seems to me to show everything exactly as I would expect. I have told the customer that it may be our problem but someone on the network side or in IBM is going to have to look at the packet trace and tell me what we're doing wrong. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, March 20, 2013 2:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Lost datagrams on z/OS 1.12? And the answer is ... that I am not a very happy camper here. I sent "version 1.3" off to the customer. The only changes are diagnostic, not "functional." And guess what -- the problem has gone away. So either - the customer is confused and/or was also making firewall or router changes at the same time. I don't think that is the case. - moving variables around has obscured the problem. That's the one that worries me. Very little variable movement so hopefully not. - perhaps compiler/library maintenance? Thank you Lloyd I am looking into that. Not much time between versions. "Version 1.2" was compiled on Feb. 25 and "Version 1.3" yesterday. Otherwise I just don't know. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, March 20, 2013 8:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Lost datagrams on z/OS 1.12? Thanks all. Filling in some gaps and answering some questions. I've added additional trace code within the product to make certain that the socket, sockaddr, and record length are as expected. (I already know that the sendto() is getting issued with the correct record.) I changed the error check from if ( returnvalue < length ) to if (returnvalue != length ) to help avoid any possibility of signed/unsigned or similar issues. Running a test at the customer today with a packet trace also. Environment is z/OS started task. Source language is IBM XL C++. Record length varies but is typically a few hundred bytes and never exceeds 1024 bytes. Ditto for the old version that works, so maximum datagram and MTU size issues seem unlikely. Don't know any of the customer's TCP/IP configuration but the message traffic should be 99.9% the same for both versions -- they are in theory both sending the same "stuff." -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
On Thu, 21 Mar 2013 08:34:52 -0700, Walter Marguccio wrote: > > how can I force HSM to�recall the dsn to�the original volume?� IIRC, if the datasets belongs to a SC whose Guaranteed Space = Yes, then hsm recalls the dataset on the same volume where the dataset originally was.� I'm pretty sure I don't grasp this "Guaranteed Space" concept. It sounds as if the OS guarantees space will be available on the original volume(s) for the data set to be recalled. To do this, it must hold that space in reserve, in which case there's precious little to gain by migrating. Or will it restore the data set to the original volume (but not necessarily the original extents) by forcing the migration of other data sets as needed? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DB2
Sign up at idug.org Lizette -Original Message- >From: Ron Wells >Sent: Mar 21, 2013 2:00 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: DB2 > >Have some DB2 questions >> not seeing group on listserv ?? >under a different area ?? > >-- >Email Disclaimer >This E-mail contains confidential information belonging to the sender, >which may be legally privileged information. This information is intended >only for the use of the individual or entity addressed above. If you are >not the intended recipient, or an employee or agent responsible for >delivering it to the intended recipient, you are hereby notified that any >disclosure, copying, distribution, or the taking of any action in reliance on >the contents of the E-mail or attached files 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
Re: DB2
thanks From: Ed Finnell To: IBM-MAIN@LISTSERV.UA.EDU Date: 03/21/2013 04:21 PM Subject:Re: DB2 Sent by:IBM Mainframe Discussion List _www.idug.org_ (http://www.idug.org) should get you pointed in right direction. Doesn't show up on lsoft.com catalist and sub db2-l to listsrv.ua.edu sends you off to american edu? In a message dated 3/21/2013 4:01:09 P.M. Central Daylight Time, ron.we...@slfs.com writes: Have some DB2 questions >> not seeing group on listserv ?? under a different area ?? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files 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: DB2
_www.idug.org_ (http://www.idug.org) should get you pointed in right direction. Doesn't show up on lsoft.com catalist and sub db2-l to listsrv.ua.edu sends you off to american edu? In a message dated 3/21/2013 4:01:09 P.M. Central Daylight Time, ron.we...@slfs.com writes: Have some DB2 questions >> not seeing group on listserv ?? under a different area ?? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DB2
Have some DB2 questions >> not seeing group on listserv ?? under a different area ?? -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files 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: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Day 1 was somewhat earlier than 1975. We installed HASP at CMU in the preceding decade. Bob Staller, Allan wrote: Maybe so, but JES2/HASP has done this since day 1 (circa 1975). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
> From: willie bunter > I checked the SC. It doesn't have Guaranteed Space. Willie, if the SC doesn't have Guaranteed Space, then there is no way to force hsm to recall a migrated dataset on the original volume (at least that I'm aware of). If your dataset would have had a SC with Guaranteed Space = Yes, then hsm would have recalled it on the same volume where it was allocated. And if the original volume is not there (for whatever reason) the recall would fail. If you have datasets with such a SC, you can test this yourself. Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
CCA (was Re: IBM Mainframe (1980's) on You tube)
I don't know much about TR-31, other than the little I've read about it in the ICSF documentation. I do remember our Thales vendor trying to sell it to us some years ago, and I couldn't understand a word he was saying! Now that I understand it a bit more I find it interesting, but rather useless until our "partners" (Visa, MasterCard, our ATM vendor) support it. And I've heard no indication that any of them have it on their radar. Frank > > From: Todd Arnold >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Wednesday, March 20, 2013 6:41 AM >Subject: Re: IBM Mainframe (1980's) on You tube > >Two points... > >(1) Remember that when IBM invented CCA back in the late 1980s, there really >were no other HSMs - thus, there were no other crypto architectures in the >banking world to be "compatible" with. I suppose other vendors who came along >and developed HSMs could have adopted CCA, but they developed their own APIs >and architectures. IBM, of course, had no way to make our own CCA any kind of >"standard" for the industry. > >(2) Compatibility for interchange has always been a problem, and the solution >for key exchange has generally been to use a least common denominator >approach, simply wrapping keys with TDES in ECB mode with no associated >type/usage information or other metadata. Dissimilar systems generally strip >off their proprietary metadata when exporting the key, then the receiving >system binds its own proprietary metadata structures to the key when importing >it. This obviously is not the best approach in terms of security, but it's >what everyone has done all these years. Now, there is the TR-31 key block >format which has improved somewhat on that situation, but TR-31 also has >significant problems. It defines its own fixed set of key metadata, which of >course is not entirely compatible with anything the preceded it and does not >generally match up exactly with any vendor's HSM architecture, so translations >have to occur and in the process security information is lost or interpreted differently. Furthermore, different vendors have interpreted the meaning of the key type/usage in TR-31 in different ways, so the restrictions you think you defined for a key may not be enforced in quite the way you thought when the key reaches some other device. One example is that TR-31 has rather coarse key typing and usage, whereas CCA has much finer granularity and lets you control the key much more tightly. When translating a CCA key to TR-31 format, all that extra control has to be discarded so that you use only the attributes defined in TR-31. Conversely, when importing a TR-31 key into CCA, you have to somehow create all the extra, more detailed control attributes that are not present in TR-31, and the only way to do that is to let the application program tell CCA what to do. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Paul: JES2 bypass's open on the proclibs. Therefore by bypasses ENQ. Its been this way since day one. Ed On Mar 21, 2013, at 11:22 AM, Paul Gilmartin wrote: On Thu, 21 Mar 2013 10:37:15 -0500, David Devine wrote: its not as simple as getting it recalled to the same volume. I believe it's still the case that at jes startup it maps the dataset extents so you would need to get it back to exactly the same place(s) on the pack. The best solution is to make all your jes proclibs non migrateable. A simple alter mgmtclas to something suitable will do the job. Does this mean that HSM will migrate a data set while it's open? Eek! -- 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: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Exactly. Think back to the days before you had multiple systems to change things from - or even back to before TSO/ISPF. For example, if you had to enlarge a proclib how could you submit a job to do so if it was in use by JES2 and JES2 was up in order for you to submit (read in) a job. You were able to make the change because the NODSI attribute for HASJES20 in the PPT for JES2. For example, allocate a new proclib, copy old to new, rename, then IPL or $PJES2,ABEND / restart. No dynamic proclib support back then either. But it was more than just NODSI, even if you tried to override it, it didn't matter because JES2 used S99NORES in the dynamic allocation. See a thread with subject "JES2 DD Concatenation issue" from 2008 with lots of information. Brian Peterson authored a requirement to allow DSI to be used for JES2 (HASJES20) in the PPT so PROCLIBs could be ENQed. I forgot when that happened, but I've been running that way for years. Paul, you even contributed to that thread with a job stream scenario to do the rename with the ENQs in place. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ >Maybe so, but JES2/HASP has done this since day 1 (circa 1975). > >Many decisions made many moons ago are maintained for historical >compatability. >Those decisions would not necessarily be the same today. > >> >> >>No. HSM will not migrate a file if it is open. IIRC, But proclibs have >> >>short usage. So it is possible the proclib is not used within the >> >>timeframe for migration is specified. JES2 does not always open PROCLIBs >> >>after the TTRs are read into JES2 ASID. Unless the environment has multiple >> >>PROCxx statements in JES2 that are constantly used, PROC01 PROC02 etc, then >> >>the dataset is not needed. JES2 already knows where the data is located on >> >>the dasd volume. >> >>> >>> >>>That breaks everything that ought to be a rule. JES2 should be a >>>law-abiding >>>citizen and hold the data set open. >>> >>>-- gil >>> >>> -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Add FORCENONSMS UNIT(3390) VOL(volser) to the recall command. hlq.CLIST(HRECN) PROC 2 D V HSEND RECALL &D VOL(&V) UNIT(3390) FORCENON END /* PROC */ On Thu, Mar 21, 2013 at 10:21 AM, willie bunter wrote: > Good Day Readers, > > Several jobs are failing due to the following : > > IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,SYS2.HESP.BPROCLIB > IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, > IEF196I SYS2.HESP.BPROCLIB > $HASP307 HESPD01 UNABLE TO OPEN PROC02 > IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR > > The problem was caused by the library which was migrated by HSM was recalled > to another volume - SMTP03. The volumes in this Storage Group are SMS > managed. > > I was able to get our MVS support folks to refresh the JES2 proc which > rectified the problem (jobs were rerun successsfully). > > My question is should a problem of this nature occur again (pds migrated) how > can I force HSM to recall the dsn to the original volume? In this case the > dsn was recalled to another volume other than the orginal. > > Thanks. -- 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: Health Checker for z/OS checks - to check or not to check, now is the..
On Thu, Mar 21, 2013 at 10:23 AM, IP wrote: > Check: XCF_SIG_STR_SIZE > Comment: This one just a raised a wonder in my head. It's not showing > an exception rather a few warnings in the text of the check - that our > signaling structures can't support the configuration specified with > MAXSYSTEM. This is beacuse the sysplex where this occurs was big once, > but now it's just a few LPARs. How could one reduce the MAXSYSTEM > value while preserving other data in the CDSs? If I format a new CDS > with a smaller MAXSYSTEM number, it won't play nice with the existing > ones. Per Barbara Nitz, create new, empty Coupling datasets. Shut down all LPARS and use the new dataset when the first system comes up. She has a user requirement for a command to purge systems from the coupling datasets. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Health Checker for z/OS checks - to check or not to check, now is the..
On Thu, Mar 21, 2013 at 11:15 AM, Staller, Allan wrote: > Comments interspersed: > > > Check: ASM_LOCAL_SLOT_USAGE > Comment: This one pops up regularly on LPAR's with Websphere software. > It's almost impossible to keep the usage below 30%. > Documentation says: "To maximize the efficiency of ASM slot management, you > should keep the slot usage on all local page data sets below 30%." > We're using 4 page data sets in our test LPAR's, which are ~540k tracks. > Adding additional is always an option, but is it worth it? > Maybe to change the warning threshold? Thoughts? > >>> Easy fix. Add more locals. ISTR,(although I may have missed an update) >>> that there was an upper limit to the size of a local. Used to be 4GB limit. Now limited to the track allocated area of an EAV (54GB). We just had a discussion on DFSORT parameters that tend to fill the paging packs. If you don't have a lot of I/O, you should be fine. https://groups.google.com/forum/?fromgroups=#!topic/bit.listserv.ibm-main/cbgA_pO0j4I EXPOLD=0 EXPMAX=50% http://www-01.ibm.com/support/docview.wss?uid=isg1II13495 > > Check: GRS_CONVERT_RESERVES > Comment: Still haven't used the GRS ENQ/DEQ/RESERVE Monitor to check what > reserves our systems are using. I was wondering has anyone tried to convert > all RESERVEs to ENQs? Were any applications problematic? > There are several cases where the GRS planning manual suggests *NOT* converting reserves. Check the fine manual for additional info. JES2 Checkpoint and Spool volumes are reserved. -- 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: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Maybe so, but JES2/HASP has done this since day 1 (circa 1975). Many decisions made many moons ago are maintained for historical compatability. Those decisions would not necessarily be the same today. No. HSM will not migrate a file if it is open. IIRC, But proclibs have short >usage. So it is possible the proclib is not used within the timeframe for >migration is specified. JES2 does not always open PROCLIBs after the TTRs are >read into JES2 ASID. Unless the environment has multiple PROCxx statements in >JES2 that are constantly used, PROC01 PROC02 etc, then the dataset is not >needed. JES2 already knows where the data is located on the dasd volume. > That breaks everything that ought to be a rule. JES2 should be a law-abiding citizen and hold the data set open. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
On Thu, 21 Mar 2013 09:31:31 -0700, Lizette Koehler wrote: >No. HSM will not migrate a file if it is open. IIRC, But proclibs have short >usage. So it is possible the proclib is not used within the timeframe for >migration is specified. JES2 does not always open PROCLIBs after the TTRs are >read into JES2 ASID. Unless the environment has multiple PROCxx statements in >JES2 that are constantly used, PROC01 PROC02 etc, then the dataset is not >needed. JES2 already knows where the data is located on the dasd volume. > That breaks everything that ought to be a rule. JES2 should be a law-abiding citizen and hold the data set open. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
No. HSM will not migrate a file if it is open. IIRC, But proclibs have short usage. So it is possible the proclib is not used within the timeframe for migration is specified. JES2 does not always open PROCLIBs after the TTRs are read into JES2 ASID. Unless the environment has multiple PROCxx statements in JES2 that are constantly used, PROC01 PROC02 etc, then the dataset is not needed. JES2 already knows where the data is located on the dasd volume. An JES2 requires that the data map to the same TTR. So the proclib could be moved, but the tracks not over written. So the TTRs would still be valid for that proc. The minute the space is reused, is when JES2 will provide the I/O error. So it is not use going back to the same volume, but to the exact same TTR placements. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf > Of Paul Gilmartin > Sent: Thursday, March 21, 2013 9:23 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME > > On Thu, 21 Mar 2013 10:37:15 -0500, David Devine wrote: > > > >its not as simple as getting it recalled to the same volume. I believe it's > >still the case > that at jes startup it maps the dataset extents so you would need to get it > back to > exactly the same place(s) on the pack. > >The best solution is to make all your jes proclibs non migrateable. > >A simple alter mgmtclas to something suitable will do the job. > > > Does this mean that HSM will migrate a data set while it's open? Eek! > > -- gil > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Lizette, Thanks for the advice. I have taken note of the suggestions and hopefully I can have the changes done. Thanks. From: Lizette Koehler To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 21, 2013 12:18:03 PM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Willie, As others have pointed out, a couple of solutions. 1) Use USER PROCLIB datasets in JCLLIB datasets in your JCL. 2) Have a NOMIG class in SMS that will not migrate the dataset. PROCLIBs are touchy to JES2. I typically have my users code JCLLIB statements, and I think the job will wait for the RECALL if they were migrated. I can test that later. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf > Of willie bunter > Sent: Thursday, March 21, 2013 8:22 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME > > Good Day Readers, > > Several jobs are failing due to the following : > > IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035- > 0009,9987,SMTP01,SYS2.HESP.BPROCLIB > IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, > IEF196I SYS2.HESP.BPROCLIB > $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - JCL > ERROR > > The problem was caused by the library which was migrated by HSM was recalled to > another volume - SMTP03. The volumes in this Storage Group are SMS managed. > > I was able to get our MVS support folks to refresh the JES2 proc which rectified the > problem (jobs were rerun successsfully). > > My question is should a problem of this nature occur again (pds migrated) how can I > force HSM to recall the dsn to the original volume? In this case the dsn was recalled to > another volume other than the orginal. > > Thanks. > -- 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
On Thu, 21 Mar 2013 10:37:15 -0500, David Devine wrote: > >its not as simple as getting it recalled to the same volume. I believe it's >still the case that at jes startup it maps the dataset extents so you would >need to get it back to exactly the same place(s) on the pack. >The best solution is to make all your jes proclibs non migrateable. >A simple alter mgmtclas to something suitable will do the job. > Does this mean that HSM will migrate a data set while it's open? Eek! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Alan, That's the problem. Restoring the dsn on the same volume. From: "Schwartz, Alan" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 21, 2013 12:02:31 PM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME IIRC, After restoring the dataset to the same volume I believe you can submit a job with a /*JOBPARM PROCLIB=ddname where that's one of the proclib concatenation DD's in the JES2 proc. That will have JES reallocate the proclibs and you should be ok. Alan Schwartz ITO Global Services Operations and Engineering Xerox Business Services, LLC 1500 Towerview Rd. Eagan, MN. 55121-1346 p. 612.266.3150 m. 651.274.5819 f. 612.266.3196 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Devine Sent: Thursday, March 21, 2013 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Hi Willie, its not as simple as getting it recalled to the same volume. I believe it's still the case that at jes startup it maps the dataset extents so you would need to get it back to exactly the same place(s) on the pack. The best solution is to make all your jes proclibs non migrateable. A simple alter mgmtclas to something suitable will do the job. Dave *** >Good Day Readers, >Several jobs are failing due to the following : >IEC143I >213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,SYS2.HESP.BPROCLIB >IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, >IEF196I SYS2.HESP.BPROCLIB >$HASP307 HESPD01 UNABLE TO OPEN PROC02 >IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR >The problem was caused by the library which was migrated by HSM was recalled >to another volume - SMTP03. The >volumes in this Storage Group are SMS >managed. >I was able to get our MVS support folks to refresh the JES2 proc which >rectified the problem (jobs were rerun >successsfully). >My question is should a problem of this nature occur again (pds migrated) how >can I force HSM to recall the dsn to the >original volume? In this case the >dsn was recalled to another volume other than the orginal. >Thanks. -- 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: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Walter, I checked the SC. It doesn't have Guaranteed Space. From: Walter Marguccio To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 21, 2013 11:34:52 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME From: willie bunter > how can I force HSM to recall the dsn to the original volume? IIRC, if the datasets belongs to a SC whose Guaranteed Space = Yes, then hsm recalls the dataset on the same volume where the dataset originally was. Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
Willie, As others have pointed out, a couple of solutions. 1) Use USER PROCLIB datasets in JCLLIB datasets in your JCL. 2) Have a NOMIG class in SMS that will not migrate the dataset. PROCLIBs are touchy to JES2. I typically have my users code JCLLIB statements, and I think the job will wait for the RECALL if they were migrated. I can test that later. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf > Of willie bunter > Sent: Thursday, March 21, 2013 8:22 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME > > Good Day Readers, > > Several jobs are failing due to the following : > > IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035- > 0009,9987,SMTP01,SYS2.HESP.BPROCLIB > IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, > IEF196I SYS2.HESP.BPROCLIB > $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - JCL > ERROR > > The problem was caused by the library which was migrated by HSM was recalled to > another volume - SMTP03. The volumes in this Storage Group are SMS managed. > > I was able to get our MVS support folks to refresh the JES2 proc which rectified the > problem (jobs were rerun successsfully). > > My question is should a problem of this nature occur again (pds migrated) how can I > force HSM to recall the dsn to the original volume? In this case the dsn was recalled to > another volume other than the orginal. > > Thanks. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Health Checker for z/OS checks - to check or not to check, now is the..
Comments interspersed: Check: ASM_LOCAL_SLOT_USAGE Comment: This one pops up regularly on LPAR's with Websphere software. It's almost impossible to keep the usage below 30%. Documentation says: "To maximize the efficiency of ASM slot management, you should keep the slot usage on all local page data sets below 30%." We're using 4 page data sets in our test LPAR's, which are ~540k tracks. Adding additional is always an option, but is it worth it? Maybe to change the warning threshold? Thoughts? >> Easy fix. Add more locals. ISTR,(although I may have missed an update) >> that there was an upper limit to the size of a local. Check: GRS_CONVERT_RESERVES Comment: Still haven't used the GRS ENQ/DEQ/RESERVE Monitor to check what reserves our systems are using. I was wondering has anyone tried to convert all RESERVEs to ENQs? Were any applications problematic? >>> There are several cases where the GRS planning manual suggests *NOT* >>> converting reserves. Check the fine manual for additional info. .snipppage Check: XCF_CDS_SPOF Comment: For this one, I just want to confirm my understanding of the messages. I'm seeing component indicators = 3000__ on all the messages which cause this check to generate a high severity (by default) exception. By checking the DOC APAR OA28958, it seems that indicator is telling me that IBM thinks owning a single book in the CEC is a single point of failure (well, it is in some way, but... hmh?). Am I reading this right? Adding a book is defenetly not an option, so if that is the case, this one will need to stay disabled. >>> I think this is referring to both cds's on the same PU (block of 4096 >>> addresses). E.G. 8000-8FFF. I actually ignore this check. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
There are some datasets which shouldn't migrate (probably shouldn't be in SMS pools at all). JES proclibs are in this set of datasets that shouldn't migrate. :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of willie bunter > Sent: Thursday, March 21, 2013 8:22 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME > > Good Day Readers, > > Several jobs are failing due to the following : > > IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035- > 0009,9987,SMTP01,SYS2.HESP.BPROCLIB > IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, > IEF196I SYS2.HESP.BPROCLIB > $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - > JCL ERROR > > The problem was caused by the library which was migrated by HSM was > recalled to another volume - SMTP03. The volumes in this Storage Group > are SMS managed. > > I was able to get our MVS support folks to refresh the JES2 proc which > rectified the problem (jobs were rerun successsfully). > > My question is should a problem of this nature occur again (pds > migrated) how can I force HSM to recall the dsn to the original > volume? In this case the dsn was recalled to another volume other than > the orginal. > > Thanks. > > -- > 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
IIRC, After restoring the dataset to the same volume I believe you can submit a job with a /*JOBPARM PROCLIB=ddname where that's one of the proclib concatenation DD's in the JES2 proc. That will have JES reallocate the proclibs and you should be ok. Alan Schwartz ITO Global Services Operations and Engineering Xerox Business Services, LLC 1500 Towerview Rd. Eagan, MN. 55121-1346 p. 612.266.3150 m. 651.274.5819 f. 612.266.3196 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Devine Sent: Thursday, March 21, 2013 10:37 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Hi Willie, its not as simple as getting it recalled to the same volume. I believe it's still the case that at jes startup it maps the dataset extents so you would need to get it back to exactly the same place(s) on the pack. The best solution is to make all your jes proclibs non migrateable. A simple alter mgmtclas to something suitable will do the job. Dave *** >Good Day Readers, >Several jobs are failing due to the following : >IEC143I >213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,SYS2.HESP.BPROCLIB >IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, >IEF196I SYS2.HESP.BPROCLIB >$HASP307 HESPD01 UNABLE TO OPEN PROC02 >IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR >The problem was caused by the library which was migrated by HSM was recalled >to another volume - SMTP03. The >volumes in this Storage Group are SMS >managed. >I was able to get our MVS support folks to refresh the JES2 proc which >rectified the problem (jobs were rerun >successsfully). >My question is should a problem of this nature occur again (pds migrated) how >can I force HSM to recall the dsn to the >original volume? In this case the >dsn was recalled to another volume other than the orginal. >Thanks. -- 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
Devnie, Thanks for the tip. I will heed your advice. I will need to fill out lots of paper work to change the rule. Thanks. From: David Devine To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, March 21, 2013 11:37:15 AM Subject: Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME Hi Willie, its not as simple as getting it recalled to the same volume. I believe it's still the case that at jes startup it maps the dataset extents so you would need to get it back to exactly the same place(s) on the pack. The best solution is to make all your jes proclibs non migrateable. A simple alter mgmtclas to something suitable will do the job. Dave *** >Good Day Readers, >Several jobs are failing due to the following : >IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,SYS2.HESP.BPROCLIB >IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, >IEF196I SYS2.HESP.BPROCLIB >$HASP307 HESPD01 UNABLE TO OPEN PROC02 >IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR >The problem was caused by the library which was migrated by HSM was recalled >to another volume - SMTP03. The >volumes in this Storage Group are SMS >managed. >I was able to get our MVS support folks to refresh the JES2 proc which >rectified the problem (jobs were rerun >successsfully). >My question is should a problem of this nature occur again (pds migrated) how >can I force HSM to recall the dsn to the >original volume? In this case the >dsn was recalled to another volume other than the orginal. >Thanks. -- 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 - RECALLING DSN TO ITS ORIGINAL VOLUME
Hi Willie, its not as simple as getting it recalled to the same volume. I believe it's still the case that at jes startup it maps the dataset extents so you would need to get it back to exactly the same place(s) on the pack. The best solution is to make all your jes proclibs non migrateable. A simple alter mgmtclas to something suitable will do the job. Dave *** >Good Day Readers, >Several jobs are failing due to the following : >IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,SYS2.HESP.BPROCLIB >IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, >IEF196I SYS2.HESP.BPROCLIB >$HASP307 HESPD01 UNABLE TO OPEN PROC02 >IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR >The problem was caused by the library which was migrated by HSM was recalled >to another volume - SMTP03. The >volumes in this Storage Group are SMS >managed. >I was able to get our MVS support folks to refresh the JES2 proc which >rectified the problem (jobs were rerun >successsfully). >My question is should a problem of this nature occur again (pds migrated) how >can I force HSM to recall the dsn to the >original volume? In this case the >dsn was recalled to another volume other than the orginal. >Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
From: willie bunter > how can I force HSM to recall the dsn to the original volume? IIRC, if the datasets belongs to a SC whose Guaranteed Space = Yes, then hsm recalls the dataset on the same volume where the dataset originally was. Walter Marguccio z/OS Systems Programmer BELENUS LOB Informatic GmbH Munich - Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Program load processing
Thanks Paolo and Anthony...you both pointed me to the same book, and it is just what I needed! Have a great day! Billy On Thu, Mar 21, 2013 at 10:42 AM, Sambataro, Anthony (NIH/NBS) [E] < anthony.sambat...@nih.gov> wrote: > How about: > > http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsysprog/zsysprogc_searchorder.htm > > > -Original Message- > From: Bill Ashton [mailto:bill00ash...@gmail.com] > Sent: Thursday, March 21, 2013 10:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Program load processing > > Hi...I am having some discussions with an application programmer about how > programs are loaded and the search sequence - STEPLIB/JOBLIB/LNKLST, etc. > > Can someone point me to the IBM doc that spells this out clearly so I can > refer him and his teammates to the right place? > > Thank you and best regards, > *Billy Ashton* > > -- > 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 > -- Thank you and best regards, *Billy Ashton* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Health Checker for z/OS checks - to check or not to check, now is the..
Hello everyone! After using Health Checker for z/OS for several months now, I'm having doubts about some checks, so please feel free to comment :) Check: ASM_LOCAL_SLOT_USAGE Comment: This one pops up regularly on LPAR's with Websphere software. It's almost impossible to keep the usage below 30%. Documentation says: "To maximize the efficiency of ASM slot management, you should keep the slot usage on all local page data sets below 30%." We're using 4 page data sets in our test LPAR's, which are ~540k tracks. Adding additional is always an option, but is it worth it? Maybe to change the warning threshold? Thoughts? Check: GRS_CONVERT_RESERVES Comment: Still haven't used the GRS ENQ/DEQ/RESERVE Monitor to check what reserves our systems are using. I was wondering has anyone tried to convert all RESERVEs to ENQs? Were any applications problematic? Check: XCF_SIG_STR_SIZE Comment: This one just a raised a wonder in my head. It's not showing an exception rather a few warnings in the text of the check - that our signaling structures can't support the configuration specified with MAXSYSTEM. This is beacuse the sysplex where this occurs was big once, but now it's just a few LPARs. How could one reduce the MAXSYSTEM value while preserving other data in the CDSs? If I format a new CDS with a smaller MAXSYSTEM number, it won't play nice with the existing ones. Check: IXGLOGR_ENTRYTHRESHOLD Comment: Another "regular" check that pops up. Almost always from the RRS MAIN logstream. Whenever I see this, I check the CF structure which always shows around 40-60% entries in use. Also, the structure is stuck at the inital size and AUTOALTER is disabled (by some recommendation, I think..). Will RRS structure auto expand if needed without z/OS (AUTOALT) intervention? Any best practices to recommend here? Also, sometimes when I check the "Count" column in the checks text, it's empty (no number is shown), but the exception is there... O.o ? Check: RRS_MUROFFLOADSIZE Comment: This check warns that RRS MAIN offload data set isn't big enough to hold everything from the structure (which is a result of enlarging the structure). Solution is to update the LS_SIZE paramater, but I'm having problems with updating it while there are open connections to it (IXG014E by using IXCMIAPU). "Updating a log stream's attributes" from "Setting Up a Sysplex" says: "Pending updates will take effect at different points for each log stream attribute as follows: The LS-DATACLASS, LS_SIZE, LS_MGMTCLASS, and LS_STORCLASS attribute updates will remain pending until a new offload data set is allocated (data set switch event) or the subsequent first connection to the log stream." This seems just fine, but I'm getting an error, not a warning that the change will be effective upon the new offload data set allocation. What's wrong here? (LOGR CDS FORMAT LEVEL: HBB6603) Check: XCF_CDS_SPOF Comment: For this one, I just want to confirm my understanding of the messages. I'm seeing component indicators = 3000__ on all the messages which cause this check to generate a high severity (by default) exception. By checking the DOC APAR OA28958, it seems that indicator is telling me that IBM thinks owning a single book in the CEC is a single point of failure (well, it is in some way, but... hmh?). Am I reading this right? Adding a book is defenetly not an option, so if that is the case, this one will need to stay disabled. Thoughts and ideas welcome! Regards, IP -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DFHSM QUESTION - RECALLING DSN TO ITS ORIGINAL VOLUME
Good Day Readers, Several jobs are failing due to the following : IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01,SYS2.HESP.BPROCLIB IEF196I IEC143I 213-2C,IFG0194D,JES2,JES2,SYS00035-0009,9987,SMTP01, IEF196I SYS2.HESP.BPROCLIB $HASP307 HESPD01 UNABLE TO OPEN PROC02 IEFC452I HESPD01 - JOB NOT RUN - JCL ERROR The problem was caused by the library which was migrated by HSM was recalled to another volume - SMTP03. The volumes in this Storage Group are SMS managed. I was able to get our MVS support folks to refresh the JES2 proc which rectified the problem (jobs were rerun successsfully). My question is should a problem of this nature occur again (pds migrated) how can I force HSM to recall the dsn to the original volume? In this case the dsn was recalled to another volume other than the orginal. Thanks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Program load processing
How about: http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsysprog/zsysprogc_searchorder.htm -Original Message- From: Bill Ashton [mailto:bill00ash...@gmail.com] Sent: Thursday, March 21, 2013 10:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Program load processing Hi...I am having some discussions with an application programmer about how programs are loaded and the search sequence - STEPLIB/JOBLIB/LNKLST, etc. Can someone point me to the IBM doc that spells this out clearly so I can refer him and his teammates to the right place? Thank you and best regards, *Billy Ashton* -- 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: Program load processing
Bill, try this link: http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zsysprog/zsysprogc_searchorder.htm Paolo Cacciari Senior IT Specialist - Certified From: Bill Ashton To: IBM-MAIN@listserv.ua.edu Date: 21/03/2013 15:31 Subject:Program load processing Sent by:IBM Mainframe Discussion List Hi...I am having some discussions with an application programmer about how programs are loaded and the search sequence - STEPLIB/JOBLIB/LNKLST, etc. Can someone point me to the IBM doc that spells this out clearly so I can refer him and his teammates to the right place? Thank you and best regards, *Billy Ashton* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN IBM Italia S.p.A. Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI) Cap. Soc. euro 347.256.998,80 C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153 Società con unico azionista Società soggetta all?attività di direzione e coordinamento di International Business Machines Corporation (Salvo che sia diversamente indicato sopra / Unless stated otherwise above) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Program load processing
Hi...I am having some discussions with an application programmer about how programs are loaded and the search sequence - STEPLIB/JOBLIB/LNKLST, etc. Can someone point me to the IBM doc that spells this out clearly so I can refer him and his teammates to the right place? Thank you and best regards, *Billy Ashton* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Logrec Record increase on EMC VMAX 5876
We were at 5876.8? something and upgraded this past weekend to 5876.159 but we didn't see any big increase either this past weekend or when we went from 5875 to 5876. ddk I was so close. The level is 5876-159 That is what I get from doing it from memory. Lizette This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: exit add in progxx for cnz_wtomdbexit and setprog
Yes, very high level of amintenance RSU1301 z/OS 1.3 Bernard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
