Re: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's
Thanks Kurt. This will be helpful as well. Ross > On Dec 15, 2023, at 9:52 AM, Kurt Quackenbush wrote: > > >> >> If he clones the existing target and dlib zones, updates the DDDEFs and >> receives the new version, will SMPE try to delete the old FMID and/or the >> contents of the existing libraries? > > Typically a new release of a product does delete the prior releases. If you > are careful to update all DDDEF entries in the new target and dlib zones to > point to the new target and dlib data sets, then you should be safe from > accidentally deleting the existing FMID in the existing data sets. But if > you are concerned then don't clone the existing target and dlib zones and > libraries; just create new, which should be about the same amount of work as > cloning, and the new product release I suspect supplies sample jobs to do > exactly that. > > Kurt Quackenbush > IBM | z/OS SMP/E and z/OSMF Software Management | ku...@us.ibm.com > > Chuck Norris never uses CHECK when he applies PTFs. > > -- > 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: SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's
Thanks for the info Tom. I had planned to use the ZONEEDIT to update my DDDEFs as well, so thanks for that confirmation. Ross > On Dec 14, 2023, at 12:44 PM, Tom Marchant > <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > > I should have added that when I clone zones, I like to copy the SMPLOG as > well, so that the full history is preserved. Don't forget to define the > disposition for SMPLOG as MOD or the SMPLOG will be useless. > > -- > Tom Marchant > > On Thu, 14 Dec 2023 12:31:15 -0600, Tom Marchant > wrote: > >> Create a new ZONEINDEX in the Global zone for each new zone (target and >> DLIB), and relate them to each other. >> >> If each zone is in its own CSI you can copy with IDCAMS REPRO. Otherwise use >> ZONECOPY. >> >> You can use ZONEEDIT to change the DDDEFs in your new zone(s). Don't forget >> that the target zone needs the DLIB data sets, must have their own SMPLTS, >> SMPMTS, SMPSTS, SMPSCDS. These can also be defined to your DLIB zone. IIRC, >> only the SCDS is required in the DLIB zone. >> >> Your target and DLIB zones will need DDDEFs for the SMPPTS >> >> Be careful that you have not left any DDDEFs pointing to the previous zone's >> data sets. >> >> -- >> Tom Marchant >> >> On Thu, 14 Dec 2023 11:27:16 -0600, Ross Vaughn >> wrote: >> >>> I’m upgrading a product in my DB2v13 global zone. I plan to use my >>> existing target & DLIB zones and just update my DDDEFs to point to my new >>> dataset names. >>> My question is - if I want to create new CSI’s (copied from my existing >>> CSIs) for the target & DLIB what’s the best way to point the target & DLIB >>> to those new CSI’s? My thought is using new CSI’s would allow me to keep >>> the previous FMID around if I needed it for any reason. >>> >>> Thanks, >>> Ross Vaughn >>> OneMain Financial >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMP/E - Pointing Existing TARG & DLIB Zones To New CSI's
I’m upgrading a product in my DB2v13 global zone. I plan to use my existing target & DLIB zones and just update my DDDEFs to point to my new dataset names. My question is - if I want to create new CSI’s (copied from my existing CSIs) for the target & DLIB what’s the best way to point the target & DLIB to those new CSI’s? My thought is using new CSI’s would allow me to keep the previous FMID around if I needed it for any reason. Thanks, Ross Vaughn OneMain Financial -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Z skills training
Our shop is looking for some Z skills training specifically around storage and SMS. We are having difficulty finding companies who can offer the training. I’ve inquired with ProTech and ZCubed but they don’t have enough interest to offer courses in the near future. Anyone have suggestions what other companies might be a good alternative? Thanks, Ross Vaughn OneMain Financial -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Moving/Merging Zones Into A New CSI
Thanks Kurt. Yes, sorry I failed to mention that I ran a ZONEIMPORT as well and copied over the v12 libraries and restored them with new names. > On Jun 29, 2023, at 8:55 AM, Kurt J. Quackenbush wrote: > >> I backed up and restored the new v13 CSI to a ‘test’ CSI…ran a ZONEEDIT and >> pointed my DDDEFs to test datasets etc.… >> Then Ran ZONEEXPORTS for a TARGET & DLIB from my current v12 CSI >> Ran ZONEEDITs to update those DDDEFs >> Ran a GZONEMERGE to copy over the associated FMIDs to the GLOBAL zone for >> the product I’m moving using ‘CONTENT’ and ‘FORFMID’ > > If the subject target a dlib zones are not physically in their own CSI data > sets, then yes, that sounds about right although your steps are little bit > vague. For example, you didn't mention it, but I assume you ran the > corresponding ZONEIMPORTs for the ZONEEXPORTs. Also, you ran ZONEEDIT to > update the DDDEF entries? Did you copy the target and distribution libraries > from your V12 environment and give them new names? > > Kurt Quackenbush > IBM | z/OS SMP/E and z/OSMF Software Management | ku...@us.ibm.com > > Chuck Norris never uses CHECK when he applies PTFs. > > -- > 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
Moving/Merging Zones Into A New CSI
We are in the process of upgrading Db2v12 to Db2v13. I am looking for suggestions/best practice for moving additional Target & DLIB zones from our Db2v12 CSI to our new Db2v13 CSI. To test this out I backed up and restored the new v13 CSI to a ‘test’ CSI…ran a ZONEEDIT and pointed my DDDEFs to test datasets etc.…Then Ran ZONEEXPORTS for a TARGET & DLIB from my current v12 CSI Ran ZONEEDITs to update those DDDEFs Ran a GZONEMERGE to copy over the associated FMIDs to the GLOBAL zone for the product I’m moving using ‘CONTENT’ and ‘FORFMID’ Is this the best approach? Am I missing anything? Thanks, Ross Vaughn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Missing Values For The 'SDSF DA' Panels - z/OS 2.5
Hi Rob, I opened a case with IBM but they are referring me to Rocket support for SDSF. So we will open a case there Rocket as well. We did not include any of the SYS1.SGRB* datasets into our LPA, APF, LINKLIST etc. because we didn't think we needed the z/OS Data Gatherer piece and we're not licensed for the advanced piece of it. Tried adding the SYS1.SERBLNKE to our APF & LNKLST but no change. We run CMF only. No RMF in our shop. Thanks, Ross Vaughn > On Feb 3, 2023, at 2:54 AM, Rob Scott wrote: > > Ross, > > First of all, I am glad you have opened a support case for this, our support > team should be able to gather further diagnostic information to resolve the > problem. > > A bit of background information for the archives : > > (o) In z/OS 2.4+, the SDSF "DA" information is gathered centrally by a > subtask in the SDSFAUX address space. > (o) This subtask uses the RMF programming service ERBSMFI (GRBSMFI) to > collect this information and any ISV product that replaces RMF supplies an > alias for this module. > (o) The SDSFAUX address space dumps the first 256 bytes of the ERBSMFI load > module in the HSFTRACE DD that is allocated to the SDSF started task > (o) When the RMF address space is not active, ERBSMFI still returns the data > we require (SMF 79-1 records), however in our experience other ISV products > do not return data when their STC is inactive and instead pass back a > non-zero return code. As a customer for an ISV that replaces RMF, you might > want to consider raising an RFE with them to address this. > (o) When we get a non-zero return code from ERBSMFI for 79-1 data, we > fallback to our own internal data collector (HSFSMFI) that builds pseudo 79-1 > records that reflect the columns that SDSF used to display prior to using > ERBSMFI (many years ago). The SDSF client code will detect this condition and > the number of columns shown on the DA panel will be greatly reduced from > "full-RMF" function. > (o) Error conditions calling ERBSMFI are normally reflected either by > WTO-style messages and/or messages written to the HSFLOG DD that is allocated > to the SDSF started task. > (o) Other SDSF panels that depend on ERBSMFI include DEV and PAG, however > they do not have internal fallback capability. > > Rob Scott > Rocket Software > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Ross Vaughn > Sent: 03 February 2023 04:07 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Missing Values For The 'SDSF DA' Panels - z/OS 2.5 > > EXTERNAL EMAIL > > > > > > We are currently in the process of rolling out z/OS 2.5 and have hit an issue > on a test LPAR that is not displaying any information in the SDSF DA panels. > There are no messages in the syslog out of the IPL that would lead us in a > certain direction. We think we may have an issue with CMF but can’t confirm. > We are occasionally seeing error messages out of SDSFAUX as well. > > It looks like beginning with z/OS 2.4 the ’SDSF DA’ information is obtained > by the SDSFAUX address space calling the BMC AMI Ops Monitor for CMF. We > have verified we have the CX10GVID module in our linklist library that CMF > uses to obtain the SDSF DA values. > We have a ticket open with support as well, but curious if anyone has seen > similar issues when rolling out z/OS 2.5? Same LPAR on z/OS 2.4 does not > have the same issue. > > Thanks, > Ross > > > > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ > Main Office Toll Free Number: +1 855.577.4323 > Contact Customer Support: > https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport > Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - > http://www.rocketsoftware.com/manage-your-email-preferences > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Missing Values For The 'SDSF DA' Panels - z/OS 2.5
We are currently in the process of rolling out z/OS 2.5 and have hit an issue on a test LPAR that is not displaying any information in the SDSF DA panels. There are no messages in the syslog out of the IPL that would lead us in a certain direction. We think we may have an issue with CMF but can’t confirm. We are occasionally seeing error messages out of SDSFAUX as well. It looks like beginning with z/OS 2.4 the ’SDSF DA’ information is obtained by the SDSFAUX address space calling the BMC AMI Ops Monitor for CMF. We have verified we have the CX10GVID module in our linklist library that CMF uses to obtain the SDSF DA values. We have a ticket open with support as well, but curious if anyone has seen similar issues when rolling out z/OS 2.5? Same LPAR on z/OS 2.4 does not have the same issue. Thanks, Ross -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
INTERNAL Cancel Command
> > I am trying to track down what or who issued a cancel command for a job. The > syslog indicates an INTERNAL command was issued by “Operator” according to > the MVS Planning Operations book. Is there specific SMF records I can look > at to see what the INTERNAL really means? > >> >> >> The ‘NC’ at the beginning of the SYSLOG record indicates N-Single Line >> MessageC-command issued by operator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
