Re: Questions regarding thruput expectations of CA-View(SAR)

2021-04-07 Thread Brian Westerman
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 

Re: STC JESYSMSG Quandry

2021-04-07 Thread Mike Schwab
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=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=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

2021-04-07 Thread kekronbekron
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)

2021-04-07 Thread A T & T Management
 
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)

2021-04-07 Thread Glenn Miller
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

2021-04-07 Thread Jake Anderson
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

2021-04-07 Thread Mark Jacobs
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=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=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=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

2021-04-07 Thread Carmen Vitullo
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=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=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

2021-04-07 Thread Mark Jacobs
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=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=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

2021-04-07 Thread Mark Jacobs
Nope. Checked that too.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=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=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

2021-04-07 Thread Carmen Vitullo
 

 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=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

2021-04-07 Thread Mark Jacobs
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=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

2021-04-07 Thread Schneck, Glenn
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

2021-04-07 Thread Dana Mitchell
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

2021-04-07 Thread Carmen Vitullo
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=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=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

2021-04-07 Thread saurabh khandelwal
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

2021-04-07 Thread Martin Packer
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 

Re: WAS v9 EAR Auto Deployment

2021-04-07 Thread Martin Packer
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


WAS v9 EAR Auto Deployment

2021-04-07 Thread saurabh khandelwal
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