Re: Questions regarding thruput expectations of CA-View(SAR)
Hi, I have used SAR at many sites and currently still do at several. If you are writing these all to the same SAR database, then you are not really going to get better throughput from a single SARSTC (archive task writer) than you will from 10 or 20 of them. They are writing to the same database, which is essentially a big sequential file with a INDEX file that indexes into that "database". What you can do is have multiple SAR database(s) and write the data to them individually. I'm surprised that CA didn't tell you this stuff already, but you can have each system write to it's own database. You can also create multiple extents for the index and database components, the first extent is what will be used for ENQ's so it can be small and should be on a separate (two) volumes. The databases are available cross-system to the viewer(s). Basically, you are just trying to let the archive tasks not have to compete with each other for access to the database portion. The Index is only necessary at the beginning and end of the extracts and is held briefly both times. If there is very high access, and you have a way to separate the data between them then completely separate database and indexes would be a great solution for this. i.e. have payroll stuff go to one and accounts payable go elsewhere. There are several ways to mitigate the issue, but in the end, the database is still a sequential file with an index into it. FSS collectors may not be a option for you, but if they are, you would get a small amount of relief. "The SARSTC task must complete archival of a SYSOUT before starting archival of the next sysout. The single threading can lead to a backlog of reports in the JES spool. To improve this situation, additional FSS/VIEW archiver collectors can be defined to JES to allow multiple SYSOUTs to be archived concurrently." In the install manual they also tell you about this problem: RESERVES are issued against both the first index extent and the first data extent; therefore, a review of local configurations is required. The product issues ENQs and RESERVEs as necessary to maintain the integrity of its data sets. The primary ENQ (QNAME=SARSTC) is used by the archival task to ensure that only one archival task starts using a specific database. The ENQ is defined as SYSTEMS which will be propagated to all LPARs in a PLEX. This queue name need not be defined to a system integrity product. A secondary ENQ (QNAME=SARPAC) is used by the tape consolidation utility SARPAC. This is also defined as SYSTEMS and need not be defined to a system integrity product. Convert all RESERVEs issued by CA View to global enqueues. Using RESERVE and ENQ The following table shows how CA View uses ENQ and RESERVE: QNAME Type Description Integrity Product Control SARSTC ENQ Restricts the CA View database to only one archival task NO SARPAC ENQ Restricts the CA View SARPAC utility to only one task at a time. NO SARACT RESERVE Serializes the updating of the CA View accounting file YES SARUPD RESERVE Serializes the updating of the CA View database and index YES any time you serialize something, only one will be able to update at a time. To take the star out of the issue, you can have only one JES do all of the updating, but having multiple database/index setups is a far better option. CA even makes a blanket statement on this in the reference: Run Multiple Archival Tasks Multiple archival tasks can be run at the same time; however, each task must use a different database. The archival task ENQs on the high-level qualifiers of the database name ensure that a different database is used. Important! For sites that have more than one processor, ensure that multiple archival tasks with the same database do not run at the same time on different processors. Otherwise, you can do permanent damage to the database. CA View prompts the operator for verification if another task with the same database is already executing on another processor. Meet the following requirements when running multiple archival tasks: • A different database is defined and used for each task • A different recovery file, if used, is defined and used for each task You don't have to worry about damage, because you have GRS up, but it still won't be fast to have them all go to the same place. Let me know if you have any more questions. Brian On Thu, 8 Apr 2021 02:10:25 +, A T & T Management wrote: > >Just some thoughts: You have 23 collectors and all are going to the same >dataset? How busy is the dataset? Also, how busy is the JES2 spool? Just >thinking 23 collectors, x number of jobs dumping in to the spool Wondering if >JES2 fencing would be beneficial? I.e. Creating a few more JES spools on >different volumes where jobs would be going to the various n
Re: STC JESYSMSG Quandry
ST shows more messages than O. Don't know if a logstream vs dasd would make a difference. On Wed, Apr 7, 2021 at 9:02 AM Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > > I might have forgotten to mention that after the STC ends, all of the > expected messages are in JESYSMSG, they're just not being shown in SDSF while > the STC is executing on this system where it is on other systems. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, April 7th, 2021 at 9:49 AM, Carmen Vitullo > wrote: > > > is IEFJOBS in use on one system and not on the other ? > > > > I see you said both 'generated' jobcards are the same, just a stretch here > > > > > > > > Carmen Vitullo > > > > -Original Message- > > > > From: Mark 0224d287a4b1-dmarc-requ...@listserv.ua.edu > > > > To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU > > > > Date: Wednesday, 7 April 2021 8:38 AM CDT > > > > Subject: Re: STC JESYSMSG Quandry > > > > I'm looking at that too. > > > > From the generated jobcard on the system that works. > > > > //XX JOB MSGLEVEL=1 > > > > And the on the system that doesn't. > > > > 1 //XX JOB MSGLEVEL=1 > > > > The internal text for the jobcard statement looks the same too. > > > > Still digging. > > > > Mark Jacobs > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Wednesday, April 7th, 2021 at 9:01 AM, Dana Mitchell mitchd...@gmail.com > > wrote: > > > > > In the description of msgIEFA111I it states: > > > > > > This message is only issued if MSGLEVEL=(,1) is in effect for this job. > > > > > > So if your JES STCCLASS is showing MSGLEVEL=(1,1), then perhaps somewhere > > > else is overriding MSGLEVEL. > > > > > > Dana > > > > > > On Tue, 6 Apr 2021 17:54:27 -0500, Mike Schwab mike.a.sch...@gmail.com > > > wrote: > > > > > > > Is the default MSGLEVEL different? > > > > > > 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 -- 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: IBM snew DOC Web SIte
Some more feedback for the Docs team: 1. Search is extremely slow. The search scope filter is missing. Assuming the web site is served from some *nix server, try using components from https://github.com/BurntSushi/ripgrep for fast search. 2. The index in the left takes ages to load. Try doing client-side assembly via WASM. I'm sure there'll be loads of great articles from one of the Firefox blogs on the technology and how to get started, etc. - KB ‐‐‐ Original Message ‐‐‐ On Tuesday, April 6, 2021 7:45 AM, kekronbekron wrote: > What would also be useful is a next/previous button at the top right & bottom > right of each Doc page. > 2 places because for pages that are long, one doesn't need to 'go to top'. > > - KB > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, April 6, 2021 7:38 AM, kekronbekron > 02dee3fcae33-dmarc-requ...@listserv.ua.edu wrote: > > > > Works ok for me. > > I should say, I do like the generous use of IBM Plex and the look of the > > site. > > Hope they get rid of the feedback banner at the bottom soon. > > Or at least make it an easy to use set of buttons in the footer (where > > language selection is). > > https://www.ibm.com/docs/en/cics-ts/5.2?topic=commands-cemt-perform-pipeline > > > > - KB > > ‐‐‐ Original Message ‐‐‐ > > On Tuesday, April 6, 2021 1:31 AM, esst...@juno.com esst...@juno.com > > wrote: > > > > > > > .HelloAnyone experiencing problems with IBMs new doc site ?.For > > > Example:If I google CICS PIPELINE SCAN , I am presented with many > > > references to documentation with "pipeline scan"If any of these > > > references invoke the old Knowledge Center, I am re-directed to a new IBM > > > doc site..However I am presented with a White Page, with no substance > > > ?.Anyone else getting this.Paul D'Angelo > > > 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: Questions regarding thruput expectations of CA-View(SAR)
Just some thoughts: You have 23 collectors and all are going to the same dataset? How busy is the dataset? Also, how busy is the JES2 spool? Just thinking 23 collectors, x number of jobs dumping in to the spool Wondering if JES2 fencing would be beneficial? I.e. Creating a few more JES spools on different volumes where jobs would be going to the various new spool datasets and jobs going ouot to the new JES2 spool datasets. I wonder if CA is using the new method of extracting spool datasets are in use or they doing their own, or perhaps using external writers to get the spool datasets? Scott On Wednesday, April 7, 2021, 8:36:50 PM EDT, Glenn Miller wrote: I have a few questions that I wanted to ask the group regarding their thruput expectations and experiences with the CA-View(SAR) software product. First, I should say that my customer has been using the CA-View(SAR) software product for a number of years and until recently has basically not had any complaints/issues. However, within the past few months, we consistently receive complaints that are basically saying..."CA-View(SAR) is slow" or "CA-View(SAR) is working as fast now as it used to be". These complaints are basically indicating that the CA-View(SAR) SYSOUT Collectors are not able to immediately "process" all of the SYSOUT from the JES2 Spool and store the output on the CA-View(SAR) disk database at "certain" timeframes. For example, last night they had a high-water mark of over 14,000 jobs in the JES2 SYSOUT Class that is used by the CA-View(SAR) SYSOUT Collectors. We have working with CA/Broadcom CA-View(SAR) support and as of this time, based on the data we have provided, they do not see any obvious areas of concern. Is it reasonable to expect the CA-View(SAR) SYSOUT Collectors to be able to "process" the SYSOUT from multiple hundreds of jobs per minute? Or is this an example of trying to shovel 10 pounds of "stuff" into a 1 pound can? After doing some investigation ourselves, we have found that during those peak timeframes that the CA-View(SAR) SYSOUT Collectors ( we have 23 of them running, all selecting SYSOUT from the same JES2 SYSOUT Class ) spend nearly the entire time ( in the very high 90's % ) waiting for the Global ENQ ( we are running GDPS Hyerswap, using GRS Star Mode ) for the resource "SARUPD" / "hlq.SARDBASE.I001". We are not experiencing other issues that would indicate that GRS is having any issues. A little information about the configuration of this environment. Three z13 machines, one Model 725, one Model 726, one Model 727 Three zEC12 external coupling facility machines One DS8886 (no flash storage) "GDPS Site 1" / One DS8886 (no flash storage) "GDPS Site 2" 10 way Sysplex / all z/OS V2R3 systems / 8 customer application z/OS systems / 2 GDPS z/OS systems The 23 CA-View(SAR) SYSOUT Collectors have always run on only 1 of the 8 customer application z/OS systems Any thoughts/ideas/experiences would be appreciated. Thank you in advance, Glenn Miller -- 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
Questions regarding thruput expectations of CA-View(SAR)
I have a few questions that I wanted to ask the group regarding their thruput expectations and experiences with the CA-View(SAR) software product. First, I should say that my customer has been using the CA-View(SAR) software product for a number of years and until recently has basically not had any complaints/issues. However, within the past few months, we consistently receive complaints that are basically saying..."CA-View(SAR) is slow" or "CA-View(SAR) is working as fast now as it used to be". These complaints are basically indicating that the CA-View(SAR) SYSOUT Collectors are not able to immediately "process" all of the SYSOUT from the JES2 Spool and store the output on the CA-View(SAR) disk database at "certain" timeframes. For example, last night they had a high-water mark of over 14,000 jobs in the JES2 SYSOUT Class that is used by the CA-View(SAR) SYSOUT Collectors. We have working with CA/Broadcom CA-View(SAR) support and as of this time, based on the data we have provided, they do not see any obvious areas of concern. Is it reasonable to expect the CA-View(SAR) SYSOUT Collectors to be able to "process" the SYSOUT from multiple hundreds of jobs per minute? Or is this an example of trying to shovel 10 pounds of "stuff" into a 1 pound can? After doing some investigation ourselves, we have found that during those peak timeframes that the CA-View(SAR) SYSOUT Collectors ( we have 23 of them running, all selecting SYSOUT from the same JES2 SYSOUT Class ) spend nearly the entire time ( in the very high 90's % ) waiting for the Global ENQ ( we are running GDPS Hyerswap, using GRS Star Mode ) for the resource "SARUPD" / "hlq.SARDBASE.I001". We are not experiencing other issues that would indicate that GRS is having any issues. A little information about the configuration of this environment. Three z13 machines, one Model 725, one Model 726, one Model 727 Three zEC12 external coupling facility machines One DS8886 (no flash storage) "GDPS Site 1" / One DS8886 (no flash storage) "GDPS Site 2" 10 way Sysplex / all z/OS V2R3 systems / 8 customer application z/OS systems / 2 GDPS z/OS systems The 23 CA-View(SAR) SYSOUT Collectors have always run on only 1 of the 8 customer application z/OS systems Any thoughts/ideas/experiences would be appreciated. Thank you in advance, Glenn Miller -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Ficon director and SAN switch
Hello We are in process of getting new virtual tape solution to replace an existing one. Solution is to get the channel connected to two ficon directors.and connect them virtual tape. So the question is instead of ficon director can we use the SAN switch ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STC JESYSMSG Quandry
No SPIN= anywhere and both STCs are started under JES2, not MSTR. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, April 7th, 2021 at 10:28 AM, Carmen Vitullo wrote: > I don't know of any JES2 exit that may display this action so I ask; > > > > No SPIN= for the DDNAME JES2MSGS? > > > > IIRC SUB=MSTR will not show any output because it was not submitted (started) > under the JES2 subsystem, I think the only way you'd see anything is after > the task has ended and only if your stcclass is set to not purge. > > > > Carmen Vitullo > > -Original Message- > > From: Mark 0224d287a4b1-dmarc-requ...@listserv.ua.edu > > To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU > > Date: Wednesday, 7 April 2021 9:02 AM CDT > > Subject: Re: STC JESYSMSG Quandry > > I might have forgotten to mention that after the STC ends, all of the > expected messages are in JESYSMSG, they're just not being shown in SDSF while > the STC is executing on this system where it is on other systems. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, April 7th, 2021 at 9:49 AM, Carmen Vitullo cvitu...@hughes.net > wrote: > > > is IEFJOBS in use on one system and not on the other ? > > > > I see you said both 'generated' jobcards are the same, just a stretch here > > > > Carmen Vitullo > > > > -Original Message- > > > > From: Mark 0224d287a4b1-dmarc-requ...@listserv.ua.edu > > > > To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU > > > > Date: Wednesday, 7 April 2021 8:38 AM CDT > > > > Subject: Re: STC JESYSMSG Quandry > > > > I'm looking at that too. > > > > From the generated jobcard on the system that works. > > > > //XX JOB MSGLEVEL=1 > > > > And the on the system that doesn't. > > > > 1 //XX JOB MSGLEVEL=1 > > > > The internal text for the jobcard statement looks the same too. > > > > Still digging. > > > > Mark Jacobs > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Wednesday, April 7th, 2021 at 9:01 AM, Dana Mitchell mitchd...@gmail.com > > wrote: > > > > > In the description of msgIEFA111I it states: > > > > > > This message is only issued if MSGLEVEL=(,1) is in effect for this job. > > > > > > So if your JES STCCLASS is showing MSGLEVEL=(1,1), then perhaps somewhere > > > else is overriding MSGLEVEL. > > > > > > Dana > > > > > > On Tue, 6 Apr 2021 17:54:27 -0500, Mike Schwab mike.a.sch...@gmail.com > > > wrote: > > > > > > > Is the default MSGLEVEL different? > > > > > > 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 > > > > 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: STC JESYSMSG Quandry
I don't know of any JES2 exit that may display this action so I ask; No SPIN= for the DDNAME JES2MSGS? IIRC SUB=MSTR will not show any output because it was not submitted (started) under the JES2 subsystem, I think the only way you'd see anything is after the task has ended and only if your stcclass is set to not purge. Carmen Vitullo -Original Message- From: Mark <0224d287a4b1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN Date: Wednesday, 7 April 2021 9:02 AM CDT Subject: Re: STC JESYSMSG Quandry I might have forgotten to mention that after the STC ends, all of the expected messages are in JESYSMSG, they're just not being shown in SDSF while the STC is executing on this system where it is on other systems. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, April 7th, 2021 at 9:49 AM, Carmen Vitullo wrote: > is IEFJOBS in use on one system and not on the other ? > > I see you said both 'generated' jobcards are the same, just a stretch here > > > > Carmen Vitullo > > -Original Message- > > From: Mark 0224d287a4b1-dmarc-requ...@listserv.ua.edu > > To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU > > Date: Wednesday, 7 April 2021 8:38 AM CDT > > Subject: Re: STC JESYSMSG Quandry > > I'm looking at that too. > > From the generated jobcard on the system that works. > > //XX JOB MSGLEVEL=1 > > And the on the system that doesn't. > > 1 //XX JOB MSGLEVEL=1 > > The internal text for the jobcard statement looks the same too. > > Still digging. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, April 7th, 2021 at 9:01 AM, Dana Mitchell mitchd...@gmail.com > wrote: > > > In the description of msgIEFA111I it states: > > > > This message is only issued if MSGLEVEL=(,1) is in effect for this job. > > > > So if your JES STCCLASS is showing MSGLEVEL=(1,1), then perhaps somewhere > > else is overriding MSGLEVEL. > > > > Dana > > > > On Tue, 6 Apr 2021 17:54:27 -0500, Mike Schwab mike.a.sch...@gmail.com > > wrote: > > > > > Is the default MSGLEVEL different? > > > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STC JESYSMSG Quandry
I might have forgotten to mention that after the STC ends, all of the expected messages are in JESYSMSG, they're just not being shown in SDSF while the STC is executing on this system where it is on other systems. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, April 7th, 2021 at 9:49 AM, Carmen Vitullo wrote: > is IEFJOBS in use on one system and not on the other ? > > I see you said both 'generated' jobcards are the same, just a stretch here > > > > Carmen Vitullo > > -Original Message- > > From: Mark 0224d287a4b1-dmarc-requ...@listserv.ua.edu > > To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU > > Date: Wednesday, 7 April 2021 8:38 AM CDT > > Subject: Re: STC JESYSMSG Quandry > > I'm looking at that too. > > From the generated jobcard on the system that works. > > //XX JOB MSGLEVEL=1 > > And the on the system that doesn't. > > 1 //XX JOB MSGLEVEL=1 > > The internal text for the jobcard statement looks the same too. > > Still digging. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, April 7th, 2021 at 9:01 AM, Dana Mitchell mitchd...@gmail.com > wrote: > > > In the description of msgIEFA111I it states: > > > > This message is only issued if MSGLEVEL=(,1) is in effect for this job. > > > > So if your JES STCCLASS is showing MSGLEVEL=(1,1), then perhaps somewhere > > else is overriding MSGLEVEL. > > > > Dana > > > > On Tue, 6 Apr 2021 17:54:27 -0500, Mike Schwab mike.a.sch...@gmail.com > > wrote: > > > > > Is the default MSGLEVEL different? > > > > 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
Re: STC JESYSMSG Quandry
Nope. Checked that too. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, April 7th, 2021 at 9:49 AM, Carmen Vitullo wrote: > is IEFJOBS in use on one system and not on the other ? > > I see you said both 'generated' jobcards are the same, just a stretch here > > > > Carmen Vitullo > > -Original Message- > > From: Mark 0224d287a4b1-dmarc-requ...@listserv.ua.edu > > To: IBM-MAIN IBM-MAIN@LISTSERV.UA.EDU > > Date: Wednesday, 7 April 2021 8:38 AM CDT > > Subject: Re: STC JESYSMSG Quandry > > I'm looking at that too. > > From the generated jobcard on the system that works. > > //XX JOB MSGLEVEL=1 > > And the on the system that doesn't. > > 1 //XX JOB MSGLEVEL=1 > > The internal text for the jobcard statement looks the same too. > > Still digging. > > Mark Jacobs > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, April 7th, 2021 at 9:01 AM, Dana Mitchell mitchd...@gmail.com > wrote: > > > In the description of msgIEFA111I it states: > > > > This message is only issued if MSGLEVEL=(,1) is in effect for this job. > > > > So if your JES STCCLASS is showing MSGLEVEL=(1,1), then perhaps somewhere > > else is overriding MSGLEVEL. > > > > Dana > > > > On Tue, 6 Apr 2021 17:54:27 -0500, Mike Schwab mike.a.sch...@gmail.com > > wrote: > > > > > Is the default MSGLEVEL different? > > > > 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
Re: STC JESYSMSG Quandry
is IEFJOBS in use on one system and not on the other ? I see you said both 'generated' jobcards are the same, just a stretch here Carmen Vitullo -Original Message- From: Mark <0224d287a4b1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN Date: Wednesday, 7 April 2021 8:38 AM CDT Subject: Re: STC JESYSMSG Quandry I'm looking at that too. >From the generated jobcard on the system that works. //XX JOB MSGLEVEL=1 And the on the system that doesn't. 1 //XX JOB MSGLEVEL=1 The internal text for the jobcard statement looks the same too. Still digging. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, April 7th, 2021 at 9:01 AM, Dana Mitchell wrote: > In the description of msgIEFA111I it states: > > This message is only issued if MSGLEVEL=(,1) is in effect for this job. > > So if your JES STCCLASS is showing MSGLEVEL=(1,1), then perhaps somewhere > else is overriding MSGLEVEL. > > Dana > > On Tue, 6 Apr 2021 17:54:27 -0500, Mike Schwab mike.a.sch...@gmail.com wrote: > > > Is the default MSGLEVEL different? > > 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: STC JESYSMSG Quandry
I'm looking at that too. >From the generated jobcard on the system that works. //XX JOB MSGLEVEL=1 And the on the system that doesn't. 1 //XX JOB MSGLEVEL=1 The internal text for the jobcard statement looks the same too. Still digging. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, April 7th, 2021 at 9:01 AM, Dana Mitchell wrote: > In the description of msgIEFA111I it states: > > This message is only issued if MSGLEVEL=(,1) is in effect for this job. > > So if your JES STCCLASS is showing MSGLEVEL=(1,1), then perhaps somewhere > else is overriding MSGLEVEL. > > Dana > > On Tue, 6 Apr 2021 17:54:27 -0500, Mike Schwab mike.a.sch...@gmail.com wrote: > > > Is the default MSGLEVEL different? > > 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
WAS Not Initializing
Hello all, I will preface this with I am no where near a WAS expert. We are having an issue starting WAS on z/OS on one LPAR. The last message we see in the server is BBOOO416I The Maximum Number of Worker Threads Is On the servlet address space the last message is BB24I Errors Will Be Written To x.ERROR.LOG. We then receive a bunch of BPXP018I Thread xxx In Process Without Being UNDUBBED - Completion Code 04EC3000 Reason Code 00080005. The address spaces are looping and taking up about 25% of the CPU. Any ideas are welcome! Thanks! Glenn Glenn Schneck USDC Manager 1 - GPS Deloitte Consulting LLP 901 International Parkway, STE 100 Lake Mary, FL 32746 Tel/Direct: +1 407-438-8809 | Fax: +1 866-396-3121 | Mobile: +1 321-279-3535 gschn...@deloitte.com| www.deloitte.com Please consider the environment before printing. This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. Deloitte refers to a Deloitte member firm, one of its related entities, or Deloitte Touche Tohmatsu Limited ("DTTL"). Each Deloitte member firm is a separate legal entity and a member of DTTL. DTTL does not provide services to clients. Please see www.deloitte.com/about to learn more. v.E.1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STC JESYSMSG Quandry
In the description of msgIEFA111I it states: This message is only issued if MSGLEVEL=(,1) is in effect for this job. So if your JES STCCLASS is showing MSGLEVEL=(1,1), then perhaps somewhere else is overriding MSGLEVEL. Dana On Tue, 6 Apr 2021 17:54:27 -0500, Mike Schwab wrote: >Is the default MSGLEVEL different? > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: STC JESYSMSG Quandry
if all the JES2 setting are identical, I'd start looking at the ALLOCxx member in use, I'm not sure there's a setting in that member to NOT display the IEFA111I message. Carmen Vitullo -Original Message- From: Mark <0224d287a4b1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN Date: Tuesday, 6 April 2021 6:24 PM CDT Subject: Re: STC JESYSMSG Quandry The system that is showing the output. $DSTCCLASS,LONG $HASP837 STCCLASS $HASP837 STCCLASS AUTH=(ALL),BLP=YES,COMMAND=EXECUTE, $HASP837 CONDPURG=NO,DSENQSHR=ALLOW,IEFUJP=YES, $HASP837 IEFUSO=YES,JESLOG=(NOSPIN),LOG=YES, $HASP837 MSGLEVEL=(1,1),MSGCLASS=A,OUTDISP=(HOLD,HOLD), $HASP837 OUTPUT=YES,PERFORM=000,PROMO_RATE=0, $HASP837 PROCLIB=00,QAFF=(ANY),REGION=0004M,SWA=ABOVE, $HASP837 TIME=(001440,00),TYPE26=YES,TYPE6=YES,DESC= $DOUTCLASS(A) $HASP842 OUTCLASS(A) $HASP842 OUTCLASS(A) OUTPUT=PRINT,BLNKTRNC=YES,COMPRESS=YES, $HASP842 OUTDISP=(HOLD,HOLD),TRKCELL=YES The system that isn't showing the output $dstcclass,long $HASP837 STCCLASS $HASP837 STCCLASS AUTH=(ALL),BLP=NO,COMMAND=EXECUTE, $HASP837 CONDPURG=NO,DSENQSHR=ALLOW,IEFUJP=YES, $HASP837 IEFUSO=YES,JESLOG=(NOSPIN),LOG=YES, $HASP837 MSGLEVEL=(1,1),MSGCLASS=K, $HASP837 OUTDISP=(HOLD,HOLD),OUTPUT=YES,PERFORM=000, $HASP837 PROMO_RATE=0,PROCLIB=00,QAFF=(ANY), $HASP837 REGION=K,SWA=ABOVE,TIME=(001440,00), $HASP837 TYPE26=YES,TYPE6=YES,DESC= $DOUTCLASS(K) $HASP842 OUTCLASS(K) $HASP842 OUTCLASS(K) OUTPUT=PRINT,BLNKTRNC=YES,COMPRESS=NO, $HASP842 OUTDISP=(HOLD,HOLD),TRKCELL=YES Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Tuesday, April 6th, 2021 at 6:54 PM, Mike Schwab wrote: > Is the default MSGLEVEL different? > > https://www.ibm.com/docs/en/zos/2.1.0?topic=mp-subparameter-definition-6 > > JOB statement MSGLEVEL=(1,1) should print everything. > > On Tue, Apr 6, 2021 at 2:34 PM Mark Jacobs > > 0224d287a4b1-dmarc-requ...@listserv.ua.edu wrote: > > > On one system (different JES2 MAS), our STCs while executing only show this > > line in SDSF. > > > > STMT NO. MESSAGE > > > > 2 IEFC001I PROCEDURE XX WAS EXPANDED USING SYSTEM LIBRARY > > ... > > > > But on other systems it's showing much more. > > > > STMT NO. MESSAGE > > > > 2 IEFC001I PROCEDURE X WAS EXPANDED USING SYSTEM LIBRARY .. > > > > IEF695I START XX WITH JOBNAME XX IS ASSIGNED TO USER A , GROUP > > B > > > > IEFA111I XX IS USING THE FOLLOWING JOB RELATED SETTINGS: > > > > SWA=ABOVE,TIOT SIZE=64K,DSENQSHR=DISALLOW,GDGBIAS=JOB > > > > and so on. > > > > I've looked at the obvious places, STCCLASS and its defaulted OUTCLASS and > > everything relevant seems the same. > > > > What am I missing? > > > > Mark Jacobs > > > > Sent from ProtonMail, Swiss-based encrypted email. > > > > GPG Public Key - > > https://api.protonmail.ch/pks/lookup?op=get&search=markjac...@protonmail.com > > > > > > 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 -- 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
Automatic ear deployment in WAS v9
Hello Group, We are in the process to implement automation in WAS v9 to deploy EAR file without any manual intervention. For this, we created monitored directory and enabled Global deployment option using WAS console. Now, we have couple of issues to be addressed. 1 ) How to update any application EAR file, which is already installed and running. I used below, config file for this. # # Header # #ResourceType=ApplicationDeployment #ResourceType=Application #ImplementingResourceType=Application #ResourceId=Cell=!{cellName}:Deployment=!{applicationName}:ApplicationDeployment= # # Header # ResourceType=ApplicationDeployment ImplementingResourceType=Application CreateDeleteCommandProperties=true ResourceId=Deployment=NbkAdapter37 # Properties Name=NbkAdapter37 Update=true operationType=update contentType=app contentFile=/was/profiles/MB_T4/temp/Package_ServerApp_4.7.8.ear useDefaultBindings=true #CreateDeleteCommandProperties=true #EnvironmentVariablesSection serverName=MBT4 But, system is not picking this new EAR file. 2) When we install new EAR file in this we like to create config file, which should handle class loader option, Shared Library reference, which Web Server to be mapped etc. I tried looking at various IBM manual, but couldn’t make this work. Can you please help. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Debugging "A high error rate was detected on the Optical Link network." HMC alert
Also eons ago, I had a customer trying to run PPRC cross-town at a speed above what the telco had given them. Still, it got me a trip and also our RMF SMF processing code that looks at path rates and response times. So it wasn't all bad. Oh, and a new, now recently retired :-), customer friend. Cheers, Martin Martin Packer WW z/OS Performance, Capacity and Architecture, IBM Technology Sales +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://mainframeperformancetopics.com Mainframe, Performance, Topics Podcast Series (With Marna Walle): https://anchor.fm/marna-walle Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: "Pommier, Rex" To: IBM-MAIN@LISTSERV.UA.EDU Date: 06/04/2021 23:55 Subject:Re: [External] Re: Debugging "A high error rate was detected on the Optical Link network." HMC alert Sent by:IBM Mainframe Discussion List Cables dirty - have you cleaned the ends of the cables and the FSPs? I see you have the Brocade negotiating down to 2 Gb to talk to the 6800. Can you try forcing the Brocade port to 2 Gb instead of using autonegotiate? I seem to recall eons ago having an issue on some HP equipment where we needed to force the port speeds instead of using auto to make it work. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Radoslaw Skorupka Sent: Tuesday, April 6, 2021 5:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Debugging "A high error rate was detected on the Optical Link network." HMC alert We've got it! "when it was connected to another mainframe, but it has it now" So something has changed. This is the most likely moment for error. Now it's time for investigation - what cable is new, what is old, what plug was inserted, etc. -- Radoslaw Skorupka (looking for new job) Lodz, Poland W dniu 06.04.2021 o 22:20, Christian Svensson pisze: > Hello, > > I understand that ideally I would find the error - but all the values seem > correct in my eyes. > The optical values are fine, no errors shown on the interfaces, etc. > > This bugs me a bit. I did not have this issue when it was connected to > another mainframe, but it has it now... > > Regards, > > On Tue, Apr 6, 2021 at 3:32 PM Radoslaw Skorupka > wrote: > >> You can disable that using HMC features (it is called Optical Network >> Errors or similar). >> However DON'T DO IT. >> This is symptom of some problem. It can be pinched FO cable, dirty >> connector or failing SFP module. >> Unfortunately it is almost good, so there is no simple way to know >> whether cable change helped or not. >> We like more consistent failures ;-) >> However I would start from visual inspection and then cable change. >> >> -- >> Radoslaw Skorupka >> (looking for new job) >> Lodz, Poland >> >> >> >> W dniu 05.04.2021 o 12:25, Christian Svensson pisze: >>> Good day, >>> >>> Recently I have been getting these kinds of alerts from my HMC. It all >>> started when I connected an old DS6800 and the details are: >>> >>> Node 1 >>> Machine: 2498-B40 >>> Serial: IBMCA107312B >>> Physical Interface: 6620 >>> Logical Interface: 0020 >>> >>> Node 2 >>> Machine: 1750-511 >>> Serial: IBM13715 >>> Physical Interface: 0100 >>> Logical Interface: >>> >>> I keep getting these errors about 3-4 per day with the exact same >>> interfaces specified. No others, just these. >>> >>> When I look at the referenced SAN switch and I do a "porterrshow" things >>> seem fine: >>> frames enccrccrctootoobadenc >> disc >>> link loss loss frjt fbsy c3timeoutpcs >>> tx rx inerrg_eof shrt long eof out c3 >>>failsync sig txrx err >>>20:4.8m 46.9k 0 0 0 0 0 0 0 0 >>> 0 2 2 0 0 0 0 0 >>>32: 27.5k 17.7k 0 0 0 0 0 0 0 0 >>> 0 0 0 0 0 0 0 0 >>>33: 19.3k 13.6k 0 0 0 0 0 0 0 0 >>> 0 0 1 0 0 0 0 0 >>>36: 78 79 0 0 0 0 0 0 0 0 >>> 0 0 1 1 0 0 0 0 >>>37: 56 57 0 0 0 0 0 0 0 0 >>> 0 0 0 1 0 0 0 0 >>> >>> I assume the interface given in the alert is in hex, so the error would >> be >>> about port 32 (which is indeed connected to the DS6800 controller 1, port >>> 0). >>> As you can see the port seems to be fine. >>> >>> The full portshow 32 is here: >>> portIndex: 32 >>> portName: port32 >>> portHealth: HEALTHY >>> >>> Authentication: None >>> portDisableReason: None >>> portCFlags: 0x1 >>> portFlags: 0x1020b03 PRESENT ACTIVE F_PORT G_PORT U_PORT >> LOGICAL_ONLINE >>> LOGIN NOELP ACCEPT F
Re: WAS v9 EAR Auto Deployment
Who is Kumar? :-) Seriously, you sent this to the IBM-MAIN newsgroup; I don't know if you intended to. Cheers, Martin Martin Packer WW z/OS Performance, Capacity and Architecture, IBM Technology Sales +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://mainframeperformancetopics.com Mainframe, Performance, Topics Podcast Series (With Marna Walle): https://anchor.fm/marna-walle Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: saurabh khandelwal To: IBM-MAIN@LISTSERV.UA.EDU Date: 07/04/2021 07:18 Subject:[EXTERNAL] WAS v9 EAR Auto Deployment Sent by:IBM Mainframe Discussion List Dear Kumar, We are in the process to implement automation in WAS v9 to deploy EAR file without any manual intervention. For this, we created monitored directory and enabled Global deployment option using WAS console. Now, we have couple of issues to be addressed. 1 ) How to update any application EAR file, which is already installed and running. I used below, config file for this. # # Header # #ResourceType=ApplicationDeployment #ResourceType=Application #ImplementingResourceType=Application #ResourceId=Cell=!{cellName}:Deployment=!{applicationName}:ApplicationDeployment= # # Header # ResourceType=ApplicationDeployment ImplementingResourceType=Application CreateDeleteCommandProperties=true ResourceId=Deployment=NbkAdapter37 # Properties Name=NbkAdapter37 Update=true operationType=update contentType=app contentFile=/was/profiles/MB_T4/temp/Package_ServerApp_4.7.8.ear useDefaultBindings=true #CreateDeleteCommandProperties=true #EnvironmentVariablesSection serverName=MBT4 But, system is not picking this new EAR file. 2) When we install new EAR file in this we like to create config file, which should handle class loader option, Shared Library reference, which Web Server to be mapped etc. I tried looking at various IBM manual, but couldn’t make this work. Can you please help. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN