I opened an SR. Problem is not so much whether HASPINDX is needed, but that the sudden need for it was unexpected and inexplicable. I spent a lot of time on this from Friday until this morning. A message would have saved KGs of grief.
. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mike Schwab Sent: Monday, April 11, 2016 1:29 PM To: [email protected] Subject: (External):Re: SDSF Mystery http://www-01.ibm.com/support/docview.wss?uid=isg1PM24416 For z/OS 1.11 and up, suggests leaving HASPINDX in case z/OS can't resolve the log. https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.isfa500/haspall.htm Sample job ISFISALC contains an allocation for the ISF.HASPINDX data set. Blocksize 4096 and CYL,5 should satisfy almost all systems. On Mon, Apr 11, 2016 at 1:01 PM, Mark Zelden <[email protected]> wrote: > On Mon, 11 Apr 2016 16:24:12 +0000, Jesse 1 Robinson > <[email protected]> wrote: > >>That's it! We recover only one member of a two member sysplex. >>Normally we use operlog, but the logstream did not get created on >>this IPL, so SDSF has to use syslog. I can now create the problem at >>will with 'SYSID missing-sys'. SYSID 'recovered-sys' goes right into syslog >>with no problem. >> >>Do I sniff an APAR here? Or does all this go away in z/OS 2.2? > > Sounds like an APAR to me. I don't recall any caveats documented when > the requirement for HASPINDX went away in z/OS 1.11. Seems to me that the > code is just going down a > path that wasn't accounted for when the requirement was removed. You > should just get the > "NO xxxx SYSLOG FOUND" message for the inactive member without SDSF > trying to allocate HASPINDX IMO, although I wouldn't be shocked if you > were told WAD if you open an SR since SDSF has no way of knowing the level of > an inactive member. > > The FM does say "it can be deleted": > > > SYSLOG > > Beginning with z/OS V1R11, SDSF uses a JES logical log to provide the > SYSLOG panel for JES2 and JES3 environments. SDSF does not use the HASPINDX > data set. > > For lower level systems, SDSF uses the HASPINDX data set for the SYSLOG panel. > Even with z/OS V1R11 and higher systems, it is possible to force the > use of HASPINDX, with the PROPERTY statement in ISFPARMS. However, you > should be aware that it is IBM's intention to eventually remove the > HASPINDX-based SYSLOG when all systems support the logical log. > > You can specify the system being processed with the SYSID command. > > > Logical Log > > The logical log removes constraints on the number of jobs and data > sets that can be indexed, and should result in better performance than > use of the HASPINDX data set. If you have only z/OS V1R11 or higher > systems in the MAS, you can delete any HASPINDX data sets. > > A SAF resource controls access to the JES logical log. The resource is > nodeid.+MASTER+.SYSLOG.SYSTEM.sysname in the JESSPOOL class. READ > access is required. This resource is in addition to the > ISFCMD.ODSP.SYSLOG resource in the SDSF class that was already used. > > > Best Regards, > > Mark > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL > v3 Foundation Certified mailto:[email protected] Mark's MVS Utilities: > http://www.mzelden.com/mvsutil.html > Systems Programming expert at > http://search390.techtarget.com/ateExperts/ 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 [email protected] with the message: INFO IBM-MAIN
