I'm just upgrading a few old CICS Regions from 4.1.0 to TS 1.3, at start up i am getting the message below, I have checked the STEPLIB'd libraries are APF auth'd so can someone push me in the right direction here ...have a feeling it has something to do with PLT from distant memories.. 


IEF188I PROBLEM PROGRAM ATTRIBUTES ASSIGNED
+DFHKE0101 DBDCCICS DFHSIP IS NOT APF-AUTHORIZED. CICS WILL TERMINATE.
-YCICSBOL CICS     YCICSBOL    12     70     .0     .0     .1     81   0      0      0      0     0

Thanks

Stewart

*************************************
Stewart Herd
CICS/MQ Systems Programmer
Perot Systems
Cabinteley, Dublin 18, Ireland.
E-mail: [log in to unmask]
Phone: +353 1 217 7000  Ext 2692
Mobile; 00 44 7976 753521
*************************************



********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please
notify us immediately at [log in to unmask] and delete this E-mail
from your system. Thank you.
It is possible for data transmitted by email to be deliberately or
accidentally corrupted or intercepted. For this reason, where the
communication is by email, the Bank of Ireland Group does not accept
any responsibility for any breach of confidence which may arise
through the use of this medium.
This footnote also confirms that this email message has been swept
for the presence of known computer viruses.
********************************************************************

------_=_NextPart_001_01C150D8.75227EBC-- ========================================================================Date: Tue, 9 Oct 2001 10:49:26 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Elliott, Brian" <[log in to unmask]> Subject: Re: DFHKE0101 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit It looks like your assembled SIT table's load module is not in the STEPLIB concatenation... Brian Elliott TSG-CICS/MQ Series West Affiliated Computer Services Phone: 615-221-0801 E-Mail: [log in to unmask] or [log in to unmask] -----Original Message----- From: Stewart Herd [mailto:[log in to unmask]] Sent: Tuesday, October 09, 2001 10:39 AM To: [log in to unmask] Subject: DFHKE0101 I'm just upgrading a few old CICS Regions from 4.1.0 to TS 1.3, at start up i am getting the message below, I have checked the STEPLIB'd libraries are APF auth'd so can someone push me in the right direction here ...have a feeling it has something to do with PLT from distant memories.. IEF188I PROBLEM PROGRAM ATTRIBUTES ASSIGNED +DFHKE0101 DBDCCICS DFHSIP IS NOT APF-AUTHORIZED. CICS WILL TERMINATE. -YCICSBOL CICS YCICSBOL 12 70 .0 .0 .1 81 0 0 0 0 0 Thanks Stewart ************************************* Stewart Herd CICS/MQ Systems Programmer Perot Systems Cabinteley, Dublin 18, Ireland. E-mail: [log in to unmask] Phone: +353 1 217 7000 Ext 2692 Mobile; 00 44 7976 753521 ************************************* ******************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify us immediately at [log in to unmask] and delete this E-mail from your system. Thank you. It is possible for data transmitted by email to be deliberately or accidentally corrupted or intercepted. For this reason, where the communication is by email, the Bank of Ireland Group does not accept any responsibility for any breach of confidence which may arise through the use of this medium. This footnote also confirms that this email message has been swept for the presence of known computer viruses. ******************************************************************** ========================================================================Date: Tue, 9 Oct 2001 10:53:59 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Chase, John" <[log in to unmask]> Subject: Re: DFHKE0101 MIME-Version: 1.0 Content-Type: text/plain On Tuesday, October 09, 2001 10:49 AM, Elliott, Brian wrote: > It looks like your assembled SIT table's load module is not in the > STEPLIB concatenation... ... or the loadlib in which your DFHSIT resides is not APF-authorized. Remember that *any* non-APF-authorized library in the //STEPLIB concatenation will negate the APF authorization for *every* library in the //STEPLIB concatenation for "this" job. -jc- ========================================================================Date: Tue, 9 Oct 2001 11:02:21 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Matthew Stitt <[log in to unmask]> Organization: Huntsville Hospital Subject: Re: DFHKE0101 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C9153DE383C6EE7F20AF1DED" --------------C9153DE383C6EE7F20AF1DED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Check your STEPLIB concatenation. Make sure that ALL libraries specified in concatenation are authorized. Make sure the dataset name and volume are correct as specified in the APF list of PROGxx or IEAAPFxx. Add the missing ones. Stewart Herd wrote: > > > I'm just upgrading a few old CICS Regions from 4.1.0 to TS 1.3, at > start up i am getting the message below, I have checked the STEPLIB'd > libraries are APF auth'd so can someone push me in the right direction > here ...have a feeling it has something to do with PLT from distant > memories.. > > IEF188I PROBLEM PROGRAM ATTRIBUTES ASSIGNED > +DFHKE0101 DBDCCICS DFHSIP IS NOT APF-AUTHORIZED. CICS WILL TERMINATE. > > -YCICSBOL CICS YCICSBOL 12 70 .0 .0 .1 81 > 0 0 0 0 0 > > Thanks > > Stewart > > ************************************* > Stewart Herd > CICS/MQ Systems Programmer > Perot Systems > Cabinteley, Dublin 18, Ireland. > E-mail: [log in to unmask] > Phone: +353 1 217 7000 Ext 2692 > Mobile; 00 44 7976 753521 > ************************************* > > > ******************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify us immediately at [log in to unmask] and delete this E-mail > from your system. Thank you. > It is possible for data transmitted by email to be deliberately or > accidentally corrupted or intercepted. For this reason, where the > communication is by email, the Bank of Ireland Group does not accept > any responsibility for any breach of confidence which may arise > through the use of this medium. > This footnote also confirms that this email message has been swept > for the presence of known computer viruses. > ******************************************************************** > --------------C9153DE383C6EE7F20AF1DED Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Check your STEPLIB concatenation.  Make sure that ALL libraries specified in concatenation are authorized.  Make sure the dataset name and volume are correct as specified in the APF list of PROGxx or IEAAPFxx.  Add the missing ones.

Stewart Herd wrote:

 

I'm just upgrading a few old CICS Regions from 4.1.0 to TS 1.3, at start up i am getting the message below, I have checked the STEPLIB'd libraries are APF auth'd so can someone push me in the right direction here ...have a feeling it has something to do with PLT from distant memories..

IEF188I PROBLEM PROGRAM ATTRIBUTES ASSIGNED
+DFHKE0101 DBDCCICS DFHSIP IS NOT APF-AUTHORIZED. CICS WILL TERMINATE.
-YCICSBOL CICS     YCICSBOL    12     70     .0     .0     .1     81   0      0      0      0     0

Thanks

Stewart

*************************************
Stewart Herd
CICS/MQ Systems Programmer
Perot Systems
Cabinteley, Dublin 18, Ireland.
E-mail: [log in to unmask]
Phone: +353 1 217 7000  Ext 2692
Mobile; 00 44 7976 753521
*************************************
 

********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please
notify us immediately at [log in to unmask] and delete this E-mail
from your system. Thank you.
It is possible for data transmitted by email to be deliberately or
accidentally corrupted or intercepted. For this reason, where the
communication is by email, the Bank of Ireland Group does not accept
any responsibility for any breach of confidence which may arise
through the use of this medium.
This footnote also confirms that this email message has been swept
for the presence of known computer viruses.
********************************************************************
 

--------------C9153DE383C6EE7F20AF1DED-- ========================================================================Date: Tue, 9 Oct 2001 17:01:30 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Stewart Herd <[log in to unmask]> Subject: Re: DFHKE0101 Mime-Version: 1.0 Content-Type: multipart/alternative ; boundary="----_=_NextPart_001_01C150DB.A9A3A5BE" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C150DB.A9A3A5BE Content-Type: text/plain; charset="windows-1252" Thanks folks...appreciate it... ************************************* Stewart Herd CICS/MQ Systems Programmer Perot Systems Cabinteley, Dublin 18, Ireland. E-mail: [log in to unmask] Phone: +353 1 217 7000 Ext 2692 Mobile; 00 44 7976 753521 ************************************* -----Original Message----- From: Chase, John [mailto:[log in to unmask]] Sent: 09 October 2001 16:54 To: [log in to unmask] Subject: Re: DFHKE0101 On Tuesday, October 09, 2001 10:49 AM, Elliott, Brian wrote: > It looks like your assembled SIT table's load module is not in the > STEPLIB concatenation... ... or the loadlib in which your DFHSIT resides is not APF-authorized. Remember that *any* non-APF-authorized library in the //STEPLIB concatenation will negate the APF authorization for *every* library in the //STEPLIB concatenation for "this" job. -jc- ******************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify us immediately at [log in to unmask] and delete this E-mail from your system. Thank you. It is possible for data transmitted by email to be deliberately or accidentally corrupted or intercepted. For this reason, where the communication is by email, the Bank of Ireland Group does not accept any responsibility for any breach of confidence which may arise through the use of this medium. This footnote also confirms that this email message has been swept for the presence of known computer viruses. ******************************************************************** ------_=_NextPart_001_01C150DB.A9A3A5BE Content-Type: text/html; charset="windows-1252" RE: DFHKE0101

Thanks folks...appreciate it...

*************************************
Stewart Herd
CICS/MQ Systems Programmer
Perot Systems
Cabinteley, Dublin 18, Ireland.
E-mail: [log in to unmask]
Phone: +353 1 217 7000  Ext 2692
Mobile; 00 44 7976 753521
*************************************


-----Original Message-----
From: Chase, John [mailto:[log in to unmask]]
Sent: 09 October 2001 16:54
To: [log in to unmask]
Subject: Re: DFHKE0101


On Tuesday, October 09, 2001 10:49 AM, Elliott, Brian wrote:
> It looks like your assembled SIT table's load module is not in the
> STEPLIB concatenation...

... or the loadlib in which your DFHSIT resides is not APF-authorized.
Remember that *any* non-APF-authorized library in the //STEPLIB
concatenation will negate the APF authorization for *every* library in the
//STEPLIB concatenation for "this" job.

    -jc-



********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please
notify us immediately at [log in to unmask] and delete this E-mail
from your system. Thank you.
It is possible for data transmitted by email to be deliberately or
accidentally corrupted or intercepted. For this reason, where the
communication is by email, the Bank of Ireland Group does not accept
any responsibility for any breach of confidence which may arise
through the use of this medium.
This footnote also confirms that this email message has been swept
for the presence of known computer viruses.
********************************************************************

------_=_NextPart_001_01C150DB.A9A3A5BE-- ========================================================================Date: Tue, 9 Oct 2001 17:08:59 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Vitor Romao <[log in to unmask]> Subject: Program to get the jobname and the stepname MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C150DC.B46D3E50" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C150DC.B46D3E50 Content-Type: text/plain; charset="windows-1252" Does anyone have a batch program in COBOL or Assembler to get the jobname and the Stepname ??? ------_=_NextPart_001_01C150DC.B46D3E50 Content-Type: text/html; charset="windows-1252" RE: DFHKE0101
Does anyone  have a batch program in COBOL or Assembler to get the jobname and the Stepname ???
 
 
   
------_=_NextPart_001_01C150DC.B46D3E50-- ========================================================================Date: Tue, 9 Oct 2001 12:23:58 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: [log in to unmask] Subject: Re: Program to get the jobname and the stepname MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Vitor, Use the MVS "EXTRACT" Macro. Example : TIOTADDR DS F REGSAVE DS F JOBINFO DS CL24 EXTRACT TIOTADDR,'S',FIELDS=TIOT ST R7,REGSAVE L R7,TIOTADDR MVC JOBINFO,0(R7) L R7,REGSAVE The order of the fields loaded into JOBINFO are ===> JOBNAME, PROCSTEP NAME and STEP NAME. Each field is 8-bytes long. HTH.... Bill Vitor Romao [log in to unmask] NCOBPI.PT> cc: Sent by: CICS List Subject: Program to get the jobname and the <[log in to unmask] stepname DU> 10/09/2001 12:08 PM Please respond to CICS List Does anyone have a batch program in COBOL or Assembler to get the jobname and the Stepname ??? ========================================================================Date: Tue, 9 Oct 2001 11:45:58 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: [log in to unmask] Subject: Re: Program to get the jobname and the stepname MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Vitor, you need a Exit Program ===================Fernando Morote Arista Soporte Técnico Anexo 133-245 Vitor Romao [log in to unmask] NCOBPI.PT> cc: Subject: Program to get the jobname and 09/10/2001 11:08 a.m. the stepname Please respond to CICS List Does anyone have a batch program in COBOL or Assembler to get the jobname and the Stepname ??? ========================================================================Date: Tue, 9 Oct 2001 11:31:34 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Thompson, William (DISA Oklahoma City)" <[log in to unmask]> Subject: Re: Program to get the jobname and the stepname MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" This is working in batch to collect info for my EXCI connection to CICS.... 008100*==============================================================* 008200* Initialise job specific information * 008300*==============================================================* 008400* 008500 01 Job-Information. 008600 03 Job-Name Pic x(8). 008700 03 Proc-Step Pic x(8). 008800 03 Step-Name Pic x(8). 008900 03 Job-Number Pic x(8). 009000 03 Program-Name Pic x(8). 009100* 009200 linkage section. 009300* 009400 01 cb1. 009500 05 ptr1 Pointer Occurs 256. 009600 01 cb2. 009700 05 ptr2 Pointer Occurs 256. 009800* 009900 01 Null-ptr usage is Pointer. 010000* 018600*==============================================================* 018700* Initialise job specific information * 018800*==============================================================* 018900 Job-Specific-Info. 019000* PSA 019100 SET Address of cb1 to null. 019200* TCB 019300 SET Address of cb1 to ptr1(136). 019400* TIOT 019500 SET Address of cb2 to ptr1(4). 019600 MOVE Cb2(1:8) to Job-Name. 019700 MOVE Cb2(9:8) to Proc-Step. 019800 MOVE Cb2(17:8) to Step-Name. 019900* JSCB 020000 SET Address of cb2 to ptr1(46). 020100 MOVE cb2(361:8) to program-name. 020200* SSIB 020300 SET Address Of cb2 To ptr2(80). 020400 MOVE cb2(13:8) To job-number. -----Original Message----- From: Vitor Romao [mailto:[log in to unmask]] Sent: Tuesday, October 09, 2001 11:09 AM To: [log in to unmask] Subject: Program to get the jobname and the stepname Does anyone have a batch program in COBOL or Assembler to get the jobname and the Stepname ??? ========================================================================Date: Tue, 9 Oct 2001 13:04:30 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: [log in to unmask] Subject: Re: Program to get the jobname and the stepname MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Bill, I see Gilbert's program has made the rounds ;o) Bill O. "Thompson, William (DISA To: [log in to unmask] Oklahoma City)" cc: <[log in to unmask] Subject: Re: Program to get the jobname and DISA.MIL> the stepname Sent by: CICS List 10/09/2001 12:31 PM Please respond to CICS List This is working in batch to collect info for my EXCI connection to CICS.... 008100*==============================================================* 008200* Initialise job specific information * 008300*==============================================================* 008400* 008500 01 Job-Information. 008600 03 Job-Name Pic x(8). 008700 03 Proc-Step Pic x(8). 008800 03 Step-Name Pic x(8). 008900 03 Job-Number Pic x(8). 009000 03 Program-Name Pic x(8). 009100* 009200 linkage section. 009300* 009400 01 cb1. 009500 05 ptr1 Pointer Occurs 256. 009600 01 cb2. 009700 05 ptr2 Pointer Occurs 256. 009800* 009900 01 Null-ptr usage is Pointer. 010000* 018600*==============================================================* 018700* Initialise job specific information * 018800*==============================================================* 018900 Job-Specific-Info. 019000* PSA 019100 SET Address of cb1 to null. 019200* TCB 019300 SET Address of cb1 to ptr1(136). 019400* TIOT 019500 SET Address of cb2 to ptr1(4). 019600 MOVE Cb2(1:8) to Job-Name. 019700 MOVE Cb2(9:8) to Proc-Step. 019800 MOVE Cb2(17:8) to Step-Name. 019900* JSCB 020000 SET Address of cb2 to ptr1(46). 020100 MOVE cb2(361:8) to program-name. 020200* SSIB 020300 SET Address Of cb2 To ptr2(80). 020400 MOVE cb2(13:8) To job-number. -----Original Message----- From: Vitor Romao [mailto:[log in to unmask]] Sent: Tuesday, October 09, 2001 11:09 AM To: [log in to unmask] Subject: Program to get the jobname and the stepname Does anyone have a batch program in COBOL or Assembler to get the jobname and the Stepname ??? ========================================================================Date: Tue, 9 Oct 2001 12:06:38 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Thompson, William (DISA Oklahoma City)" <[log in to unmask]> Subject: Re: Program to get the jobname and the stepname MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" You bet...When it works, why re-invent it...but (somewhat embarrassed), I will update the program using it to back reference the original author..... -----Original Message----- From: [log in to unmask] [mailto:[log in to unmask]] Sent: Tuesday, October 09, 2001 12:05 PM To: [log in to unmask] Subject: Re: Program to get the jobname and the stepname Bill, I see Gilbert's program has made the rounds ;o) Bill O. snip ========================================================================Date: Tue, 9 Oct 2001 18:21:13 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Vitor Romao <[log in to unmask]> Subject: Re: Program to get the jobname and the stepname MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Fantastic, it work's Thank's everybody -----Original Message----- From: Thompson, William (DISA Oklahoma City) [mailto:[log in to unmask]] Sent: Terça-feira, 9 de Outubro de 2001 18:07 To: [log in to unmask] Subject: Re: Program to get the jobname and the stepname You bet...When it works, why re-invent it...but (somewhat embarrassed), I will update the program using it to back reference the original author..... -----Original Message----- From: [log in to unmask] [mailto:[log in to unmask]] Sent: Tuesday, October 09, 2001 12:05 PM To: [log in to unmask] Subject: Re: Program to get the jobname and the stepname Bill, I see Gilbert's program has made the rounds ;o) Bill O. snip ========================================================================Date: Tue, 9 Oct 2001 10:16:13 -0700 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Millie Rivero <[log in to unmask]> Subject: Forward Recovery Logs Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii I was given the task of transmitting the forward recovery logs from our TS regions to off-site storage several times a day, so in case of a disaster we can recover the system from the nightly backups plus the transmitted logs. We do this with our 4.1 journals but I'm not sure how to accomplish the same thing with the TS logs. Can anyone out there doing this type of thing give me some ideas ? Thanks. ========================================================================Date: Tue, 9 Oct 2001 13:35:15 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Williams, Dave" <[log in to unmask]> Subject: Is there a similar List .... MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" For MQSeries? If someone has the name, I'd appreciate it. Thanks! Dave [log in to unmask] ========================================================================Date: Tue, 9 Oct 2001 10:59:12 -0700 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Lesseg, Jon" <[log in to unmask]> Subject: Re: Is there a similar List .... MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C150EC.1A3FB050" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C150EC.1A3FB050 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit L-Soft list server at AKH-WIEN.AC.AT (1.8d) [[log in to unmask]] -----Original Message----- From: Williams, Dave [mailto:[log in to unmask]] Sent: Tuesday, October 09, 2001 10:35 AM To: [log in to unmask] Subject: Is there a similar List .... For MQSeries? If someone has the name, I'd appreciate it. Thanks! Dave [log in to unmask] ------_=_NextPart_001_01C150EC.1A3FB050 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: Is there a similar List ....

L-Soft list server at AKH-WIEN.AC.AT (1.8d) [[log in to unmask]]

-----Original Message-----
From: Williams, Dave [mailto:[log in to unmask]]
Sent: Tuesday, October 09, 2001 10:35 AM
To: [log in to unmask]
Subject: Is there a similar List ....


For MQSeries? If someone has the name, I'd appreciate it. Thanks!

Dave

[log in to unmask]

------_=_NextPart_001_01C150EC.1A3FB050-- ========================================================================Date: Tue, 9 Oct 2001 16:08:17 -0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Sergio Lima <[log in to unmask]> Subject: Re: Program to get the jobname and the stepname Mime-Version: 1.0 Content-Type: text/plain; format=flowed Hello. I want have this program here also, but I imagine that this program 'LINK' another . How can I run this program here ? Thank's Sergio Lima Costa System Consultant Sao Paulo - Brasil >From: Vitor Romao <[log in to unmask]> >Reply-To: CICS List <[log in to unmask]> >To: [log in to unmask] >Subject: Re: Program to get the jobname and the stepname >Date: Tue, 9 Oct 2001 18:21:13 +0100 > >Fantastic, it work's > >Thank's everybody > >-----Original Message----- >From: Thompson, William (DISA Oklahoma City) >[mailto:[log in to unmask]] >Sent: Terça-feira, 9 de Outubro de 2001 18:07 >To: [log in to unmask] >Subject: Re: Program to get the jobname and the stepname > > >You bet...When it works, why re-invent it...but (somewhat embarrassed), I >will update the program using it to back reference the original author..... > >-----Original Message----- >From: [log in to unmask] [mailto:[log in to unmask]] >Sent: Tuesday, October 09, 2001 12:05 PM >To: [log in to unmask] >Subject: Re: Program to get the jobname and the stepname > > >Bill, > > I see Gilbert's program has made the rounds ;o) > >Bill O. > >snip _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ========================================================================Date: Tue, 9 Oct 2001 13:24:20 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Thompson, William (DISA Oklahoma City)" <[log in to unmask]> Subject: Re: Program to get the jobname and the stepname MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" The following is just imbedded in your assembler program: Use the MVS "EXTRACT" Macro. Example : TIOTADDR DS F REGSAVE DS F JOBINFO DS CL24 EXTRACT TIOTADDR,'S',FIELDS=TIOT ST R7,REGSAVE L R7,TIOTADDR MVC JOBINFO,0(R7) L R7,REGSAVE The order of the fields loaded into JOBINFO are ===> JOBNAME, PROCSTEP NAME and STEP NAME. Each field is 8-bytes long. The following is just imbedded in your COBOL program: This is working in batch to collect info for my EXCI connection to CICS.... 008100*==============================================================* 008200* Initialise job specific information * 008300*==============================================================* 008400* 008500 01 Job-Information. 008600 03 Job-Name Pic x(8). 008700 03 Proc-Step Pic x(8). 008800 03 Step-Name Pic x(8). 008900 03 Job-Number Pic x(8). 009000 03 Program-Name Pic x(8). 009100* 009200 linkage section. 009300* 009400 01 cb1. 009500 05 ptr1 Pointer Occurs 256. 009600 01 cb2. 009700 05 ptr2 Pointer Occurs 256. 009800* 009900 01 Null-ptr usage is Pointer. 010000* 018600*==============================================================* 018700* Initialise job specific information * 018800*==============================================================* 018900 Job-Specific-Info. 019000* PSA 019100 SET Address of cb1 to null. 019200* TCB 019300 SET Address of cb1 to ptr1(136). 019400* TIOT 019500 SET Address of cb2 to ptr1(4). 019600 MOVE Cb2(1:8) to Job-Name. 019700 MOVE Cb2(9:8) to Proc-Step. 019800 MOVE Cb2(17:8) to Step-Name. 019900* JSCB 020000 SET Address of cb2 to ptr1(46). 020100 MOVE cb2(361:8) to program-name. 020200* SSIB 020300 SET Address Of cb2 To ptr2(80). 020400 MOVE cb2(13:8) To job-number. -----Original Message----- From: Sergio Lima [mailto:[log in to unmask]] Sent: Tuesday, October 09, 2001 1:08 PM To: [log in to unmask] Subject: Re: Program to get the jobname and the stepname Hello. I want have this program here also, but I imagine that this program 'LINK' another . How can I run this program here ? Thank's Sergio Lima Costa System Consultant Sao Paulo - Brasil snip ========================================================================Date: Tue, 9 Oct 2001 13:33:17 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "McKown, John" <[log in to unmask]> Subject: Re: Program to get the jobname and the stepname MIME-Version: 1.0 Content-Type: text/plain Not a good idea in CICS! Yes it will work OK. But it violates coding standards by issuing an SVC. More my personal opinion than a hard and fast rule. ---------------------------------------------------------------------- John McKown HealthAxis All opinions are my own and are not the opinions of my employer. Unsolicited telephone calls from vendors are NOT appreciated and tend to upset my management. Where does bad light end up? In a prism! (Gary Lisica) > -----Original Message----- > From: Thompson, William (DISA Oklahoma City) [SMTP:[log in to unmask]] > Sent: Tuesday, October 09, 2001 1:24 PM > To: [log in to unmask] > Subject: Re: Program to get the jobname and the stepname > > The following is just imbedded in your assembler program: > > Use the MVS "EXTRACT" Macro. Example : > > TIOTADDR DS F > REGSAVE DS F > JOBINFO DS CL24 > > EXTRACT TIOTADDR,'S',FIELDS=TIOT > ST R7,REGSAVE > L R7,TIOTADDR > MVC JOBINFO,0(R7) > L R7,REGSAVE > > ========================================================================Date: Tue, 9 Oct 2001 13:41:03 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Thompson, William (DISA Oklahoma City)" <[log in to unmask]> Subject: Re: Program to get the jobname and the stepname MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Of course, but the original thread was referring to batch programs......grin..... -----Original Message----- From: McKown, John [mailto:[log in to unmask]] Sent: Tuesday, October 09, 2001 1:33 PM To: [log in to unmask] Subject: Re: Program to get the jobname and the stepname Not a good idea in CICS! Yes it will work OK. But it violates coding standards by issuing an SVC. More my personal opinion than a hard and fast rule. ship ========================================================================Date: Tue, 9 Oct 2001 16:03:30 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Mike Martin <[log in to unmask]> Subject: Shipping data to TD queue Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Hi all, This is another of my stupid-rookie questions... Is there some slick way of shipping data (external to CICS) to a transient data queue? Using some facility that requires very little or no programming? Thanks in advance. Mike Martin Systems Programmer Wake Med Information Services 3000 New Bern Ave. Raleigh, N.C. 27610 (919)-350-8458 [log in to unmask] ========================================================================Date: Tue, 9 Oct 2001 16:11:11 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Norman Potter <[log in to unmask]> Subject: Re: Shipping data to TD queue Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit There used to be a product from IBM called CICSFXR or something like that that did what you are asking. >>> [log in to unmask] 10/09/01 04:03PM >>> Hi all, This is another of my stupid-rookie questions... Is there some slick way of shipping data (external to CICS) to a transient data queue? Using some facility that requires very little or no programming? Thanks in advance. Mike Martin Systems Programmer Wake Med Information Services 3000 New Bern Ave. Raleigh, N.C. 27610 (919)-350-8458 [log in to unmask] ========================================================================Date: Tue, 9 Oct 2001 16:42:04 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Bob Juch <[log in to unmask]> Subject: Re: Shipping data to TD queue MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii If it's an external TD queue, IEBGENER works very well. If it's an internal queue, you'd have to buy or write a program. You could use EXCI to write such a program. Bob Juch CICS and MQSeries Support Canon USA Mike Martin [log in to unmask] D.ORG> cc: Sent by: CICS Subject: [CICS-L] Shipping data to TD queue List 10/09/2001 04:03 PM Please respond to CICS List Hi all, This is another of my stupid-rookie questions... Is there some slick way of shipping data (external to CICS) to a transient data queue? Using some facility that requires very little or no programming? Thanks in advance. Mike Martin Systems Programmer Wake Med Information Services 3000 New Bern Ave. Raleigh, N.C. 27610 (919)-350-8458 [log in to unmask] ========================================================================Date: Tue, 9 Oct 2001 14:25:59 -0700 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Lesseg, Jon" <[log in to unmask]> Subject: Re: Shipping data to TD queue MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15108.FD4C2A60" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15108.FD4C2A60 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit As previously mentioned, if this is an external TD queue loading with IEBGENER would work, but wouldn't it need to be either unavailable to CICS at the time of loading or the TD queue would need to be closed and reopened for CICS transaction to "recognize" the existence of the new data? Jon W. Lesseg CICS & OS390 Support PacifiCorp Mailto:[log in to unmask] -----Original Message----- From: Mike Martin [mailto:[log in to unmask]] Sent: Tuesday, October 09, 2001 1:04 PM To: [log in to unmask] Subject: Shipping data to TD queue Hi all, This is another of my stupid-rookie questions... Is there some slick way of shipping data (external to CICS) to a transient data queue? Using some facility that requires very little or no programming? Thanks in advance. Mike Martin Systems Programmer Wake Med Information Services 3000 New Bern Ave. Raleigh, N.C. 27610 (919)-350-8458 [log in to unmask] ------_=_NextPart_001_01C15108.FD4C2A60 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: Shipping data to TD queue

As previously mentioned, if this is an external TD queue loading with IEBGENER would work,
but wouldn't it need to be either unavailable to CICS at the time of loading or
the TD queue would need to be closed and reopened for CICS transaction to
"recognize" the existence of the new data?
Jon W. Lesseg
CICS & OS390 Support
PacifiCorp
[log in to unmask]">Mailto:[log in to unmask]

-----Original Message-----
From: Mike Martin [mailto:[log in to unmask]]
Sent: Tuesday, October 09, 2001 1:04 PM
To: [log in to unmask]
Subject: Shipping data to TD queue


Hi all,

This is another of my stupid-rookie questions...

Is there some slick way of shipping data (external to CICS) to a transient data queue?  Using some facility that requires very little or no programming?

Thanks in advance.

Mike Martin
Systems Programmer
Wake Med Information Services
3000 New Bern Ave.
Raleigh, N.C. 27610
(919)-350-8458
[log in to unmask]

------_=_NextPart_001_01C15108.FD4C2A60-- ========================================================================Date: Tue, 9 Oct 2001 23:04:34 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Peter J. Farley III" <[log in to unmask]> Subject: Re: Question on dynamic CALL's under CICS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:42 AM 10/9/01 -0400, you wrote: >Peter, > > There's no problem with a 24-bit sub-program being statically >called >from a 31-bit caller. R1 is loaded with a 24-bit parmlist address. Yes, >CICS Dynamic Calls are a bit slower than Static but much more efficient >that the LINK-API. Apparently, you have more than one COBOL-Caller >accessing the Assembler sub-program (the reason a Dynamic Call is >appealing). That's what I hoped, thanks for the confirmation. > Have a look at the BASSM and BSM instructions for Dynamic Calls >for mixed addressabilities. We've used them quite a bit before in >intermediate intercept programs nudged between 31-bit COBOL and >24-bit Assembler. > > Would it be worthwhile developing a standard COBOL "Gateway" >program that's Dynamically Called, who then issues a static call to >the Assembler program? You'd only require a re-compilation and link >to the COBOL program if the Assembler program is modified. > > Just a thought.... > >HTH.... Bill, The assembler program in this case is itself already an interface or "gateway" routine to a large collection of 24-bit code. I have plans to modify it to use BASSM/BSM to allow the routine to be loaded above the line but execute the 24-bit code in the right mode, but I thought I could go one step further (and possibly do less work) if I could just use dynamic call to invoke one below-the-line copy shared by all callers. The only problem there is the large number of ALIAS's the gateway has to have. Fortunately it's re-entrant so only one real copy would be needed for everyone. What I've gathered from the responses so far is that so long as I use DATA(24) I should be able to dynamically call the assembler interface and pass only 24-bit parameters along. The other option I've been investigating is RMODE(SPLIT) along with DATA(24), but all systems need to be at V2.10 for that to work out, and I can't guarantee that at the moment. Thanks for the help. --------------------------------------------------------- Peter J. Farley III ([log in to unmask]) ========================================================================Date: Wed, 10 Oct 2001 00:28:00 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Gary P. Klos" <[log in to unmask]> Subject: Gary P Klos/Headquarters/USX is in training for the remainder of the week, but I will be checking email. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii I will be out of the office starting 10/09/2001 and will not return until 10/15/2001. I will respond to your message as soon as I can. ========================================================================Date: Wed, 10 Oct 2001 08:03:39 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Dean Stewart / OutSource@SDC" <[log in to unmask]> Subject: UDP MULTICAST SETSOCKOPT PROBLEM MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Problem: JOINING A UDP MULTICAST GROUP UNDER CICS/COBOL USING THE 'SETSOCKOPT' CALL Situation: We are looking at the OS/390 V2R8.0 Secureway CS IP CICS Sockets Guide, and are trying to find the command/correct values, to get the above working. Regards, Dean Stewart CICS Team PQ OutSource Ph. 011 322 5611 Cell. 082 334 8581 ========================================================================Date: Wed, 10 Oct 2001 09:54:28 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Flint, Mike" <[log in to unmask]> Subject: Re: Program to get the jobname and the stepname MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Using the CICS SPI to INQUIRE SYSTEM JOBNAME(xxxxxx) will yield the jobname in a 'CICS friendly' manner. No INQUIRE STEPNAME though! -----Original Message----- From: McKown, John [mailto:[log in to unmask]] Sent: 09 October 2001 19:33 To: [log in to unmask] Subject: Re: Program to get the jobname and the stepname Not a good idea in CICS! Yes it will work OK. But it violates coding standards by issuing an SVC. More my personal opinion than a hard and fast rule. ---------------------------------------------------------------------- John McKown HealthAxis All opinions are my own and are not the opinions of my employer. Unsolicited telephone calls from vendors are NOT appreciated and tend to upset my management. Where does bad light end up? In a prism! (Gary Lisica) > -----Original Message----- > From: Thompson, William (DISA Oklahoma City) [SMTP:[log in to unmask]] > Sent: Tuesday, October 09, 2001 1:24 PM > To: [log in to unmask] > Subject: Re: Program to get the jobname and the stepname > > The following is just imbedded in your assembler program: > > Use the MVS "EXTRACT" Macro. Example : > > TIOTADDR DS F > REGSAVE DS F > JOBINFO DS CL24 > > EXTRACT TIOTADDR,'S',FIELDS=TIOT > ST R7,REGSAVE > L R7,TIOTADDR > MVC JOBINFO,0(R7) > L R7,REGSAVE > > ======================================================================Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF ========================================================================Date: Wed, 10 Oct 2001 11:58:02 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Giuliani, Claudio" <[log in to unmask]> MIME-Version: 1.0 Content-Type: text/plain Hi everbody, We are new Landmark Tmon Cics users.For a long time we used Candle Omegamon Cics , and with this one there was a program used to manage SMF 110 records. We are looking for a similar tool able to read as an input SMf 110 records .We know that there was nothing standard with rel 2.0 Do you know something like this ? Any idea. Regards, ========================================================================Date: Wed, 10 Oct 2001 11:10:53 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Stewart Herd <[log in to unmask]> Subject: TMON Logs Mime-Version: 1.0 Content-Type: multipart/alternative ; boundary="----_=_NextPart_001_01C15173.D8C591C0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15173.D8C591C0 Content-Type: text/plain; charset="iso-8859-1" TMON - We increased the sizes of our logs in TMON because they were switching too regularly, but we still seem to be switching regularly whether or not the logs are full, is there a parameter that requires to be changed to prevent the switching before the logs are actually full. Thanks ************************************* Stewart Herd CICS/MQ Systems Programmer Perot Systems Cabinteley, Dublin 18, Ireland. E-mail: [log in to unmask] Phone: +353 1 217 7000 Ext 2692 Mobile; 00 44 7976 753521 ************************************* ******************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify us immediately at [log in to unmask] and delete this E-mail from your system. Thank you. It is possible for data transmitted by email to be deliberately or accidentally corrupted or intercepted. For this reason, where the communication is by email, the Bank of Ireland Group does not accept any responsibility for any breach of confidence which may arise through the use of this medium. This footnote also confirms that this email message has been swept for the presence of known computer viruses. ******************************************************************** ------_=_NextPart_001_01C15173.D8C591C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TMON Logs

TMON - We increased the sizes of our logs in TMON because they were switching too regularly, but we still seem to be switching regularly whether or not the logs are full, is there a parameter that requires to be changed to prevent the switching before the logs are actually full.

Thanks

*************************************
Stewart Herd
CICS/MQ Systems Programmer
Perot Systems
Cabinteley, Dublin 18, Ireland.
E-mail: [log in to unmask]
Phone: +353 1 217 7000  Ext 2692
Mobile; 00 44 7976 753521
*************************************



********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please
notify us immediately at [log in to unmask] and delete this E-mail
from your system. Thank you.
It is possible for data transmitted by email to be deliberately or
accidentally corrupted or intercepted. For this reason, where the
communication is by email, the Bank of Ireland Group does not accept
any responsibility for any breach of confidence which may arise
through the use of this medium.
This footnote also confirms that this email message has been swept
for the presence of known computer viruses.
********************************************************************

------_=_NextPart_001_01C15173.D8C591C0-- ========================================================================Date: Wed, 10 Oct 2001 12:28:49 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: [log in to unmask] Subject: Re: TMON Logs Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Stewart In our TMON-using environments we have activated the File Switch Utility feature, where a configuration file is telling TMON to do so. It can be seen in the log of the DLS address space as: WEDNESDAY, OCTOBER 10, 2001 00:00 LFS TMONPCSM RUNNING AS JOB TMONPDLS ON SYSTE SENDING 'SWITCH' TO LF(TMON01) IN RESPONSE TO TIMEDSWITCH(UDV) SUBMIT COMPLETE, MEMBER(TCEFSU), LDS(TMON01B), DSN(SYS3CICS.TMONCICS.V200.TMON01 SENDING 'SWITCH' TO LF(TMON02) IN RESPONSE TO TIMEDSWITCH(CICSGPP) SUBMIT COMPLETE, MEMBER(TCEFSU), LDS(TMON02B), DSN(SYS3CICS.TMONCICS.V200.TMON02 SENDING 'SWITCH' TO LF(TMON03) IN RESPONSE TO TIMEDSWITCH(PROD) SUBMIT COMPLETE, MEMBER(TCEFSU), LDS(TMON03A), DSN(SYS3CICS.TMONCICS.V200.TMON03 Have you got something like that? Best rgds, Michael Erichsen CSC Denmark ========================================================================Date: Wed, 10 Oct 2001 12:18:16 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Luscombe John (HS)" <[log in to unmask]> Subject: AW: TMON Logs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" >TMON - We increased the sizes of our logs in TMON because they were >switching too regularly, but we still seem to be switching regularly whether >or not the logs are full, is there a parameter that requires to be changed >to prevent the switching before the logs are actually full. Hi Stewart, If by "regular" you mean at specific times, then maybe by an automated switch command? John. ========================================================================Date: Wed, 10 Oct 2001 12:23:38 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Luscombe John (HS)" <[log in to unmask]> Subject: AW: TMON SMF 110 recs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" >Hi everbody, > >We are new Landmark Tmon Cics users.For a long time we used Candle Omegamon >Cics , and with this one there was a program used to manage SMF 110 records. >We are looking for a similar tool able to read as an input SMf 110 records >.We know that there was nothing standard with rel 2.0 >Do you know something like this ? Any idea. Hi, I'm not aware of anything from TMON/CICS that does this. We record CICS info to the TMON collection address space which logs to datasets. We then report from these using TMON/CICS Report writer, which I guess is a separate product, but I'm not sure. John. ========================================================================Date: Wed, 10 Oct 2001 12:56:59 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: [log in to unmask] Subject: Re: AW: TMON SMF 110 recs Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi The TMON report writer is a not separately priced part of the product. You can go the opposite way and let TMON produce the equvalent of SMF110 records. Best rgds, Michael Erichsen CSC Denmark "Luscombe John (HS)" <[log in to unmask]> on 10-10-2001 12:23:38 Please respond to CICS List <[log in to unmask]> To: [log in to unmask] cc: (bcc: Michael Erichsen/SCA/CSC) Subject: AW: TMON SMF 110 recs >Hi everbody, > >We are new Landmark Tmon Cics users.For a long time we used Candle Omegamon >Cics , and with this one there was a program used to manage SMF 110 records. >We are looking for a similar tool able to read as an input SMf 110 records >.We know that there was nothing standard with rel 2.0 >Do you know something like this ? Any idea. Hi, I'm not aware of anything from TMON/CICS that does this. We record CICS info to the TMON collection address space which logs to datasets. We then report from these using TMON/CICS Report writer, which I guess is a separate product, but I'm not sure. John. ========================================================================Date: Wed, 10 Oct 2001 12:54:29 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Lisbeth Smed <[log in to unmask]> Subject: SV: TMON SMF 110 recs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From TMON for CICS rel 2.0 Reference Manual -----Oprindelig meddelelse----- Fra: Luscombe John (HS) [mailto:[log in to unmask]] Sendt: 10. oktober 2001 12:24 Til: [log in to unmask] Emne: AW: TMON SMF 110 recs >Hi everbody, > >We are new Landmark Tmon Cics users.For a long time we used Candle Omegamon >Cics , and with this one there was a program used to manage SMF 110 records. >We are looking for a similar tool able to read as an input SMf 110 records >.We know that there was nothing standard with rel 2.0 >Do you know something like this ? Any idea. Hi, I'm not aware of anything from TMON/CICS that does this. We record CICS info to the TMON collection address space which logs to datasets. We then report from these using TMON/CICS Report writer, which I guess is a separate product, but I'm not sure. John. ========================================================================Date: Wed, 10 Oct 2001 12:55:38 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Lisbeth Smed <[log in to unmask]> Subject: SV: TMON SMF 110 recs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From TMON for CICS rel 2.0 Reference manual: "Data conversion to SMF 110 format. Using the Data Conversion Facility program, TMON for CICS/ESA archived data can be converted to SMF 110 type 1 (classes 1 and 3) format." Regards Lisbeth Smed -----Oprindelig meddelelse----- Fra: Luscombe John (HS) [mailto:[log in to unmask]] Sendt: 10. oktober 2001 12:24 Til: [log in to unmask] Emne: AW: TMON SMF 110 recs >Hi everbody, > >We are new Landmark Tmon Cics users.For a long time we used Candle Omegamon >Cics , and with this one there was a program used to manage SMF 110 records. >We are looking for a similar tool able to read as an input SMf 110 records >.We know that there was nothing standard with rel 2.0 >Do you know something like this ? Any idea. Hi, I'm not aware of anything from TMON/CICS that does this. We record CICS info to the TMON collection address space which logs to datasets. We then report from these using TMON/CICS Report writer, which I guess is a separate product, but I'm not sure. John. ========================================================================Date: Wed, 10 Oct 2001 14:00:36 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Luscombe John (HS)" <[log in to unmask]> Subject: AW: TMON SMF 110 recs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi Lisbeth, Thanks, that's good to know, but original poster's problem was not having any tool to process type 110's. John. -----Ursprüngliche Nachricht----- Von: Lisbeth Smed [mailto:[log in to unmask]] Gesendet am: Mittwoch, 10. Oktober 2001 12:56 An: [log in to unmask] Betreff: SV: TMON SMF 110 recs From TMON for CICS rel 2.0 Reference manual: "Data conversion to SMF 110 format. Using the Data Conversion Facility program, TMON for CICS/ESA archived data can be converted to SMF 110 type 1 (classes 1 and 3) format." Regards Lisbeth Smed -----Oprindelig meddelelse----- Fra: Luscombe John (HS) [mailto:[log in to unmask]] Sendt: 10. oktober 2001 12:24 Til: [log in to unmask] Emne: AW: TMON SMF 110 recs >Hi everbody, > >We are new Landmark Tmon Cics users.For a long time we used Candle Omegamon >Cics , and with this one there was a program used to manage SMF 110 records. >We are looking for a similar tool able to read as an input SMf 110 records >.We know that there was nothing standard with rel 2.0 >Do you know something like this ? Any idea. Hi, I'm not aware of anything from TMON/CICS that does this. We record CICS info to the TMON collection address space which logs to datasets. We then report from these using TMON/CICS Report writer, which I guess is a separate product, but I'm not sure. John. ========================================================================Date: Wed, 10 Oct 2001 07:03:49 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Chase, John" <[log in to unmask]> Subject: Re: Question on dynamic CALL's under CICS MIME-Version: 1.0 Content-Type: text/plain On Tuesday, October 09, 2001 10:05 PM, Peter J. Farley III wrote: > [ snip ] > The assembler program in this case is itself already an interface or > "gateway" routine to a large collection of 24-bit code. I have plans > to modify it to use BASSM/BSM to allow the routine to be loaded above > the line but execute the 24-bit code in the right mode, That won't work. The "gateway" (aka "glue") routine will have to reside below the line; otherwise, your Amode(24) programs will end up like "Charlie on the MTA" (old Kingston Trio song) and never return. > but I thought I > could go one step further (and possibly do less work) if I could just > use dynamic call to invoke one below-the-line copy shared by all > callers. The only problem there is the large number of ALIAS's the > gateway has to have. Fortunately it's re-entrant so only one real copy > would be needed for everyone. If it's also LPA-eligible, that might be the place to load it. > What I've gathered from the responses so far is that so long as I use > DATA(24) I should be able to dynamically call the assembler interface > and pass only 24-bit parameters along. > > The other option I've been investigating is RMODE(SPLIT) along with > DATA(24), but all systems need to be at V2.10 for that to work out, and > I can't guarantee that at the moment. AMODE(ANY) and RMODE(24) should work "forever" for your "gateway" routine, once you incorporate the Amode-switching instructions. -jc- ========================================================================Date: Wed, 10 Oct 2001 09:00:35 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: [log in to unmask] Subject: Re: TMON SMF 110 recs MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit If you have SAS, you could purchase the MXG product. It processes the SMF 110 records. Larry Alan Gray Phone: 336-658-7944 Technical Services Fax: 336-658-2124 Lowe's Companies Inc. email: [log in to unmask] > -----Original Message----- > From: Luscombe John (HS) [SMTP:[log in to unmask]] > Sent: Wednesday, October 10, 2001 8:01 AM > To: [log in to unmask] > Subject: AW: TMON SMF 110 recs > > Hi Lisbeth, > > Thanks, that's good to know, but original poster's problem was not having > any tool to process type 110's. > > John. > > -----Ursprüngliche Nachricht----- > Von: Lisbeth Smed [mailto:[log in to unmask]] > Gesendet am: Mittwoch, 10. Oktober 2001 12:56 > An: [log in to unmask] > Betreff: SV: TMON SMF 110 recs > > From TMON for CICS rel 2.0 Reference manual: > > "Data conversion to SMF 110 format. > Using the Data > Conversion Facility program, TMON for CICS/ESA archived > data can be converted to SMF 110 type 1 (classes 1 and 3) format." > > Regards > > Lisbeth Smed > > -----Oprindelig meddelelse----- > Fra: Luscombe John (HS) [mailto:[log in to unmask]] > Sendt: 10. oktober 2001 12:24 > Til: [log in to unmask] > Emne: AW: TMON SMF 110 recs > > > >Hi everbody, > > > >We are new Landmark Tmon Cics users.For a long time we used Candle > Omegamon > >Cics , and with this one there was a program used to manage SMF 110 > records. > >We are looking for a similar tool able to read as an input SMf 110 > records > >.We know that there was nothing standard with rel 2.0 > >Do you know something like this ? Any idea. > > Hi, > > I'm not aware of anything from TMON/CICS that does this. We record CICS > info > to the TMON collection address space which logs to datasets. We then > report > from these using TMON/CICS Report writer, which I guess is a separate > product, but I'm not sure. > > John. ========================================================================Date: Wed, 10 Oct 2001 15:01:51 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Lisbeth Smed <[log in to unmask]> Subject: SV: TMON SMF 110 recs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi John! -----Oprindelig meddelelse----- Fra: Luscombe John (HS) [mailto:[log in to unmask]] Sendt: 10. oktober 2001 14:01 Til: [log in to unmask] Emne: AW: TMON SMF 110 recs Hi Lisbeth, Thanks, that's good to know, but original poster's problem was not having any tool to process type 110's. John. -----Ursprüngliche Nachricht----- Von: Lisbeth Smed [mailto:[log in to unmask]] Gesendet am: Mittwoch, 10. Oktober 2001 12:56 An: [log in to unmask] Betreff: SV: TMON SMF 110 recs From TMON for CICS rel 2.0 Reference manual: "Data conversion to SMF 110 format. Using the Data Conversion Facility program, TMON for CICS/ESA archived data can be converted to SMF 110 type 1 (classes 1 and 3) format." Regards Lisbeth Smed -----Oprindelig meddelelse----- Fra: Luscombe John (HS) [mailto:[log in to unmask]] Sendt: 10. oktober 2001 12:24 Til: [log in to unmask] Emne: AW: TMON SMF 110 recs >Hi everbody, > >We are new Landmark Tmon Cics users.For a long time we used Candle Omegamon >Cics , and with this one there was a program used to manage SMF 110 records. >We are looking for a similar tool able to read as an input SMf 110 records >.We know that there was nothing standard with rel 2.0 >Do you know something like this ? Any idea. Hi, I'm not aware of anything from TMON/CICS that does this. We record CICS info to the TMON collection address space which logs to datasets. We then report from these using TMON/CICS Report writer, which I guess is a separate product, but I'm not sure. John. ========================================================================Date: Wed, 10 Oct 2001 09:08:53 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Peter J. Farley III" <[log in to unmask]> Subject: Re: Question on dynamic CALL's under CICS In-Reply-To: <[log in to unmask]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:03 AM 10/10/01 -0500, you wrote: >On Tuesday, October 09, 2001 10:05 PM, Peter J. Farley III wrote: >> [ snip ] >> The assembler program in this case is itself already an interface or >> "gateway" routine to a large collection of 24-bit code. I have plans >> to modify it to use BASSM/BSM to allow the routine to be loaded above >> the line but execute the 24-bit code in the right mode, > >That won't work. The "gateway" (aka "glue") routine will have to >reside below the line; otherwise, your Amode(24) programs will end up >like "Charlie on the MTA" (old Kingston Trio song) and never return. D'oh! Of course, and thank you for reminding me about that. And yes, I am in fact old enough to remember that song quite fondly. :O) >> but I thought I >> could go one step further (and possibly do less work) if I could just >> use dynamic call to invoke one below-the-line copy shared by all >> callers. The only problem there is the large number of ALIAS's the >> gateway has to have. Fortunately it's re-entrant so only one real >> copy would be needed for everyone. > >If it's also LPA-eligible, that might be the place to load it. Good point, I hadn't considered that. >> What I've gathered from the responses so far is that so long as I use >> DATA(24) I should be able to dynamically call the assembler interface >> and pass only 24-bit parameters along. >> >> The other option I've been investigating is RMODE(SPLIT) along with >> DATA(24), but all systems need to be at V2.10 for that to work out, >> and I can't guarantee that at the moment. > >AMODE(ANY) and RMODE(24) should work "forever" for your "gateway" >routine, once you incorporate the Amode-switching instructions. True, and the more elegant (as in KISS) solution as well. Thanks again for the help, John. --------------------------------------------------------- Peter J. Farley III ([log in to unmask]) ========================================================================Date: Wed, 10 Oct 2001 16:27:27 +0300 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Adnan Can (Garanti Teknoloji)" <[log in to unmask]> Subject: Re: IGZEINI was not a proper module Ponzio, Yes, both are link-edited with the same LE libraries. Actually we had a SYSPRINT problem from a VA PLI program and IBM sent us a test fix. After applying the fix, this problem was disappeared as well. Regards, -----Original Message----- From: Ponzio, Andrea [mailto:[log in to unmask]] Sent: Tuesday, October 09, 2001 5:02 PM To: [log in to unmask] Subject: R: IGZEINI was not a proper module Have you linkedited Cobol and PLI with same LE libraries (SCEELKED) ? -----Messaggio originale----- Da: Adnan Can (Garanti Teknoloji) [mailto:[log in to unmask]] Inviato: martedì 9 ottobre 2001 10.29 A: [log in to unmask] Oggetto: IGZEINI was not a proper module Hi everbody, We are trying to call a cobol program (compiled by cobol for OS/390) from a VA PLI under CICS TS 1.2 and having the following error message: IGZ0011C IGZEINI was not a proper module for this system environment. From compile unit LAG30902 at entry point LAG30902 at compile unit offset -EE70B5C6 at address 00FCEBE6. We have DFHRPL concat : CEE.SCEECICS CEE.SCEERUN What could be the reason for this? Any idea. Regards, ----------------------------------- Adnan CAN Garanti Technology [log in to unmask] TEL: +90.212.4783298 ----------------------------------- ========================================================================Date: Wed, 10 Oct 2001 09:45:18 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Richard Henley <[log in to unmask]> Subject: Re: SMF 110 records MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii When you send e-mail to the Listserver please include a subject. Because of all the junk e-mail that I receive, I most often discard without opening any e-mail without a subject. Thanks, Dick Henley IBM Global Services 614-308-6561 TL 409-6561 "Giuliani, Claudio" To: [log in to unmask] Subject: Sent by: CICS List <[log in to unmask] GA.EDU> 10/10/01 05:58 AM Please respond to CICS List Hi everbody, We are new Landmark Tmon Cics users.For a long time we used Candle Omegamon Cics , and with this one there was a program used to manage SMF 110 records. We are looking for a similar tool able to read as an input SMf 110 records .We know that there was nothing standard with rel 2.0 Do you know something like this ? Any idea. Regards, ========================================================================Date: Wed, 10 Oct 2001 08:58:17 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Buckles, Stephen L." <[log in to unmask]> Subject: Re: Question on dynamic CALL's under CICS MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" For pitty sakes - make the assembler program AMODE(31) RMODE(ANY). Doesn't take that much work and will save you a lot of junior programmer headaches. -----Original Message----- From: Peter J. Farley III [mailto:[log in to unmask]] Sent: Sunday, October 07, 2001 11:14 PM To: [log in to unmask] Subject: Re: Question on dynamic CALL's under CICS At 09:30 PM 10/7/01 -0500, you wrote: >So the answer is NO. COBOL will not attempt to copy the parameters from >31 bit storage to 24 bit storage. This would be terrible, if you think >of it. >Now, with an EXEC CICS LINK transfer, CICS will copy the data for you. >I think this is because (1) there is only one area - the COMMAREA, and >(2) the size of the area is limited to a maximum of 64K. This is more >reasonable. Thanks for the reply, John. That's the way I analyzed it, too, I was just hoping I was wrong. I'll just have to use DATA(24). >I am basing the above on my own experience and a SWAG of how COBOL >works. I don't think that it is documented anywhere. In this case, >"that which is not explicitly permitted, is forbidden." I remember reading that in "1984", and I didn't like it then any more than I do now. --------------------------------------------------------- Peter J. Farley III ([log in to unmask]) ========================================================================Date: Wed, 10 Oct 2001 09:00:28 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Buckles, Stephen L." <[log in to unmask]> Subject: Re: Macro Level MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X'11' in any level of CICS is a test for a Set Buffer Address (SBA) which is one way to determine if you have received a 3270 formatted message or not. If X'11' is the first byte - it's formatted. -----Original Message----- From: KIRAN Damojipurapu [mailto:[log in to unmask]] Sent: Monday, October 08, 2001 4:44 AM To: [log in to unmask] Subject: Macro Level Hello, In CICS Macro level, what does CLI TIOADBA,X'11' mean? Thanks in advance. Regards Kiran ========================================================================Date: Wed, 10 Oct 2001 09:55:39 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Mullen, Patrick" <[log in to unmask]> Subject: Re: TMON SMF 110 recs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit We should ask the original poster what it is exactly he wants to do with the 110 records. If he has TMON set up correctly then I don't see why he requires 110 records at all. > -----Original Message----- > From: Luscombe John (HS) [mailto:[log in to unmask]] > > Thanks, that's good to know, but original poster's problem > was not having > any tool to process type 110's. > > John. > > -----Ursprüngliche Nachricht----- > Von: Lisbeth Smed [mailto:[log in to unmask]] > > From TMON for CICS rel 2.0 Reference manual: > > "Data conversion to SMF 110 format. > Using the Data > Conversion Facility program, TMON for CICS/ESA archived > data can be converted to SMF 110 type 1 (classes 1 and 3) format." > > Regards > > Lisbeth Smed > > -----Oprindelig meddelelse----- > Fra: Luscombe John (HS) [mailto:[log in to unmask]] > > >Hi everbody, > > > >We are new Landmark Tmon Cics users.For a long time we used Candle > Omegamon > >Cics , and with this one there was a program used to manage SMF 110 > records. > >We are looking for a similar tool able to read as an input > SMf 110 records > >.We know that there was nothing standard with rel 2.0 > >Do you know something like this ? Any idea. > > Hi, > > I'm not aware of anything from TMON/CICS that does this. We > record CICS info > to the TMON collection address space which logs to datasets. > We then report > from these using TMON/CICS Report writer, which I guess is a separate > product, but I'm not sure. > > John. > ========================================================================Date: Wed, 10 Oct 2001 10:20:31 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Matthew Stitt <[log in to unmask]> Organization: Huntsville Hospital Subject: Re: TMON SMF 110 recs MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I did. I got an ambiguous answer. I think he wants to use SMF 110's as input to the TMON reporter. "Mullen, Patrick" wrote: > We should ask the original poster what it is exactly he wants to do with the > 110 records. If he has TMON set up correctly then I don't see why he > requires 110 records at all. > > > -----Original Message----- > > From: Luscombe John (HS) [mailto:[log in to unmask]] > > > > Thanks, that's good to know, but original poster's problem > > was not having > > any tool to process type 110's. > > > > John. > > > > -----Ursprüngliche Nachricht----- > > Von: Lisbeth Smed [mailto:[log in to unmask]] > > > > From TMON for CICS rel 2.0 Reference manual: > > > > "Data conversion to SMF 110 format. > > Using the Data > > Conversion Facility program, TMON for CICS/ESA archived > > data can be converted to SMF 110 type 1 (classes 1 and 3) format." > > > > Regards > > > > Lisbeth Smed > > > > -----Oprindelig meddelelse----- > > Fra: Luscombe John (HS) [mailto:[log in to unmask]] > > > > >Hi everbody, > > > > > >We are new Landmark Tmon Cics users.For a long time we used Candle > > Omegamon > > >Cics , and with this one there was a program used to manage SMF 110 > > records. > > >We are looking for a similar tool able to read as an input > > SMf 110 records > > >.We know that there was nothing standard with rel 2.0 > > >Do you know something like this ? Any idea. > > > > Hi, > > > > I'm not aware of anything from TMON/CICS that does this. We > > record CICS info > > to the TMON collection address space which logs to datasets. > > We then report > > from these using TMON/CICS Report writer, which I guess is a separate > > product, but I'm not sure. > > > > John. > > ========================================================================Date: Wed, 10 Oct 2001 15:40:05 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Stewart Herd <[log in to unmask]> Subject: Re: TMON Logs Mime-Version: 1.0 Content-Type: multipart/alternative ; boundary="----_=_NextPart_001_01C15199.74A2B170" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C15199.74A2B170 Content-Type: text/plain; charset="windows-1252" Thanks for the replies and help regarding the TMON Log switching...off to look into it. Stewart ************************************* Stewart Herd CICS/MQ Systems Programmer Perot Systems Cabinteley, Dublin 18, Ireland. E-mail: [log in to unmask] Phone: +353 1 217 7000 Ext 2692 Mobile; 00 44 7976 753521 ************************************* -----Original Message----- From: [log in to unmask] [mailto:[log in to unmask]] Sent: 10 October 2001 11:29 To: [log in to unmask] Subject: Re: TMON Logs Hi Stewart In our TMON-using environments we have activated the File Switch Utility feature, where a configuration file is telling TMON to do so. It can be seen in the log of the DLS address space as: WEDNESDAY, OCTOBER 10, 2001 00:00 LFS TMONPCSM RUNNING AS JOB TMONPDLS ON SYSTE SENDING 'SWITCH' TO LF(TMON01) IN RESPONSE TO TIMEDSWITCH(UDV) SUBMIT COMPLETE, MEMBER(TCEFSU), LDS(TMON01B), DSN(SYS3CICS.TMONCICS.V200.TMON01 SENDING 'SWITCH' TO LF(TMON02) IN RESPONSE TO TIMEDSWITCH(CICSGPP) SUBMIT COMPLETE, MEMBER(TCEFSU), LDS(TMON02B), DSN(SYS3CICS.TMONCICS.V200.TMON02 SENDING 'SWITCH' TO LF(TMON03) IN RESPONSE TO TIMEDSWITCH(PROD) SUBMIT COMPLETE, MEMBER(TCEFSU), LDS(TMON03A), DSN(SYS3CICS.TMONCICS.V200.TMON03 Have you got something like that? Best rgds, Michael Erichsen CSC Denmark ******************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify us immediately at [log in to unmask] and delete this E-mail from your system. Thank you. It is possible for data transmitted by email to be deliberately or accidentally corrupted or intercepted. For this reason, where the communication is by email, the Bank of Ireland Group does not accept any responsibility for any breach of confidence which may arise through the use of this medium. This footnote also confirms that this email message has been swept for the presence of known computer viruses. ******************************************************************** ------_=_NextPart_001_01C15199.74A2B170 Content-Type: text/html; charset="windows-1252" RE: TMON Logs

Thanks for the replies and help regarding the TMON Log switching...off to look into it.

Stewart

*************************************
Stewart Herd
CICS/MQ Systems Programmer
Perot Systems
Cabinteley, Dublin 18, Ireland.
E-mail: [log in to unmask]
Phone: +353 1 217 7000  Ext 2692
Mobile; 00 44 7976 753521
*************************************


-----Original Message-----
From: [log in to unmask] [mailto:[log in to unmask]]
Sent: 10 October 2001 11:29
To: [log in to unmask]
Subject: Re: TMON Logs


Hi Stewart

In our TMON-using environments we have activated the File Switch Utility
feature, where a configuration file is telling TMON to do so. It can be seen in
the log of the DLS address space as:

WEDNESDAY, OCTOBER 10, 2001  00:00 LFS TMONPCSM RUNNING AS JOB TMONPDLS ON SYSTE
SENDING 'SWITCH' TO LF(TMON01) IN RESPONSE TO TIMEDSWITCH(UDV)
SUBMIT COMPLETE, MEMBER(TCEFSU), LDS(TMON01B), DSN(SYS3CICS.TMONCICS.V200.TMON01
SENDING 'SWITCH' TO LF(TMON02) IN RESPONSE TO TIMEDSWITCH(CICSGPP)
SUBMIT COMPLETE, MEMBER(TCEFSU), LDS(TMON02B), DSN(SYS3CICS.TMONCICS.V200.TMON02
SENDING 'SWITCH' TO LF(TMON03) IN RESPONSE TO TIMEDSWITCH(PROD)
SUBMIT COMPLETE, MEMBER(TCEFSU), LDS(TMON03A), DSN(SYS3CICS.TMONCICS.V200.TMON03

Have you got something like that?

Best rgds,
Michael Erichsen
CSC Denmark



********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please
notify us immediately at [log in to unmask] and delete this E-mail
from your system. Thank you.
It is possible for data transmitted by email to be deliberately or
accidentally corrupted or intercepted. For this reason, where the
communication is by email, the Bank of Ireland Group does not accept
any responsibility for any breach of confidence which may arise
through the use of this medium.
This footnote also confirms that this email message has been swept
for the presence of known computer viruses.
********************************************************************

------_=_NextPart_001_01C15199.74A2B170-- ========================================================================Date: Wed, 10 Oct 2001 10:52:08 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Chase, John" <[log in to unmask]> Subject: Re: Question on dynamic CALL's under CICS MIME-Version: 1.0 Content-Type: text/plain On Wednesday, October 10, 2001 8:58 AM, Buckles, Stephen L. wrote: > For pitty sakes - make the assembler program AMODE(31) RMODE(ANY). > Doesn't > take that much work and will save you a lot of junior programmer headaches. ... such as, "how does an Amode(24) program return to an Rmode(Any) program that got loaded above the line?" -jc- ========================================================================Date: Wed, 10 Oct 2001 11:06:26 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Synoga, Jerry P. (RyTull)" <[log in to unmask]> Subject: Re: TMON Logs MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C151A5.8399E840" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C151A5.8399E840 Content-Type: text/plain; charset="iso-8859-1" Stewart, We use TMON and I force a switch at midnight. I have a definition in TCELFSPx(in samplib) that defines the switch definition and the frequency. I switch my files at midnight ( or they will switch if they become full). You may want to look at the TIMEDSWITCH parameter since you can set it up for many frequencies (days, minutes, times, weekdays,weekends). example of my timedswitch parameters: Jerry Synoga Ryerson Tull [log in to unmask] 630-758-2021 -----Original Message----- From: Stewart Herd [mailto:[log in to unmask]] Sent: Wednesday, October 10, 2001 5:11 AM To: [log in to unmask] Subject: TMON Logs TMON - We increased the sizes of our logs in TMON because they were switching too regularly, but we still seem to be switching regularly whether or not the logs are full, is there a parameter that requires to be changed to prevent the switching before the logs are actually full. Thanks ************************************* Stewart Herd CICS/MQ Systems Programmer Perot Systems Cabinteley, Dublin 18, Ireland. E-mail: [log in to unmask] Phone: +353 1 217 7000 Ext 2692 Mobile; 00 44 7976 753521 ************************************* ******************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify us immediately at [log in to unmask] and delete this E-mail from your system. Thank you. It is possible for data transmitted by email to be deliberately or accidentally corrupted or intercepted. For this reason, where the communication is by email, the Bank of Ireland Group does not accept any responsibility for any breach of confidence which may arise through the use of this medium. This footnote also confirms that this email message has been swept for the presence of known computer viruses. ******************************************************************** --- Legal Disclaimer: The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. Thank you. --- ------_=_NextPart_000_01C151A5.8399E840 Content-Type: image/bmp; name="Outlook..bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Outlook..bmp" Content-ID: <17595815@10102001-3500> Qk22GgAAAAAAAHYAAAAoAAAAGAEAADAAAAABAAQAAAAAAEAaAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAA4AAOAO7u7g AO7uAADu7gAO7u7gDgAA4ADu7gAADgAAAADgAA7u7gDgAADgAO7gAA7u7uAADgAAAAAAAAAOAAAA 7uAA4AAA4A7u7uAAAOAADu7u4ADu7gAA7u4AAA7gAA4AAAAOAAAADgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAOAAAADgAA4A4AAAAODgDgDgAA4A4AAAAOAA7gDgAA4AAOAAAADgAADgAA 4OAAAOAADgAADgAAAAAOAAAAAAAAAA4AAAAOAADgAADgDgAAAAAOAAAOAAAADgAA4A4AAOAAAA4A AOAAAADgAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAOAA4ADgAAAA4AAOAO AADgDgAAAA4ADuAOAAAAAA4AAAAOAAAOAADg4AAA4AAOAAAOAAAAAA4AAAAAAAAADgAAAA4AAOAA AOAOAAAAAA4AAADgAAAAAADgAAAA4AAADgAA4AAAAOAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAADgAAAA4ADgAOAAAADgAA4A4AAOAOAAAADgDg4A4AAAAADgAAAOAAAA4AAOAO7u4A AA4AAA4AAAAADgAAAAAAAAAOAAAADgAA4AAA4A4AAAAA4AAAAA4AAAAAAOAAAADgAAAA4AAOAAAA DgAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAADgDgAA4AAAAOAADgDgAA4A4A AAAOAODgDgAAAADu4AAA4AAADgAA4A4ADgAADgAADgAAAADu4AAAAAAAAA4AAAAOAADgAADgDgAA AADgAAAAAOAAAAAA4AAAAOAA7uDgAA4AAAAOAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA7u7gAO7u4ADu7gAA4AAOAOAADgDu7gAA4OAOAOAAAAAODgAADgAAAOAADgDgAOAAAOAAAO AAAAAODgAAAAAAAADgAAAA4AAOAOAOAO7uAAAOAAAAAADgAADu4ADu7uAA4ADuAADgAAAA4AAAAO AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAA4AAOAOAAAADgAA4A4AAOAOAAAADg4A 4A4AAAAOAA4AAOAAAA4AAOAA4OAAAA4AAA4AAAAOAA4AAAAAAAAOAAAADgAA4A4A4A4AAAAA4AAA AAAA4AAAAOAOAAAADgAA4AAOAAAADgAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO AAAADgAA4A4AAAAOAADgDgAA4A4AAAAO4ADgDgAAAA4ADgAA4AAADgAA4ADg4AAADgAADgAAAA4A DgAAAAAAAA4AAAAOAADg4ODgDgAAAADgAAAAAADgAAAA4A4AAAAOAADgAA4AAAAOAAAADgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAOAADgDgAAAA4AAOAOAADgDgAAAA7gAOAOAADg 4AAA4AAOAAAOAADgAA4AAAAOAAAOAAAA4AAA4AAAAAAADgAAAA4AAO4ADuAOAAAAAA4AAADgAOAO AADgDgAAAA4AAOAA4AAAAOAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADu7u4A7u 7gAO7u7gAO7uAA4AAOAO7u7gDgAA4ADu7gDgAADgAA4AAA7u7gAADgAAAO7gAA4AAADgAADgAAAA AO7u7uAA7uAA4AAA4A7u7uAADgAAAA7uAADu7gAO7u4AAO7uAADgAAAA4AAAAOAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAA AAAAAAAADgAAAA4AAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAOAADg4AAA4OAAAOAO7u7gAADgAOAAAOAA7uAADu7uAA4AAOAA7uAAAA4AAA7u7uAOAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4ADuDgAADg4AAA4A4AAAAADgAA4AAA4AAO AAAOAADgDgAO4AAOAAAADgAADgAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DgAO4OAAAODgAADgDgAAAAAOAADgAADgAA4AAA4AAOAOAA7gAA4AAAAOAAAOAAAAAOAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAODgDu7uAOAAAOAOAAAAAOAAAOAAAOAADgAADgAA 4A4A4OAADgAAAA4AAA4AAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4A4OAO AA4A4AAA4A4AAAAA4AAA4AAA4AAOAAAOAADgDgDg4AAOAAAADgAADgAAAAAOAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAADg4A4A4ADgDgDgDgDu7gAADgAADgDgDgAA4AAA4AAOAODgDg AA4AAAAOAAAO7uAAAA4AAAAAAAAAAAAAAAAAAA7u7uAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAODgDgAODgAOAO AOAOAAAAAOAAAOAOAOAADgAADgAA4A4OAOAADgAAAA4AAA4AAAAADgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA7gAOAA4OAA4ODg4A4AAAAA4AAA4ODg4AAOAAAOAADgDuAA4AAOAAAA DgAADgAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADuAA4AAOAADuAA7gDgAA AAAOAADuAA7gAA4AAA4AAOAO4ADgAA4AAAAOAAAOAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAOAADgAA4AAOAAAOAO7u7gAA4AAOAAAOAA7uAADu7uAA4AAOAA7uAA7u7u4A7u 7uAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAO7u4ADu7u4A4AAAAAAAAAAA4AAADu4ADgAADgDu7u4A7u7gAA7u4A4AAA4ADu4AAADgAAAO7u AA4AAOAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAOAOAAAADgAAAAAAAAAADgAAAA4AAOAAAOAO AAAADgAA4A4AAODuAA7gAA4AAAAOAAAOAADgDgAA4AAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAA 4A4AAAAOAAAAAAAAAAAOAAAADgAA4AAA4A4AAAAOAADgAAAA4ODg4OAADgAAAA4AAA4AAAAOAADg AA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAADgDgAAAA4AAAAAAAAAAA4AAAAOAADgAADgDgAAAA4A AOAAAADg4A4A4AAOAAAADgAADgAAAA4AAOAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAOAOAAAA DgAAAAAAAAAADgAAAA4AAOAAAOAOAAAADgAA4AAA7gDgDgDgAA4AAAAOAAAOAAAADgAA4ADgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAADgAA4A7u4AAO7u4AAAAAAAAOAAAADgAA4A4A4A7u4AAOAADgAO4A AOAAAOAADgAAAA4AAA4AAAAO7u7gAOAAAAAAAAAAAAAADu7u4AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAADgDgAAAA4AAAAA AAAAAA4AAAAOAADgDgDgDgAAAA4AAOAOAAAA4AAA4AAOAAAADgAADgAAAA4AAOAA4AAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA4AAOAOAAAADgAAAAAAAAAADgAAAA4AAODg4OAOAAAADgAA4A4AAADgAADg AA4AAAAOAAAOAAAADgAA4ADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAA4A4AAAAOAAAAAAAAAAAO AAAADgAA7gAO4A4AAAAOAADgDgAA4OAAAOAADgAAAA4AAA4AAOAOAADgAA4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAO7u4ADu7u4A7u7uAAAAAA7u7u4ADu4ADgAADgDu7u4A7u7gAA7u4A4AAA4ADu4ADu 7u7gAO7uAA4AAOAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------_=_NextPart_000_01C151A5.8399E840 Content-Type: image/bmp; name="Outlook..bmp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Outlook..bmp" Content-ID: <17595815@10102001-3507> Qk12UgAAAAAAAHYAAAAoAAAASAEAAIAAAAABAAQAAAAAAABSAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgAAAgAAAAICAAIAAAACAAIAAgIAAAICAgADAwMAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAOAAAA7uAA4AAA4A7u7uAO7u4AAO7uAOAAAOAA7uAAAA4AAADu7gAOAADgAADgAOAAAOAA7uAA Du7uAA4AAOAA7uAAAA4AAA7u7uAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAO AADgAADgDgAAAA4AAOAOAADg7gAO4AAOAAAADgAADgAA4A4AAOAADgAA4AAA4AAOAAAOAADgDgAO 4AAOAAAADgAADgAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAA4AAOAAAOAO AAAADgAA4AAAAODg4ODgAA4AAAAOAAAOAAAADgAA4AAOAADgAADgAA4AAA4AAOAOAA7gAA4AAAAO AAAOAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAADgAA4AAA4A4AAAAOAADg AAAA4OAOAOAADgAAAA4AAA4AAAAOAADgAOAAAOAAAOAADgAADgAA4A4A4OAADgAAAA4AAA4AAAAA DgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAOAADgAADgDgAAAA4AAOAAAO4A4A4A 4AAOAAAADgAADgAAAA4AAOAA4AAA4AAA4AAOAAAOAADgDgDg4AAOAAAADgAADgAAAAAOAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAA4AAOAOAOAO7uAADgAA4ADuAADgAADgAA4AAAAO AAAOAAAADu7u4ADgAADgDgDgAA4AAA4AAOAODgDgAA4AAAAOAAAO7uAAAA4AAAAAAAAO7u7gAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAOAAAADgAA4A4A4A4AAAAOAADgDgAAAOAAAOAADgAAAA4AAA4AAAAO AADgAOAAAOAOAOAADgAADgAA4A4OAOAADgAAAA4AAA4AAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA4AAAAOAADg4ODgDgAAAA4AAOAOAAAA4AAA4AAOAAAADgAADgAAAA4AAOAA4AAA 4ODg4AAOAAAOAADgDuAA4AAOAAAADgAADgAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADgAAAA4AAO4ADuAOAAAADgAA4A4AAODgAADgAA4AAAAOAAAOAADgDgAA4AAOAADuAA7gAA4A AA4AAOAO4ADgAA4AAAAOAAAOAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO7u7uAA 7uAA4AAA4A7u7uAO7u4AAO7uAOAAAOAA7uAA7u7u4ADu7gAOAADgAA4AAOAAAOAA7uAADu7uAA4A AOAA7uAA7u7u4A7u7uAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADgAAAA4AAOAA7u4ADu7uAADu7gAA7u4AAA4AAA4AAADgAADgDgAA4OAAAOAAAOAAAA4AAOAA AOAA7u4ADgAA4ADu7gAADgAAAO7gAAAAAAAA7u4ADgAA4ADu4AAADgAAAO7gAADu7gDgAADgDu7u 4AAA4AAADgAADu7u4ADu7gAOAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAA DgAA4A4AAOAOAADgDgAA4A4AAOAADgAADgAAAOAAAOAOAADg4AAA4AAOAAAADgAA4AAA4A4AAOAO AA7gDgAA4AAOAAAADgAAAAAAAA4AAOAOAADgAA4AAAAOAAAADgAADgAA4OAAAOAOAAAAAA4AAAAO AAAOAAAADgAA4ADgAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAOAA4ADgAA 4A4AAOAOAADgDgAAAAAOAAAOAAAA4AAA4A4ADgDgAADgAA4AAAAOAADgAADgDgAA4A4ADuAOAADg AA4AAAAOAAAAAAAADgAAAA4ADgAADgAAAA4AAAAOAAAOAAAA4AAA4A4AAAAADgAAAA4AAA4AAAAA AADgAOAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAA4ADgAOAADgDgAA4A4A AOAOAAAAAA4AAA4AAAAO7u4ADgAOAOAAAOAA4AAAAA4AAOAAAOAOAADgDgDg4A4AAOAADgAAAA4A AAAAAAAOAAAADgAOAAAOAAAADgAAAA4AAA4AAAAO7u4ADgAAAADgAAAADgAADgAAAAAAAOAADgAA AA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAADgDgAA4AAOAOAADgDgAA4A4AAAAA DgAADgAAAA4ADgAOAOAA4AAA4ADgAAAADgAA4AAA4A4AAOAOAODgDuAA4AAA4AAADgAAAAAAAA4A AAAOAOAAAA4AAAAOAAAADgAADgAAAA4ADgAOAAAAAOAAAADu4AAOAAAAAADuAAAOAAAADgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7u7gAO7u4ADgAA4A4AAOAOAADgDgAAAAAOAAAO7u4A DgAOAA7u7gDgDgDgAOAAAAAOAADgDgDgDgAA4A4OAOAODu4AAADgAAAOAAAAAAAADgAAAA7u7gAA DgAAAA4AAAAOAAAOAAAADgAOAA4AAAAA4AAAAODgAA7u4AAA7gAAAA4AAAAOAAAAAAAADu7u4AAA AAAAAAAAAAAAAAAAAAAAAAAADgAA4A4AAOAOAADgDgAA4A4AAOAOAAAAAA4AAA4AAOAA4OAADgAA 4OAOAOAA4AAAAA4AAOAOAOAOAADgDg4A4ADgAAAAAA4AAA4AAAAAAAAOAAAADgAA4AAOAAAADgAA AA4AAA4AAAAA4OAADgAAAADgAAAOAA4ADgAAAA4AAAAADgAAAA4AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAOAADgDgAA4A4AAOAOAADgDgAA4A4AAAAADgAADgAA4ADg4AAOAADg4ODg4ADg AAAADgAA4ODg4A4AAOAO4ADgAOAAAAAADgAADgAAAAAAAA4AAAAOAADgAA4AAAAOAAAADgAADgAA AADg4AAOAAAAAOAAAA4ADgAOAAAADgAAAAAOAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA4AAOAOAADgDgAA4A4AAOAOAADgDgAA4AAOAAAOAADgAA4AAA4AAODuAA7gAA4AAAAOAADu AA7gDgAA4A7gAOAADgAAAAAA4ADuAAAAAAAADgAA4A4AAOAADgAAAA4AAAAOAAAOAADgAA4AAA4A AAAADgAA4AAA4A4AAAAOAADgAOAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADu7u AA7u7gAA7u4ADu7uAA4AAOAA7u4A7u7u4A7u7gAADgAADu7uAOAAAOAADgAA7u7u4OAAAOAA7u4A DgAA4AAA4AAO7u7gAA4AAAAAAAAA7u4ADu7uAADu4ADu7u7gAO7gAADu7gAADgAADgAAAAAOAADg AADgDu7u4ADu7gAA4AAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAAAAAAAA AAAAAA4AAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADgAADgDu7u4A7u7uAOAAAAAO7uAA7u7uAO7u7gAADgAADu7gAADgAADu7u4A4AAODgAADg DgAA4ADu4AAADgAADu7u4A4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAA AOAOAAAADgAAAA4AAAAOAADgDgAAAA4AAAAADgAADgAA4AAOAAAOAAAADgAA4O4ADuAOAADgAA4A AAAOAAAOAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAA4A4AAAAO AAAADgAAAA4AAOAOAAAADgAAAAAOAAAOAADgAODgAA4AAAAOAA4A4ODg4A4ADgAADgAAAA4AAA4A AAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO7u4ADgAAAA4AAAAOAAAA DgAA4A4AAAAOAAAAAOAAAA4AAOAA4OAADgAAAA4ADgDgDgDgDgAOAAAOAAAADgAADgAAAAAOAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4ADgAOAAAADgAAAA4AAAAOAADgDgAA AA4AAAAA4AAADgAA4A4ADgAOAAAADgDgAOAOAOAOAOAAAA4AAAAOAAAOAAAAAA4AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAOAA4AAAAOAAAADu7uAA4AAOAOAAAADgAAAADg AAAOAADgDgAOAA7u4AAO7u4A4AAA4A7u7gAADgAAAA4AAA7u4AAADgAAAAAAAA7u7uAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA4OAADgAAAA4AAAAOAAAADgAA4A4AAAAOAAAAAOAAAA4AAOAO AA4ADgAAAA4AAODgAADgDgAA4AAOAAAADgAADgAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADg4AAOAAAADgAAAA4AAAAOAADgDgAAAA4AAAAA4AAADgAA4OAAAOAOAAAA DgAA4OAAAOAOAADgAA4AAAAOAAAOAAAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA4AAA4AAAAOAAAADgAAAA4AAOAOAAAADgAAAAAOAAAOAADg4AAA4A4AAAAOAADg4AAA 4A4AAOAADgAAAA4AAA4AAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DgAADgAAAA4AAAAO7u7gDgAA4A4AAAAOAAAAAA4AAADu7gDgAADgDu7u4A7u7gDgAADgDu7uAADu 4ADu7u7gDu7u4ADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADu7gAA7u4A4AAA4A4AAAAOAADgDu7u4ADu7gAA7u4AAADgAAAOAAAO7u7gAO7uAA4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DgAA4A4AAODgAADgDgAAAA4AAOAOAAAADgAA4A4AAOAADgAAAA4AAA4AAAAOAADgAOAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAADgAA 4OAAAOAOAAAADgAOAA4AAAAAAADgAAAA4AAOAAAADgAADgAAAAAAAOAA4AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAOAADg4AAA4A4A AAAOAA4ADgAAAAAAAOAAAADgAOAAAAAOAAAOAAAAAAAA4AAOAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAA4AAODgAADgDgAAAA4A4AAO AAAAAADuAAAA7gAA4AAAAO7gAA4AAAAAAO4AAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAADgAA4OAOAOAO7u4ADu7uAA7u4AAA7gAA AO4AAADgAAAA4OAADu7gAADuAAAADgAAAAAAAA7u7uAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAOAADg4A4A4A4AAOAOAADgDgAAAA4AAAAOAAAAAOAA AA4ADgAOAAAADgAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAADgAAAA4AAODg4ODgDgAA4A4AAOAOAAAADgAAAA4AAAAA4AAADgAOAA4A AAAOAAAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAOAADgDgAA4O4ADuAOAADgDgAA4A4AAAAOAADgDgAA4AAOAADgAADgDgAAAA4AAOAA 4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AADu7gAA7u4A4AAA4A7u7gAO7u4ADu7u4ADu7gAA7u4AAA4AAOAAAOAO7u7gAO7uAADgAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAADu7u4A7u7gAA7u4AAADgAAAOAADgAADgAO7uAA4AAOAA7u4AAO7gAOAAAOAADuAA AA4AAOAAAOAA7u4ADgAA4ADu7gAA7uAADu7uAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAOAAAADgAA4A4AAOAADgAAAA4AAOAAAOAOAADgDgAO4A7gAOAADgAA4AAA4AAAAAAADgAA4AAA 4A4AAOAOAA7gDuAA4AAOAAAOAADgAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAO AADgAAAA4AAOAAAADgAA4AAA4A4AAOAOAA7gDuAA4AAOAADgAADgAAAAAAAOAADgAADgDgAA4A4A DuAO4ADgAA4AAA4AAOAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAA4AAOAAAADg AOAAAAAOAADgAADgDgAA4A4A4OAODgDgAA4AAA7u7gAAAAAAAA4AAOAAAOAOAADgDgDg4A4OAOAA DgAADgAA4AAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAAADgAA4AAA7gAA4AAAAA4A AOAAAOAOAADgDgDg4A4OAOAADgAADgAOAAAAAAAADgAA4AAA4A4AAOAOAODgDg4A4AAOAAAOAADg AA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAAAOAADgAO4AAADgAAAADgAA4A4A4A4A AOAODgDgDgDg4AAOAAAOAA4AAAAAAAAOAADgDgDgDgAA4A4OAOAOAODgAA4AAA7u7gAADgAAAAAA AA7u7uAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAA4AAOAOAAAAAOAAAAAOAADgDgDgDgAA4A4OAOAO AODgAA4AAADg4AAAAAAAAA4AAOAOAOAOAADgDg4A4A4A4OAADgAADgAA4AAOAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAOAAAADgAA4A4AAAAA4AAAAA4AAODg4OAOAADgDuAA4A4ADuAADgAA AODgAAAAAAAADgAA4ODg4A4AAOAO4ADgDgAO4AAOAAAOAADgAA4AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA4AAAAOAADgDgAA4AAOAAAADgAA7gAO4A4AAOAO4ADgDgAO4ADuAAAADgAAAAAA AAAOAADuAA7gDgAA4A7gAOAOAA7gAO4AAA4AAOAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADgAAAA7u7gAA7u4AAA4AAO7u7uDgAADgAO7uAA4AAOAA7u4AAA4AAAAOAAAAAAAA7u7u4OAA AOAA7u4ADgAA4ADu7gAADgAADu7uAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAOAADg4AAA4OAAAOAO7u7gAADgAAAOAADgAADgAO7uAA4AAOAA7u4AAO7gAA4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA4ADuDgAADg4AAA4A4AAAAADgAAAA4AAOAAAOAOAADgDgAO4A7gAOAADgAAAOAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAO 4OAAAODgAADgDgAAAAAOAAAADgAA4AAA4A4AAOAOAA7gDuAA4AAOAAAA4AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAODgDu7uAOAA AOAOAAAAAOAAAAAOAADgAADgDgAA4A4A4OAODgDgAA4AAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4A4OAOAA4A4AAA4A4AAAAA 4AAAAA4AAOAAAOAOAADgDgDg4A4OAOAADgAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADg4A4A4ADgDgDgDgDu7gAADgAAAADgAA 4A4A4A4AAOAODgDgDgDg4AAOAAAADgAAAAAAAA7u7uAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAODgDgAODgAOAOAOAOAAAAAOAAAAAOAADgDgDgDgAA 4A4OAOAOAODgAA4AAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA7gAOAA4OAA4ODg4A4AAAAA4AAAAA4AAODg4OAOAADgDuAA4A4A DuAADgAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADuAA4AAOAADuAA7gDgAAAAAOAAAADgAA7gAO4A4AAOAO4ADgDgAO4ADuAAAA 4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAOAADgAA4AAOAAAOAO7u7gAA4AAO7u7uDgAADgAO7uAA4AAOAA7u4AAA4AAADgAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADu7u AA7u7uAOAAAAAAAAAA7u7uAOAAAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAADgDgAAAA4A AAAAAAAADgAAAA4AAAAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAOAOAAAADgAAAAAAAAAO AAAADgAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAA4A4AAAAOAAAAAAAAAA4AAAAOAAAA AOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAADgDgAAAA4AAAAAAAAADgAAAA4AAAAA4AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA4AAOAO7uAADu7uAAAAAAAOAAAADu7uAADgAAAAAAAADu7u4AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADgAA4A4AAAAOAAAAAAAAAA4AAAAOAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAOAADgDgAAAA4AAAAAAAAADgAAAA4AAAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4A AOAOAAAADgAAAAAAAAAOAAAADgAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADu7uAA7u7uAO 7u7gAAAAAA4AAAAO7u7gAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA ------_=_NextPart_000_01C151A5.8399E840-- ========================================================================Date: Wed, 10 Oct 2001 11:19:28 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Synoga, Jerry P. (RyTull)" <[log in to unmask]> Subject: Re: TMON Logs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" resending reply with text format instead of bmp images(did something wrong there-sorry)) Stewart, We use TMON and I force a switch at midnight. I have a definition in TCELFSPx(in samplib) that defines the switch definition and the frequency. I switch my files at midnight ( or they will switch if they become full). You may want to look at the TIMEDSWITCH parameter since you can set it up for many frequencies (days, minutes, times, weekdays,weekends). example of my timedswitch parameters: DEF TIMEDSWITCH( - NAME(MIDNITE) - FREQUENCY(DAILY TIME(2359))) DEF LF( - NAME(TMON01) - LDS(TMON01A,TMON01B) - COMPRESS(YES) - ALLFULL(OVERWRITE) - PRODUCTPARM(TMON671 CRITICAL(YES)) - TIMEDSWITCH(MIDNITE) - ) -----Original Message----- From: Stewart Herd [mailto:[log in to unmask]] Sent: Wednesday, October 10, 2001 5:11 AM To: [log in to unmask] Subject: TMON Logs TMON - We increased the sizes of our logs in TMON because they were switching too regularly, but we still seem to be switching regularly whether or not the logs are full, is there a parameter that requires to be changed to prevent the switching before the logs are actually full. Thanks ************************************* Stewart Herd CICS/MQ Systems Programmer Perot Systems Cabinteley, Dublin 18, Ireland. E-mail: [log in to unmask] Phone: +353 1 217 7000 Ext 2692 Mobile; 00 44 7976 753521 ************************************* ******************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify us immediately at [log in to unmask] and delete this E-mail from your system. Thank you. It is possible for data transmitted by email to be deliberately or accidentally corrupted or intercepted. For this reason, where the communication is by email, the Bank of Ireland Group does not accept any responsibility for any breach of confidence which may arise through the use of this medium. This footnote also confirms that this email message has been swept for the presence of known computer viruses. ******************************************************************** --- Legal Disclaimer: The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. Thank you. --- --- Legal Disclaimer: The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. Thank you. --- ========================================================================Date: Wed, 10 Oct 2001 11:08:22 -0700 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Chin, Sherman" <[log in to unmask]> Subject: AAL1 Abends MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Could someone give me a clue as to what causes AAL1 abends. We've been getting a lot of these lately. I checked with our systems staff and they've indicated that no patches have been applied to CICS or DB2. They also indicated that DTIMOUT=NO when I asked them about the timeout parameter. Is there somewhere else I can dig regarding this abend. Thanks... P.S. We are on CICS V4R1 and DB2 V6 Sherm Chin <> email [log in to unmask] Administrative <> voice (415) 476-5627 Computing, <> fax (415) 476-8544 UCSF <> pager (415) 719-9960 ========================================================================Date: Wed, 10 Oct 2001 13:31:50 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "McKown, John" <[log in to unmask]> Subject: Re: AAL1 Abends MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit That is documented in "CICS® Transaction Server for OS/390®: CICS Messages and Codes" which states: AAL1 Explanation: DFHALP was processing a request that deadlocked. The most likely reason for the abend is that an ALLOCATE QUEUE request has been suspended because there are no contention-winning links available. System Action: CICS terminates the task abnormally. A dump is taken only if the abend is nontime-out related. A dump is not taken for stall purges and deadlock time-outs. User Response: Ensure that there are enough contention-winning sessions available to satisfy the ALLOCATE QUEUE request. If you are running with modegroups, ensure that there are contention-winning sessions available to satisfy the ALLOCATE request in that modegroup. It might be necessary to increase the deadlock timeout (DTIMEOUT) value for the transaction to prevent this abend from recurring. Sounds to me like you are using MRO for cross region communications (TOR + AOR?) and there there are not enough queues. Look at the MRO connection and the "Queuelimit" and "Maxqtime" parameters. On our system, we have "NO" specified. This is in the CONNECTION type in CEDA. In the SESSION type, look at the RECEIVECOUNT and SENDCOUNT parameters. We have 15, but not for any particular reason that I can see. Look in "CICS® Transaction Server for OS/390®: CICS Intercommunication Guide" which says: QUEUELIMIT defines the maximum number of allocate requests that CICS is to queue while waiting for free sessions on the connection. You can specify a number in the range 0 (that is, do not queue any requests) through 9999; or that all requests should be queued, if necessary, no matter what the length of the queue. MAXQTIME defines the approximate time for which allocate requests should queue for free sessions on a connection that appears to be unresponsive. Its value is used only if a queue limit is specified on QUEUELIMIT, and if that limit is reached. You can specify a time in the range 0 (that is, the queue should be purged immediately after receipt of an allocate request that would exceed the queue limit) through 9999 seconds; or that requests should be queued for as long as necessary. ---------------------------------------------------------------------- John McKown HealthAxis All opinions are my own and are not the opinions of my employer. Unsolicited telephone calls from vendors are NOT appreciated and tend to upset my management. Where does bad light end up? In a prism! (Gary Lisica) > -----Original Message----- > From: Chin, Sherman [SMTP:[log in to unmask]] > Sent: Wednesday, October 10, 2001 1:08 PM > To: [log in to unmask] > Subject: AAL1 Abends > > Hi > > Could someone give me a clue as to what causes AAL1 abends. We've been > getting a lot of these lately. I checked with our systems staff and > they've indicated that no patches have been applied to CICS or DB2. They > also indicated that DTIMOUT=NO when I asked them about the timeout > parameter. Is there somewhere else I can dig regarding this abend. > > Thanks... > > P.S. > > We are on CICS V4R1 and DB2 V6 > > > Sherm Chin <> email [log in to unmask] > Administrative <> voice (415) 476-5627 > Computing, <> fax (415) 476-8544 > UCSF <> pager (415) 719-9960 ========================================================================Date: Wed, 10 Oct 2001 14:31:54 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Anne Crabtree <[log in to unmask]> Subject: Re: AAL1 Abends Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit From Quickref: -------------------------------------------------------------------------- AAL1 Explanation: DFHALP was processing a request that deadlocked. The most likely reason for the abend is that an ALLOCATE QUEUE request has been suspended because there are no contention-winning links available. System Action: CICS terminates the task abnormally. A dump is taken only if the abend is nontime-out related. A dump is not taken for stall purges and deadlock time-outs. User Response: Ensure that there are enough contention-winning sessions available to satisfy the ALLOCATE QUEUE request. If you are running with modegroups, ensure that there are contention-winning sessions available to satisfy the ALLOCATE request in that modegroup. It might be necessary to increase the deadlock timeout (DTIMEOUT) value for the transaction to prevent this abend from recurring. Module: DFHALP >>> "Chin, Sherman" <[log in to unmask]> 10/10/01 02:08PM >>> Hi Could someone give me a clue as to what causes AAL1 abends. We've been getting a lot of these lately. I checked with our systems staff and they've indicated that no patches have been applied to CICS or DB2. They also indicated that DTIMOUT=NO when I asked them about the timeout parameter. Is there somewhere else I can dig regarding this abend. Thanks... P.S. We are on CICS V4R1 and DB2 V6 Sherm Chin <> email [log in to unmask] Administrative <> voice (415) 476-5627 Computing, <> fax (415) 476-8544 UCSF <> pager (415) 719-9960 ========================================================================Date: Wed, 10 Oct 2001 13:41:33 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Chase, John" <[log in to unmask]> Subject: Re: AAL1 Abends MIME-Version: 1.0 Content-Type: text/plain On Wednesday, October 10, 2001 1:08 PM, Chin, Sherman wrote: > Hi > > Could someone give me a clue as to what causes AAL1 abends. We've been > getting a lot of these lately. I checked with our systems staff and > they've indicated that no patches have been applied to CICS or DB2. > They also indicated that DTIMOUT=NO when I asked them about the timeout > parameter. Is there somewhere else I can dig regarding this abend. Here's what the CICS Messages and Codes manual says about it: ====== Begin Inserted Text ======AAL1 Explanation: DFHALP was processing a request that deadlocked. The most likely reason for the abend is that an ALLOCATE QUEUE request has been suspended because there are no contention-winning links available. System Action: CICS terminates the task abnormally. A dump is taken only if the abend is nontime-out related. A dump is not taken for stall purges and deadlock time-outs. User Response: Ensure that there are enough contention-winning sessions available to satisfy the ALLOCATE QUEUE request. If you are running with modegroups, ensure that there are contention-winning sessions available to satisfy the ALLOCATE request in that modegroup. It might be necessary to increase the deadlock timeout (DTIMEOUT) value for the transaction to prevent this abend from recurring. ====== End Inserted Text ====== -jc- ========================================================================Date: Wed, 10 Oct 2001 14:46:43 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Bob Juch <[log in to unmask]> Subject: Re: AAL1 Abends MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii You attempted to run more transactions over a connection than you had winning sessions. That might be due to a slowdown or hang on the other system. If you'd rather have your users wait instead of abend, you can put all routed transactions to the system in a TCLASS with a limit equal to the number of winning sessions. If you download my demo of Super CEMT from http://www.CICSCentral.com, it will be easier for you to see the statistics for that connection. Bob Juch CICS and MQSeries Support Canon USA "Chin, Sherman" <[log in to unmask] To: [log in to unmask] .EDU> cc: Sent by: CICS Subject: [CICS-L] AAL1 Abends List 10/10/2001 02:08 PM Please respond to CICS List Hi Could someone give me a clue as to what causes AAL1 abends. We've been getting a lot of these lately. I checked with our systems staff and they've indicated that no patches have been applied to CICS or DB2. They also indicated that DTIMOUT=NO when I asked them about the timeout parameter. Is there somewhere else I can dig regarding this abend. Thanks... P.S. We are on CICS V4R1 and DB2 V6 Sherm Chin <> email [log in to unmask] Administrative <> voice (415) 476-5627 Computing, <> fax (415) 476-8544 UCSF <> pager (415) 719-9960 ========================================================================Date: Wed, 10 Oct 2001 14:27:53 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Gaskell, James" <[log in to unmask]> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C151C1.A8619530" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C151C1.A8619530 Content-Type: text/plain; charset="iso-8859-1" SET CICS-L DIGEST ------_=_NextPart_001_01C151C1.A8619530 Content-Type: text/html; charset="iso-8859-1"

SET CICS-L DIGEST

------_=_NextPart_001_01C151C1.A8619530-- ========================================================================Date: Thu, 11 Oct 2001 01:01:58 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Mark Hawkes <[log in to unmask]> Subject: MARK HAWKES/Phoenix Home Life Mutual Insurance is out of the office. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I will be out of the office from 10/11/2001 until 10/15/2001. Please direct any issues through the On-call Tech. You can reach this person through the Service Center x2500. Regards, Mark ========================================================================Date: Thu, 11 Oct 2001 11:09:50 +0530 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Ramesh Aripak <[log in to unmask]> Subject: Map Field Changed. MIME-Version: 1.0 Content-Type: text/plain Hi List, Could anyone please gimme the code to check a field on the map is changed. Thanks in Advance. Ramesha. ========================================================================Date: Thu, 11 Oct 2001 09:36:09 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Flint, Mike" <[log in to unmask]> Subject: Re: Map Field Changed. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Ramesha, You need to check the length attribute of the input field ... this contains the length of any data typed into the field, AND the attribute byte to see if the entire field has been cleared using the 'EOF' key. For an alphanumeric field, something like : IF FIELD-L > 0 MOVE FIELD-I TO .......... ELSE IF FIELD-A = DFHBMEOF MOVE SPACE TO .......... END-IF END-IF. Note that the attribute byte can contain different bit settings if you have field cursor positioning enabled (you've used CURSLOCN in the map definition). See section 4.3 of the Application Programming Guide (SC33-1169) which describes BMS support (especially the section on 'Modified Data'). -----Original Message----- From: Ramesh Aripak [mailto:[log in to unmask]] Sent: 11 October 2001 06:40 To: [log in to unmask] Subject: Map Field Changed. Hi List, Could anyone please gimme the code to check a field on the map is changed. Thanks in Advance. Ramesha. ======================================================================Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF ========================================================================Date: Thu, 11 Oct 2001 08:35:55 -0600 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Rakesh Kaushika <[log in to unmask]> Subject: Re: Map Field Changed. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Checking the length attribute is good when you do not have yr modified data tag (FSET) permanently on.If FSET is on permanently then you would always get Field-L > 0. Thanks Rakesh -----Original Message----- From: Flint, Mike [mailto:[log in to unmask]] Sent: Thursday, October 11, 2001 2:36 AM To: [log in to unmask] Subject: Re: Map Field Changed. Ramesha, You need to check the length attribute of the input field ... this contains the length of any data typed into the field, AND the attribute byte to see if the entire field has been cleared using the 'EOF' key. For an alphanumeric field, something like : IF FIELD-L > 0 MOVE FIELD-I TO .......... ELSE IF FIELD-A = DFHBMEOF MOVE SPACE TO .......... END-IF END-IF. Note that the attribute byte can contain different bit settings if you have field cursor positioning enabled (you've used CURSLOCN in the map definition). See section 4.3 of the Application Programming Guide (SC33-1169) which describes BMS support (especially the section on 'Modified Data'). -----Original Message----- From: Ramesh Aripak [mailto:[log in to unmask]] Sent: 11 October 2001 06:40 To: [log in to unmask] Subject: Map Field Changed. Hi List, Could anyone please gimme the code to check a field on the map is changed. Thanks in Advance. Ramesha. ======================================================================Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF ========================================================================Date: Thu, 11 Oct 2001 09:21:27 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: [log in to unmask] Subject: CICS Universal Client DLL's MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Where do I find the following DLLs (COM objects) needed by VB programs to access CICS via the CTG using Universal Clients V3.1: CCLIECI.DLL CCLIEPI.DLL This is the link to the pdf programming guide for the COM interface for the Universal Clients v3.1. It describes these DLL's: ftp://ftp.software.ibm.com/software/cics/ccl/cclhaq00.pdf Environment: OS/390 2.9 CICS/TS 1.3 CICS/CTG 3.1.3 Thanks, Jim Laney State of Alabama Finance - ISD Tech Support [log in to unmask] ========================================================================Date: Thu, 11 Oct 2001 11:22:38 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Yeh, Jeff" <[log in to unmask]> Subject: LINK vs. CALL in Cics MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi All, In our team we are debating about the LINK vs. CALL in CICS environment. To my knowledge, the LINK is more "distributed" but a little bit performance disadvantage. CALL is better in performance, but is not "distributed." IBM also recommends to use CALL in LE. I am not so sure what that means. Can anyone give me some feedback? Thanks. Jeff ========================================================================Date: Thu, 11 Oct 2001 08:07:08 -0700 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Walt Blanding <[log in to unmask]> Organization: Washington Mutual Subject: CICS TS1.3 and XLNACTION connection parm MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit After we went to TS1.3 we started getting connections in a Pending state. We are receiving message DFHRS2111 cicsprdo cold/warm restart mismatch with system prd5 netname cicsprd5 protocol APPC. We looked in the manuals and have found that we could use the parm XLNACTION(FORCE) to reestablish the connection, using the indoubt attributes of the transaction. This sounds correct to us. What we were wondering is, has anyone had any problems using the parm with FORCE and if so what were they and how did you get around them? Did you have to go back to using KEEP? Is there any other way around this issue? Thanks for any info you might have on this. Another question also comes to mind on this or something like this is that some connections get a XNO status (XINSTATUS, exchange log names flow for APPC connections has not completed successfully). They seem to be getting this on VTAM type failures and it is new with TS1.3. Are then any parms that control this? Any one else having more problems with this now? Any suggestions/info? Thanks for the help. Walt -- Walt Blanding 206-461-6633 [log in to unmask] Washington Mutual Bank Seattle Wa ========================================================================Date: Thu, 11 Oct 2001 12:17:50 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "McKown, John" <[log in to unmask]> Subject: Re: LINK vs. CALL in Cics MIME-Version: 1.0 Content-Type: text/plain Jeff, I didn't know that IBM recommended using CALL instead of EXEC CICS LINK. I perfer LINK because if the subroutine abends, the CICS dump correctly identifies the module that abended. If you do a CALL (or chain of CALLs), then CICS reports that the abend occurred in the last program which was LINK'ed to. This may well be the initial program and the actual abend in a program "n" levels deep in CALLs. I don't know if the other abend processors such as AbendAid have this problem or not. Just my take on it. ---------------------------------------------------------------------- John McKown HealthAxis All opinions are my own and are not the opinions of my employer. Unsolicited telephone calls from vendors are NOT appreciated and tend to upset my management. Where does bad light end up? In a prism! (Gary Lisica) > -----Original Message----- > From: Yeh, Jeff [SMTP:[log in to unmask]] > Sent: Thursday, October 11, 2001 10:23 AM > To: [log in to unmask] > Subject: LINK vs. CALL in Cics > > Hi All, > > In our team we are debating about the LINK vs. CALL in CICS environment. > To > my knowledge, the LINK is more "distributed" but a little bit performance > disadvantage. CALL is better in performance, but is not "distributed." > IBM > also recommends to use CALL in LE. I am not so sure what that means. Can > anyone give me some feedback? Thanks. > > Jeff ========================================================================Date: Thu, 11 Oct 2001 10:24:28 -0700 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Bob Halpern <[log in to unmask]> Organization: CPU http://www.CPUperform.com Subject: Re: LINK vs. CALL in Cics MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Link is almost identical overhead as a new transaction - very high. Call requires either external call (high overhead) or direct binding - low overhead. Being performance oriented, I alsways set up things for direct call. "Yeh, Jeff" wrote: > > Hi All, > > In our team we are debating about the LINK vs. CALL in CICS environment. To > my knowledge, the LINK is more "distributed" but a little bit performance > disadvantage. CALL is better in performance, but is not "distributed." IBM > also recommends to use CALL in LE. I am not so sure what that means. Can > anyone give me some feedback? Thanks. > > Jeff ========================================================================Date: Thu, 11 Oct 2001 12:29:46 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "McKown, John" <[log in to unmask]> Subject: Re: LINK vs. CALL in Cics MIME-Version: 1.0 Content-Type: text/plain Bob, Isn't still true that statically linked (CALL literal) subroutines are not allowed to issue EXEC CICS commands? Or has that restriction been lifted? If it has, on what version of CICS? Using dynamic linkage (CALL identifier) allows the subroutine to issue EXEC CICS commands. ---------------------------------------------------------------------- John McKown HealthAxis All opinions are my own and are not the opinions of my employer. Unsolicited telephone calls from vendors are NOT appreciated and tend to upset my management. Where does bad light end up? In a prism! (Gary Lisica) > -----Original Message----- > From: Bob Halpern [SMTP:[log in to unmask]] > Sent: Thursday, October 11, 2001 12:24 PM > To: [log in to unmask] > Subject: Re: LINK vs. CALL in Cics > > Link is almost identical overhead as a new transaction - very > high. Call requires either external call (high overhead) or > direct binding - low overhead. Being performance oriented, I > alsways set up things for direct call. > > ========================================================================Date: Thu, 11 Oct 2001 12:42:37 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Thompson, William (DISA Oklahoma City)" <[log in to unmask]> Subject: Re: LINK vs. CALL in Cics MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" John; IIRC, passing the two EIB addresses to the statically called routine will allow that routine to do EXEC CICS commands.... -----Original Message----- From: McKown, John [mailto:[log in to unmask]] Sent: Thursday, October 11, 2001 12:30 PM To: [log in to unmask] Subject: Re: LINK vs. CALL in Cics Bob, Isn't still true that statically linked (CALL literal) subroutines are not allowed to issue EXEC CICS commands? Or has that restriction been lifted? If it has, on what version of CICS? Using dynamic linkage (CALL identifier) allows the subroutine to issue EXEC CICS commands. snip ========================================================================Date: Thu, 11 Oct 2001 15:14:12 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Jones, Phil" <[log in to unmask]> Subject: DBCTL/CICS query MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, Does anyone know if there is a way from a program to query whether the DBCTL/CICS connection is active and what the suffix is? I want to check this periodically and display a hook if it isn't active and if I can get the suffix from somewhere I could include that in the console message also. Thanks, Phil ************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. ========================================================================Date: Thu, 11 Oct 2001 12:27:01 -0700 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Sheffer, Holly" <[log in to unmask]> Subject: Re: DBCTL/CICS query MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit In group dfhdbctl there is transaction cdbc which will give you the info you want -----Original Message----- From: Jones, Phil [mailto:[log in to unmask]] Sent: Thursday, October 11, 2001 12:14 PM To: [log in to unmask] Subject: DBCTL/CICS query Hi, Does anyone know if there is a way from a program to query whether the DBCTL/CICS connection is active and what the suffix is? I want to check this periodically and display a hook if it isn't active and if I can get the suffix from somewhere I could include that in the console message also. Thanks, Phil ************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ========================================================================Date: Thu, 11 Oct 2001 21:58:44 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Roland Schiradin <[log in to unmask]> Subject: AW: LINK vs. CALL in Cics In-Reply-To: <8105C68DCFBDD111805500104B22762D09DD1EE7@NRHCRE00> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit John, You should pass the original EIB to a static called program or pass a dummy EIB (be aware the length of the EIB differ in different platforms) and issue a EXEC CICS ADDRESS EIB(address of EIB). Also I don't prefer the static call. Roland -----Ursprüngliche Nachricht----- Von: CICS List [mailto:[log in to unmask]]Im Auftrag von McKown, John Gesendet: Donnerstag, 11. Oktober 2001 19:30 An: [log in to unmask] Betreff: Re: LINK vs. CALL in Cics Bob, Isn't still true that statically linked (CALL literal) subroutines are not allowed to issue EXEC CICS commands? Or has that restriction been lifted? If it has, on what version of CICS? Using dynamic linkage (CALL identifier) allows the subroutine to issue EXEC CICS commands. ---------------------------------------------------------------------- John McKown HealthAxis All opinions are my own and are not the opinions of my employer. Unsolicited telephone calls from vendors are NOT appreciated and tend to upset my management. Where does bad light end up? In a prism! (Gary Lisica) > -----Original Message----- > From: Bob Halpern [SMTP:[log in to unmask]] > Sent: Thursday, October 11, 2001 12:24 PM > To: [log in to unmask] > Subject: Re: LINK vs. CALL in Cics > > Link is almost identical overhead as a new transaction - very > high. Call requires either external call (high overhead) or > direct binding - low overhead. Being performance oriented, I > alsways set up things for direct call. > > ========================================================================Date: Thu, 11 Oct 2001 15:46:25 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Jones, Phil" <[log in to unmask]> Subject: Re: DBCTL/CICS query MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" I know about CDBC/CDBI, but what I want to know if there is a way to get that info in a program that I set up to run, say every half-hour, and issue a wto if the connection is dropped. DBCTL dropped one Sunday and was brought back up but CICS doesn't reconnect automatically so the connection was down for many hours before it was reported. With DB2 we can issue an EXEC CICS INQ DB2CONN and get that information easily. With IMS they haven't made it so easy for some reason. Phil -----Original Message----- From: Sheffer, Holly [mailto:[log in to unmask]] Sent: Thursday, October 11, 2001 3:27 PM To: [log in to unmask] Subject: Re: DBCTL/CICS query In group dfhdbctl there is transaction cdbc which will give you the info you want -----Original Message----- From: Jones, Phil [mailto:[log in to unmask]] Sent: Thursday, October 11, 2001 12:14 PM To: [log in to unmask] Subject: DBCTL/CICS query Hi, Does anyone know if there is a way from a program to query whether the DBCTL/CICS connection is active and what the suffix is? I want to check this periodically and display a hook if it isn't active and if I can get the suffix from somewhere I could include that in the console message also. Thanks, Phil ************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. ========================================================================Date: Thu, 11 Oct 2001 22:08:51 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Roland Schiradin <[log in to unmask]> Subject: AW: LINK vs. CALL in Cics In-Reply-To: <[log in to unmask]> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Since LE the Exec CICS LINK is slower as under LE there is a new term called "enclave" and every CICS LINK/XCTL creates a new enclave. LE creates a new runtime environment (e.g CEEUOPT/CEEROPT and so on). A lot of APARs lower the overhead. We use the dynamic call (and the second call to the same sub-progr is dramaticly faster then a EXEC CICS LINK) if we didn't left the application. For sample: Payroll-Application always call dynamicly other Payroll-application modules but if the Payroll application need data or programs from the other application it use Exec CICS LINK. This allow use to have different LE enclaves and we can use DPL to move one application into another CICS region maybe on different LPAR. So inside the Payroll-application we use CALL and LINK to other applications. Remember in some case you have to do a EXEC CICS LINK if the called program might have a different EXECKEY. LE doesn't care about the EXECKEY and some other attributes. Roland -----Ursprüngliche Nachricht----- Von: CICS List [mailto:[log in to unmask]]Im Auftrag von Yeh, Jeff Gesendet: Donnerstag, 11. Oktober 2001 17:23 An: [log in to unmask] Betreff: LINK vs. CALL in Cics Hi All, In our team we are debating about the LINK vs. CALL in CICS environment. To my knowledge, the LINK is more "distributed" but a little bit performance disadvantage. CALL is better in performance, but is not "distributed." IBM also recommends to use CALL in LE. I am not so sure what that means. Can anyone give me some feedback? Thanks. Jeff ========================================================================Date: Thu, 11 Oct 2001 15:01:42 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: [log in to unmask] Subject: Re: DBCTL/CICS query Comments: To: [log in to unmask] MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_qLAYi4ah3RxRGYVZbOSIgg)" --Boundary_(ID_qLAYi4ah3RxRGYVZbOSIgg) Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT if you have CPSM, have it monitor the connections and it will give you a WTO message [log in to unmask] on 10/11/2001 02:46:25 PM To: [log in to unmask] @ PMDF cc: Subject: Re: DBCTL/CICS query I know about CDBC/CDBI, but what I want to know if there is a way to get that info in a program that I set up to run, say every half-hour, and issue a wto if the connection is dropped. DBCTL dropped one Sunday and was brought back up but CICS doesn't reconnect automatically so the connection was down for many hours before it was reported. With DB2 we can issue an EXEC CICS INQ DB2CONN and get that information easily. With IMS they haven't made it so easy for some reason. Phil -----Original Message----- From: Sheffer, Holly [mailto:[log in to unmask]] Sent: Thursday, October 11, 2001 3:27 PM To: [log in to unmask] Subject: Re: DBCTL/CICS query In group dfhdbctl there is transaction cdbc which will give you the info you want -----Original Message----- From: Jones, Phil [mailto:[log in to unmask]] Sent: Thursday, October 11, 2001 12:14 PM To: [log in to unmask] Subject: DBCTL/CICS query Hi, Does anyone know if there is a way from a program to query whether the DBCTL/CICS connection is active and what the suffix is? I want to check this periodically and display a hook if it isn't active and if I can get the suffix from somewhere I could include that in the console message also. Thanks, Phil ************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. --Boundary_(ID_qLAYi4ah3RxRGYVZbOSIgg)-- ========================================================================Date: Thu, 11 Oct 2001 16:00:11 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Ken Taylor <[log in to unmask]> Subject: Re: DBCTL/CICS query MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii There is a transaction in CICS called CDBI which has all of that info. If you want to write a program you might be able to find where CDBI gets its info from and duplicate it for your purposes. Ken Taylor IT Specialist Avon Products, Inc. Rye, NY [log in to unmask] "Jones, Phil" [log in to unmask] ALONE.COM> cc: Sent by: CICS List Subject: DBCTL/CICS query <[log in to unmask] .EDU> 10/11/01 03:14 PM Please respond to CICS List Hi, Does anyone know if there is a way from a program to query whether the DBCTL/CICS connection is active and what the suffix is? I want to check this periodically and display a hook if it isn't active and if I can get the suffix from somewhere I could include that in the console message also. Thanks, Phil ************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. ========================================================================Date: Thu, 11 Oct 2001 22:25:28 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Jean-Claude Duffau <[log in to unmask]> Subject: Re: DBCTL/CICS query MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Phil, I'm not sure for CICS/TS13 and DBCTL (what version??) but for CICS410, I used the code : MVC EXITW,=CL8'DFHDBAT' MVC ENTRYW,=CL8'DBCTL' EXEC CICS INQUIRE EXITPROGRAM(EXITW) ENTRYNAME(ENTRYW) * CONNECTST(RESP2) RESP(RESP) CLC RESP2,DFHVALUE(CONNECTED) Attachment OK? Hope this helps. Best regards. Jean-Claude Duffau SYStems LABoratory Services Paris France ----- Original Message ----- From: Jones, Phil <[log in to unmask]> To: <[log in to unmask]> Sent: Thursday, October 11, 2001 9:14 PM Subject: DBCTL/CICS query > Hi, > > Does anyone know if there is a way from a program to query whether the > DBCTL/CICS connection is active and what the suffix is? I want to check > this periodically and display a hook if it isn't active and if I can get the > suffix from somewhere I could include that in the console message also. > > Thanks, > > Phil > > ************************************************************************** > The information transmitted herewith is sensitive information intended only > for use by the individual or entity to which it is addressed. If the reader > of this message is not the intended recipient, you are hereby notified that > any review, retransmission, dissemination, distribution, copying or other > use of, or taking of any action in reliance upon this information is > strictly prohibited. If you have received this communication in error, > please contact the sender and delete the material from your computer. ========================================================================Date: Thu, 11 Oct 2001 15:53:36 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Laine, Rogers" <[log in to unmask]> Subject: CICS Transaction Reporting using SMP 110 records MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit My manager has requested a report showing average MIPS per cics transaction. The person trying to run the report off of these 110 records says that it is missing the sub type 0 & 1's. How do I turn on these sub type records and where? Your help is appreciated, Rogers =============================================================================Confidentiality Notice This E-Mail transmission (and/or the documents accompanying it) may contain information belonging to the sender which is confidential, privileged and/or exempt from disclosure under applicable law. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this E-Mail transmission in error, please immediately notify us by return E-Mail or telephone to arrange for return of its contents including any documents. ====================================================================================================================================================Date: Thu, 11 Oct 2001 14:09:41 -0700 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Bob Halpern <[log in to unmask]> Organization: CPU http://www.CPUperform.com Subject: Re: LINK vs. CALL in Cics MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just need to pass the address of the EIB. "McKown, John" wrote: > > Bob, > Isn't still true that statically linked (CALL literal) subroutines are not > allowed to issue EXEC CICS commands? Or has that restriction been lifted? If > it has, on what version of CICS? Using dynamic linkage (CALL identifier) > allows the subroutine to issue EXEC CICS commands. > > ---------------------------------------------------------------------- > John McKown > HealthAxis > > All opinions are my own and are not the opinions of my employer. > > Unsolicited telephone calls from vendors are NOT appreciated and tend to > upset my management. > > Where does bad light end up? In a prism! (Gary Lisica) > > > -----Original Message----- > > From: Bob Halpern [SMTP:[log in to unmask]] > > Sent: Thursday, October 11, 2001 12:24 PM > > To: [log in to unmask] > > Subject: Re: LINK vs. CALL in Cics > > > > Link is almost identical overhead as a new transaction - very > > high. Call requires either external call (high overhead) or > > direct binding - low overhead. Being performance oriented, I > > alsways set up things for direct call. > > > > ========================================================================Date: Thu, 11 Oct 2001 14:15:02 -0700 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Bob Halpern <[log in to unmask]> Organization: CPU http://www.CPUperform.com Subject: Re: CICS Transaction Reporting using SMP 110 records MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit First, you need to set up monitoring to capture CPU time. This adds a lot of overhead to CICS as it needs to invoke the MVS dispatcher to update the TCB time. (CALLDISP with branch entry) Alternatively, you could take the entire CICS region but that would be a very crude approximation. I would be more interested in service units, not mips. Service units is scalable across different boxes and LPAR definitions. "Laine, Rogers" wrote: > > My manager has requested a report showing average MIPS per cics transaction. > > The person trying to run the report off of these 110 records says that it is > missing the sub type 0 & 1's. > > How do I turn on these sub type records and where? > > Your help is appreciated, > Rogers > > ==============================================================================Confidentiality Notice > > This E-Mail transmission (and/or the documents accompanying it) may contain information belonging to the sender which is confidential, privileged and/or exempt from disclosure under applicable law. The information is intended only for the use of the individual(s) or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this E-Mail transmission in error, please immediately notify us by return E-Mail or telephone to arrange for return of its contents including any documents. > > =====================================================================================================================================================Date: Thu, 11 Oct 2001 17:49:58 EDT Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Dave Myers <[log in to unmask]> Subject: CICS V4.1 >> CICS TS 1.3 Newbie MRO Questions MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_34.1c2fa081.28f76e06_boundary" --part1_34.1c2fa081.28f76e06_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Currently we run two CICS 4.1 regions One region runs our GL (datacom) app and the other runs all other apps. We use MRO to communicate between the two. We're going to CICS TS 1.3 and I was wondering the following: 1. Why not get rid of MRO and combine these apps into one region?? Is there a technical reason to separate apps these days?? 2. Are there any tricks to moving those apps under one CICS region and eliminating MRO...or is it just a matter of moving the resources over?? We run a 9672-R35 (55mip engine) and I'm pretty sure that we won't have a CPU bottleneck. Both regions do about 1/2 million trans per week. Both regions currently average sub-second response times. 3. If I can not combine apps, can the TS 1.3 region and the CICS V4 regions use MRO to communicate during the transition from V4 to TS 1.3 ?? --part1_34.1c2fa081.28f76e06_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Currently we run two CICS 4.1 regions
One region runs our GL (datacom) app and the other runs all other apps.
We use MRO to communicate between the two.


We're going to CICS TS 1.3 and  I was wondering the following:

1. Why not get rid of MRO and combine these apps into
   one region??  Is there a technical reason to separate apps these days??

2.  Are there any tricks to moving those apps under one CICS region
   and eliminating MRO...or is it just a matter of moving the resources
   over??

   We run a 9672-R35  (55mip engine)
   and I'm pretty sure that we won't have a CPU bottleneck.

   Both regions do about 1/2 million trans per week.
   Both regions currently average sub-second response times.

3.  If I can not combine apps,  can the TS 1.3 region and the CICS V4
    regions use MRO to communicate during the transition from
    V4 to TS 1.3 ??

--part1_34.1c2fa081.28f76e06_boundary-- ========================================================================Date: Thu, 11 Oct 2001 17:10:02 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Matthew Stitt <[log in to unmask]> Organization: Huntsville Hospital Subject: Re: CICS V4.1 >> CICS TS 1.3 Newbie MRO Questions MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7EDFF977A2E8A53AE78911BC" --------------7EDFF977A2E8A53AE78911BC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 1. It's up to you. The separate region may have started as a stability issue, political issue, etc. 2. Half a million a week is peanuts to most people. I've run regions with 4 million a day on 9672-R?5 cpu and subsecond response time. 3. Yes. There may be some level dependencies on various functions, but I don't think you would be worried over that. Dave Myers wrote: > Currently we run two CICS 4.1 regions > One region runs our GL (datacom) app and the other runs all other > apps. > We use MRO to communicate between the two. > > > We're going to CICS TS 1.3 and I was wondering the following: > > 1. Why not get rid of MRO and combine these apps into > one region?? Is there a technical reason to separate apps these > days?? > > 2. Are there any tricks to moving those apps under one CICS region > and eliminating MRO...or is it just a matter of moving the > resources > over?? > > We run a 9672-R35 (55mip engine) > and I'm pretty sure that we won't have a CPU bottleneck. > > Both regions do about 1/2 million trans per week. > Both regions currently average sub-second response times. > > 3. If I can not combine apps, can the TS 1.3 region and the CICS V4 > regions use MRO to communicate during the transition from > V4 to TS 1.3 ?? > --------------7EDFF977A2E8A53AE78911BC Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 1. It's up to you.  The separate region may have started as a stability issue, political issue, etc.

2.  Half a million a week is peanuts to most people.  I've run regions with 4 million a day on 9672-R?5 cpu and subsecond response time.

3.  Yes.  There may be some level dependencies on various functions, but I don't think you would be worried over that.

Dave Myers wrote:

Currently we run two CICS 4.1 regions
One region runs our GL (datacom) app and the other runs all other apps.
We use MRO to communicate between the two.
 

We're going to CICS TS 1.3 and  I was wondering the following:

1. Why not get rid of MRO and combine these apps into
   one region??  Is there a technical reason to separate apps these days??

2.  Are there any tricks to moving those apps under one CICS region
   and eliminating MRO...or is it just a matter of moving the resources
   over??

   We run a 9672-R35  (55mip engine)
   and I'm pretty sure that we won't have a CPU bottleneck.

   Both regions do about 1/2 million trans per week.
   Both regions currently average sub-second response times.

3.  If I can not combine apps,  can the TS 1.3 region and the CICS V4
    regions use MRO to communicate during the transition from
    V4 to TS 1.3 ??
 

--------------7EDFF977A2E8A53AE78911BC-- ========================================================================Date: Fri, 12 Oct 2001 00:33:08 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Roland Schiradin <[log in to unmask]> Subject: AW: CICS V4.1 >> CICS TS 1.3 Newbie MRO Questions In-Reply-To: <[log in to unmask]> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C152B5.7747B1B0" This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C152B5.7747B1B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dave, the technical reason to run seprate CICS regions is that CICS itself use almost one TCB for the main work. This will limit the use of a multiple CPUs. If you have 4 CPU's you should run 4 CICS regions and workload the stuff between those 4 regions. Please note the storage overhard as some application programs reside 4 time in case of 4 CICS regions Roland -----Ursprungliche Nachricht----- Von: CICS List [mailto:[log in to unmask]]Im Auftrag von Dave Myers Gesendet: Donnerstag, 11. Oktober 2001 23:50 An: [log in to unmask] Betreff: CICS V4.1 >> CICS TS 1.3 Newbie MRO Questions Currently we run two CICS 4.1 regions One region runs our GL (datacom) app and the other runs all other apps. We use MRO to communicate between the two. We're going to CICS TS 1.3 and I was wondering the following: 1. Why not get rid of MRO and combine these apps into one region?? Is there a technical reason to separate apps these days?? 2. Are there any tricks to moving those apps under one CICS region and eliminating MRO...or is it just a matter of moving the resources over?? We run a 9672-R35 (55mip engine) and I'm pretty sure that we won't have a CPU bottleneck. Both regions do about 1/2 million trans per week. Both regions currently average sub-second response times. 3. If I can not combine apps, can the TS 1.3 region and the CICS V4 regions use MRO to communicate during the transition from V4 to TS 1.3 ?? ------=_NextPart_000_000C_01C152B5.7747B1B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dave,
 
the technical reason to run seprate CICS regions is that CICS itself use
almost one TCB for the main work. This will limit the use of a multiple
CPUs. If you have 4 CPU's you should run 4 CICS regions and workload
the stuff between those 4 regions.
 
Please note the storage overhard as some application programs reside 4
time in case of 4 CICS  regions
 
 
Roland
 
-----Ursprüngliche Nachricht-----
Von: CICS List [mailto:[log in to unmask]]Im Auftrag von Dave Myers
Gesendet: Donnerstag, 11. Oktober 2001 23:50
An: [log in to unmask]
Betreff: CICS V4.1 >> CICS TS 1.3 Newbie MRO Questions

Currently we run two CICS 4.1 regions
One region runs our GL (datacom) app and the other runs all other apps.
We use MRO to communicate between the two.


We're going to CICS TS 1.3 and  I was wondering the following:

1. Why not get rid of MRO and combine these apps into
   one region??  Is there a technical reason to separate apps these days??

2.  Are there any tricks to moving those apps under one CICS region
   and eliminating MRO...or is it just a matter of moving the resources
   over??

   We run a 9672-R35  (55mip engine)
   and I'm pretty sure that we won't have a CPU bottleneck.

   Both regions do about 1/2 million trans per week.
   Both regions currently average sub-second response times.

3.  If I can not combine apps,  can the TS 1.3 region and the CICS V4
    regions use MRO to communicate during the transition from
    V4 to TS 1.3 ??

------=_NextPart_000_000C_01C152B5.7747B1B0-- ========================================================================Date: Thu, 11 Oct 2001 16:18:36 -0700 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: [log in to unmask] Subject: DFHXMAB Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi All, Thank you for being always there for me in time of trouble. I need your help again...PLEASE. The non-browser transaction TST4 works fine. The following 3 browser urls using the CWI/CWS work fine HTTP://i.p.a.ddr:3003/CICS/CWBA/dfh$wb1a The following 2 browser urls using 3270 bridge HTTP://i.p.a.ddr:3003/CICS/CWBA/dfhwbtta/tst4 http://i.p.a.ddr:3004/attrbcnv/CWBA/dfhwbtta/tst1?ajjerbnc (CICS Web Interface signon screen) result in browser message Internal error Also, the transaction TST1/TST4 triggered from the browser creates the messages in DFHMSG: DFHAC2236 10/11/01 14:57:02 A11CICS5 Transaction TST1 abend LATC in program DFHXMAB term ????. Updates to local recoverable resources will be backed out. DFHWB0137 10/11/01 15:07:03 A11CICS5 CWBA An error code X'420B' occurred in DFHWBTTA while accessing the Web state data for this transaction. TCPIPSERVICE: HTTPNSSL 420B A call to wait for the CICS Web Interface alias transaction associated with this instance of DFHWBTTA failed. There is no RDO definition for DFHXMAB TIA - Gloria ========================================================================Date: Fri, 12 Oct 2001 12:07:12 +1000 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Chalker, Craig" <[log in to unmask]> Subject: CICS TS 1.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C152C2.9B494D50" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C152C2.9B494D50 Content-Type: text/plain; charset="ISO-8859-1" Hi Folks, I have a customer who is running CICS TS 1.2, they only run a couple of apps that are very stable, not interested in having Web based access to those apps and can't see the need to move to TS 1.3 in the near future. I was wondering if anyone here knows when TS 1.2 loses support. I can't find much on IBMLink and thought I'd ask the question here before calling IBM. Any other compelling reasons to move ? Thanks. Regards, Craig. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager of QR. This message has been swept by MIMESweeper for the presence of computer viruses. No warranty is given that this message upon its receipt is virus free and no liability is accepted by the sender in this respect. This email is a message only; does not constitute advice and should not be relied upon as such. ********************************************************************** ------_=_NextPart_001_01C152C2.9B494D50 Content-Type: text/html; charset="ISO-8859-1"
Hi Folks,
             I have a customer who is running CICS TS 1.2, they only run a couple of apps that are very stable, not interested in having Web based access to those apps and can't see the need to move to TS 1.3 in the near future. I was wondering if anyone here knows when TS 1.2 loses support. I can't find much on IBMLink and thought I'd ask the question here before calling IBM. Any other compelling reasons to move ? Thanks.
Regards,
Craig.


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager of QR.

This message has been swept by MIMESweeper for the presence of computer
viruses. No warranty is given that this message upon its receipt is
virus free and no liability is accepted by the sender in this respect.

This email is a message only; does not constitute advice and should not
be relied upon as such.
**********************************************************************
------_=_NextPart_001_01C152C2.9B494D50-- ========================================================================Date: Fri, 12 Oct 2001 08:35:25 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "McBurnie, Carl" <[log in to unmask]> Subject: AW: DBCTL/CICS query MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi Phil, you're obviously looking at some way of automating the CICS/DBCTL connection, but you didn't indicate if you have any automation product. You could use MODIFY commands and WTOs to solve the problem:- Regularly issue "MODIFY cicsname,CDBI" and trap the resulting WTOs e.g. +DFHDB8293I DBCTL connected and ready. +DFHDB8225I xxxxxxxx The DBCTL ID is xxxx. The DRA Startup Table suffix is xx. if the connection is available or +DFHDB8290I DBCTL not connected to CICS. if it isn't. If the connection isn't available you can issue "MODIFY cicsname,CDBC CONNECT" to re-establish the connection. You don't need to specify the DRA suffix in the CDBC CONNECT if you have specified it in DFHDBCON='xx' in the SIT INITPARM as an override for example. This is an alternative to writing a program, hope it helps. Regards, Carl --------------------------- Carl Wade McBurnie MBCS I.T. Consultant E-Mail: [log in to unmask] -----Ursprüngliche Nachricht----- Von: Jones, Phil [mailto:[log in to unmask]] Gesendet: Donnerstag, 11. Oktober 2001 21:46 An: [log in to unmask] Betreff: Re: DBCTL/CICS query I know about CDBC/CDBI, but what I want to know if there is a way to get that info in a program that I set up to run, say every half-hour, and issue a wto if the connection is dropped. DBCTL dropped one Sunday and was brought back up but CICS doesn't reconnect automatically so the connection was down for many hours before it was reported. With DB2 we can issue an EXEC CICS INQ DB2CONN and get that information easily. With IMS they haven't made it so easy for some reason. Phil -----Original Message----- From: Sheffer, Holly [mailto:[log in to unmask]] Sent: Thursday, October 11, 2001 3:27 PM To: [log in to unmask] Subject: Re: DBCTL/CICS query In group dfhdbctl there is transaction cdbc which will give you the info you want -----Original Message----- From: Jones, Phil [mailto:[log in to unmask]] Sent: Thursday, October 11, 2001 12:14 PM To: [log in to unmask] Subject: DBCTL/CICS query Hi, Does anyone know if there is a way from a program to query whether the DBCTL/CICS connection is active and what the suffix is? I want to check this periodically and display a hook if it isn't active and if I can get the suffix from somewhere I could include that in the console message also. Thanks, Phil ************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. ========================================================================Date: Fri, 12 Oct 2001 12:17:48 +0530 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Ramesh Aripak <[log in to unmask]> Subject: BMS map load module RESIDENT/NONRESIDENT. MIME-Version: 1.0 Content-Type: text/plain Hi List, How can we make a BMS map load module RESIDENT/NONRESIDENT ? Any kind of inputs is appreciated. Thanks in advance. Ramesha. ========================================================================Date: Fri, 12 Oct 2001 08:38:59 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Lisbeth Smed <[log in to unmask]> Subject: SV: BMS map load module RESIDENT/NONRESIDENT. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Ramesha, When you define the map you have the option RESIDENT No/Yes. Regards Lisbeth -----Oprindelig meddelelse----- Fra: Ramesh Aripak [mailto:[log in to unmask]] Sendt: 12. oktober 2001 08:48 Til: [log in to unmask] Emne: BMS map load module RESIDENT/NONRESIDENT. Hi List, How can we make a BMS map load module RESIDENT/NONRESIDENT ? Any kind of inputs is appreciated. Thanks in advance. Ramesha. ========================================================================Date: Fri, 12 Oct 2001 08:42:23 +0200 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "McBurnie, Carl" <[log in to unmask]> Subject: AW: BMS map load module RESIDENT/NONRESIDENT. MIME-Version: 1.0 Content-Type: text/plain Hi Ramesha, by specifying RESIDENT(YES) or RESIDENT(NO) in the MAPSET definition in the CSD. Regards, Carl ---------------------------------- Carl Wade McBurnie MBCS I.T. Consultant E-Mail: [log in to unmask] -----Ursprungliche Nachricht----- Von: Ramesh Aripak [mailto:[log in to unmask]] Gesendet: Freitag, 12. Oktober 2001 08:48 An: [log in to unmask] Betreff: BMS map load module RESIDENT/NONRESIDENT. Hi List, How can we make a BMS map load module RESIDENT/NONRESIDENT ? Any kind of inputs is appreciated. Thanks in advance. Ramesha. ========================================================================Date: Fri, 12 Oct 2001 12:36:48 +0300 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Adem Arslan (Garanti Teknoloji)" <[log in to unmask]> Subject: RUWAPOOL=YES to maximize performance with LE on CICS ? Hi All, in our team we are debating about the RUWAPOOL=YES vs NO in the SIT option.To my knowledge, to have more performance we have to set SIT option RUWAPOOL=YES and LE option ALL31(ON). Can anyone give me some feedback and experiment about this parameters. Is there any site that use this options ? Thanks in advance, ----------------------------------- Adem ARSLAN Garanti Technology [log in to unmask] TEL: +90.212.4783213 ----------------------------------- ========================================================================Date: Fri, 12 Oct 2001 10:47:46 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Derek Scrivens <[log in to unmask]> Subject: Re: LINK vs. CALL in Cics MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Have a look at the LE and CICS discussion document by Andy Krasun at UK Guide minutes Jan 2001 there is some useful info in there re CALL vs LINK performance and future directions. Our applications people did some comparative tests and found that CALL was about 60x quicker than LINK, but I haven't seen the actual programs they used for the test. Regards, Derek. "Yeh, Jeff" [log in to unmask] LCITY.COM> cc: Sent by: "CICS Fax to: List" Subject: LINK vs. CALL in Cics <[log in to unmask] UGA.EDU> 11/10/01 16:22 Please respond to "CICS List" Hi All, In our team we are debating about the LINK vs. CALL in CICS environment. To my knowledge, the LINK is more "distributed" but a little bit performance disadvantage. CALL is better in performance, but is not "distributed." IBM also recommends to use CALL in LE. I am not so sure what that means. Can anyone give me some feedback? Thanks. Jeff ========================================================================Date: Fri, 12 Oct 2001 11:17:29 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Derek Scrivens <[log in to unmask]> Subject: Re: LINK vs. CALL in Cics MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry, it looks as if the link may not work properly. It should be: http://www.harpers.demon.co.uk/gsecics/Jan01/Entering%20the%20LE%20Zone.pdf Derek. "Derek Scrivens" [log in to unmask] TPOST.COM> cc: Sent by: "CICS Fax to: List" Subject: Re: LINK vs. CALL in Cics <[log in to unmask] GA.EDU> 12/10/01 10:47 Please respond to "CICS List" Have a look at the LE and CICS discussion document by Andy Krasun at UK Guide minutes Jan 2001 there is some useful info in there re CALL vs LINK performance and future directions. Our applications people did some comparative tests and found that CALL was about 60x quicker than LINK, but I haven't seen the actual programs they used for the test. Regards, Derek. "Yeh, Jeff" [log in to unmask] LCITY.COM> cc: Sent by: "CICS Fax to: List" Subject: LINK vs. CALL in Cics <[log in to unmask] UGA.EDU> 11/10/01 16:22 Please respond to "CICS List" Hi All, In our team we are debating about the LINK vs. CALL in CICS environment. To my knowledge, the LINK is more "distributed" but a little bit performance disadvantage. CALL is better in performance, but is not "distributed." IBM also recommends to use CALL in LE. I am not so sure what that means. Can anyone give me some feedback? Thanks. Jeff ========================================================================Date: Fri, 12 Oct 2001 11:14:39 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Andy Krasun <[log in to unmask]> Subject: Re: CICS TS 1.2 and other end of currencies MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii End of currencies in USA CICS 4.1 31/12/2002 CICS TS 1.1 31/12/2001 CICS TS 1.2 31/12/2002 CICS TS 2.1 30/6/2002 CICSPlex SM 1.3 31/12/2002 andyK IBM Corp. |--------+-------------------------> | | "Chalker, | | | Craig" | | | | | | | | | 12/10/2001 | | | 03:07 | | | Please respond | | | to CICS List | | | | |--------+-------------------------> >-----------------------------------------------------------------------------------------------------------------------| | | | To: [log in to unmask] | | cc: | | Subject: CICS TS 1.2 | | | | | >-----------------------------------------------------------------------------------------------------------------------| Hi Folks, I have a customer who is running CICS TS 1.2, they only run a couple of apps that are very stable, not interested in having Web based access to those apps and can't see the need to move to TS 1.3 in the near future. I was wondering if anyone here knows when TS 1.2 loses support. I can't find much on IBMLink and thought I'd ask the question here before calling IBM. Any other compelling reasons to move ? Thanks. Regards, Craig. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager of QR. This message has been swept by MIMESweeper for the presence of computer viruses. No warranty is given that this message upon its receipt is virus free and no liability is accepted by the sender in this respect. This email is a message only; does not constitute advice and should not be relied upon as such. ********************************************************************** #### att1.htm has been removed from this note on October 12 2001 by Andy Krasun ========================================================================Date: Fri, 12 Oct 2001 14:37:24 +0300 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Funda Karagoz <[log in to unmask]> Subject: Re: Forwarded Security Question MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: 8bit Hi Chris, I was working on EPI and the question that you forwarded to the list is my current problem. Since 2 years have passed after you forwarded this question, I wonder if your friend found a solution. Would you please help me? Thanks in advance. Regards, Funda Karagöz Central Bank of Turkey Data Processing Department Tel: +90 312 311 97 69 Fax: +90 312 311 58 85 -----Original Message----- From: Chris McFadden [mailto:[log in to unmask]] Sent: Tuesday, September 14, 1999 3:07 PM To: [log in to unmask] Subject: Forwarded Security Question > >We are interested in hearing about *ANY* solution for accessing >RACF secured transactions in CICS/ESA via the CICS Client using >the EPI (*NOT* ECI!). We have a good solution in place now but >are unable to secure it properly since: > >1) The EPI API has no mechanism for providing userid/password. >2) EXEC CICS SIGNON from within the transaction program is > not allowed since the terminal that is auto-installed is > a remote. > >As long as the transactions are not secured things work fine. > >We would consider using ECI but the 32K limit on the amount >of data we need to return (for a *single* task) is too low. >However, if someone has engineered an ECI solution to get >around this limit we would be happy hear about it! > >Of course the ECI API *has* a mechanism for providing a >userid/password. > >TIA! > >Hank > > =========================================================Bu e-posta sadece yukarida isimleri belirtilen kisiler arasinda ozel haberlesme amacini tasimaktadir. Size yanlislikla ulasmissa lutfen mesaji geri gonderiniz ve sisteminizden siliniz. Turkiye Cumhuriyet Merkez Bankasi A.S. bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. This e-mail communication is intended for the private use of the persons named above. If you received this message in error, please immediately notify the sender and delete it from your system. The Central Bank of The Republic of Turkey does not accept legal responsibility for the contents of this message. ========================================================================Date: Fri, 12 Oct 2001 12:55:41 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: [log in to unmask] Subject: Re: Omegamon TASK HISTORY COLLECTION MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT" Benjamin White asked: >To the group: How does Omegamon Task History overhead compare to >Landmark's "The Monitor" TMON? for the same function of transaction detail >recording? Ben, Any History Recording involves significant overhead. I assume that you are a TMON user and that you wish to collect TA and TI type data. I'm now working with OMEGAMON now but formerly I used TMON and wanted to achieve recording but without certain trace data being involved. TMON turns on certain trace components (e.g EI) to give you greater details but one may not be bothered about this, if you are data collecting in the TAAREQ segment and you can't easily turn this off. To get around this overhead, code a small PLT pgm to turn this component off, as follows. EXEC CICS SET TRACETYPE STANDARD EI(X'00000000') This PLT pgm need to run after any TMON PLT elements. The reduction in overhead is quite significant. But I haven't got my original figures to hand to give you any figures. Turn your data collection on and try it, with the PLT pgm and then without it. NB: This was tested in TMON/CICS V1 and then V2 quite a long time ago. So most of this is from memory. Regards, Leo ========================================================================Date: Fri, 12 Oct 2001 07:10:14 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Chase, John" <[log in to unmask]> Subject: Re: CICS V4.1 >> CICS TS 1.3 Newbie MRO Questions MIME-Version: 1.0 Content-Type: text/plain On Thursday, October 11, 2001 4:50 PM, Dave Myers wrote: > Currently we run two CICS 4.1 regions > One region runs our GL (datacom) app and the other runs all other apps. > We use MRO to communicate between the two. > > > We're going to CICS TS 1.3 and I was wondering the following: > > 1. Why not get rid of MRO and combine these apps into > one region?? Is there a technical reason to separate apps these > days?? Generally, no. > 2. Are there any tricks to moving those apps under one CICS region > and eliminating MRO...or is it just a matter of moving the resources > over?? You should ensure that all applications involved can run with the same language support, e.g., LE. > We run a 9672-R35 (55mip engine) > and I'm pretty sure that we won't have a CPU bottleneck. > > Both regions do about 1/2 million trans per week. > Both regions currently average sub-second response times. > > 3. If I can not combine apps, can the TS 1.3 region and the CICS V4 > regions use MRO to communicate during the transition from > V4 to TS 1.3 ?? Yes. You will have to use the TS13 levels of the CICS SVC and the DFHIRP and related modules. -jc- ========================================================================Date: Fri, 12 Oct 2001 13:22:15 +0100 Reply-To: [log in to unmask] Sender: CICS List <[log in to unmask]> From: Owen Williams <[log in to unmask]> Subject: Re: CICS V4.1 >> CICS TS 1.3 Newbie MRO Questions In-Reply-To: <[log in to unmask]> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C15320.E8F51800" This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C15320.E8F51800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Dave, You mention that one of your regions is running against CA-Datacom for your GL application. Is your other CICS region also communicating with a different CA-Datacom Multi-User Facility? If so, then you will need to merge those two CA-Datacom MUFs before merging the CICS regions. A single Datacom MUF can talk to multiple CICS regions, but each CICS region can only communicate with one MUF. Best regards, Owen Williams Allied Data Resources Ltd. mailto:[log in to unmask] Web http://www.adr.vfree.com/cv.htm Tel: +44 (0)7961 103632 Fax: +44 (0)20 8930 0339 -----Original Message----- From: CICS List [mailto:[log in to unmask]]On Behalf Of Dave Myers Sent: Thursday, October 11, 2001 22:50 To: [log in to unmask] Subject: CICS V4.1 >> CICS TS 1.3 Newbie MRO Questions Currently we run two CICS 4.1 regions One region runs our GL (datacom) app and the other runs all other apps. We use MRO to communicate between the two. We're going to CICS TS 1.3 and I was wondering the following: 1. Why not get rid of MRO and combine these apps into one region?? Is there a technical reason to separate apps these days?? 2. Are there any tricks to moving those apps under one CICS region and eliminating MRO...or is it just a matter of moving the resources over?? We run a 9672-R35 (55mip engine) and I'm pretty sure that we won't have a CPU bottleneck. Both regions do about 1/2 million trans per week. Both regions currently average sub-second response times. 3. If I can not combine apps, can the TS 1.3 region and the CICS V4 regions use MRO to communicate during the transition from V4 to TS 1.3 ?? ------=_NextPart_000_0004_01C15320.E8F51800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave,

You mention that one of your regions is running against CA-Datacom for your GL application. Is your other CICS region also communicating with a different CA-Datacom Multi-User Facility? If so, then you will need to merge those two CA-Datacom MUFs before merging the CICS regions.

A single Datacom MUF can talk to multiple CICS regions, but each CICS region can only communicate with one MUF.

Best regards,
Owen Williams
Allied Data Resources Ltd.
mailto:[log in to unmask]     Web http://www.adr.vfree.com/cv.htm
Tel: +44 (0)7961 103632   Fax: +44 (0)20 8930 0339

-----Original Message-----
From: CICS List [mailto:[log in to unmask]]On Behalf Of Dave Myers
Sent: Thursday, October 11, 2001 22:50
To: [log in to unmask]
Subject: CICS V4.1 >> CICS TS 1.3 Newbie MRO Questions

Currently we run two CICS 4.1 regions
One region runs our GL (datacom) app and the other runs all other apps.
We use MRO to communicate between the two.


We're going to CICS TS 1.3 and  I was wondering the following:

1. Why not get rid of MRO and combine these apps into
   one region??  Is there a technical reason to separate apps these days??

2.  Are there any tricks to moving those apps under one CICS region
   and eliminating MRO...or is it just a matter of moving the resources
   over??

   We run a 9672-R35  (55mip engine)
   and I'm pretty sure that we won't have a CPU bottleneck.

   Both regions do about 1/2 million trans per week.
   Both regions currently average sub-second response times.

3.  If I can not combine apps,  can the TS 1.3 region and the CICS V4
    regions use MRO to communicate during the transition from
    V4 to TS 1.3 ??

------=_NextPart_000_0004_01C15320.E8F51800-- ========================================================================Date: Fri, 12 Oct 2001 07:23:12 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Chase, John" <[log in to unmask]> Subject: Re: BMS map load module RESIDENT/NONRESIDENT. MIME-Version: 1.0 Content-Type: text/plain On Friday, October 12, 2001 1:48 AM, Ramesh Aripak wrote: > Hi List, > How can we make a BMS map load module RESIDENT/NONRESIDENT ? > > Any kind of inputs is appreciated. In CICS Resource Definition Online, the doc for the MAPSET definition says to specify RESIDENT = YES or NO. You may also specify to use a copy of the MAPSET from the LPA. -jc- ========================================================================Date: Fri, 12 Oct 2001 08:40:03 -0600 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Rakesh Kaushika <[log in to unmask]> Subject: Document Api in CICS ts1.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Listers! I am using Document insert command to insert a selection list in a document.The output goes fine and I see the dropdown list on the browser with the document. The problem is when I try to read this selection field in my program by using WEB READ FORMFIELD I get EIBRESP 13 which is Form field not found. looking at the source on the browser I find that this selection list was added at the end after the and I think that is why I am getting Form field not found. what should i be doing so that the selection list gets inserted before the and not at the end after . any suggestions or ideas would be greatly appreciated. Thanks Rakesh ========================================================================Date: Fri, 12 Oct 2001 08:56:35 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Elliott, Brian" <[log in to unmask]> Subject: Re: Document Api in CICS ts1.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Use the AT and TO options of the EXEC CICS DOCUMENT INSERT command. You must create "bookmarks" first. See the App. Prog. Ref. manual for assistance... Brian Elliott TSG-CICS/MQ Series West Affiliated Computer Services Phone: 615-221-0801 E-Mail: [log in to unmask] or [log in to unmask] -----Original Message----- From: Rakesh Kaushika [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 9:40 AM To: [log in to unmask] Subject: Document Api in CICS ts1.3 Hi Listers! I am using Document insert command to insert a selection list in a document.The output goes fine and I see the dropdown list on the browser with the document. The problem is when I try to read this selection field in my program by using WEB READ FORMFIELD I get EIBRESP 13 which is Form field not found. looking at the source on the browser I find that this selection list was added at the end after the and I think that is why I am getting Form field not found. what should i be doing so that the selection list gets inserted before the and not at the end after . any suggestions or ideas would be greatly appreciated. Thanks Rakesh ========================================================================Date: Fri, 12 Oct 2001 10:26:15 -0400 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Donald H. Blake" <[log in to unmask]> Subject: Translation problem Comments: To: [log in to unmask] MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii I have installed Websphere V4 and the WAS associated with it. I brought up CTG V4, and installed it into WAS as a plugin. I installed a JAVA servelette which uses CTG (ECI) to talk to CICS. I set up DFHCNV to translate the COMMAREA to/from ASCII. I can see that the data is being translated appropriately into the CICS program, and that works properly. I see the data being translated back to ASCII in a CICS trace. I believe that is working OK too, BUT ... the data is being translated AGAIN, and garbled. I don't think this is happening in CICS. I figured out, if I write a little chunk of code for DFHUCNV ... translate the COMMAREA from EBCDIC to ASCII on input to the CICS program, and leave the data in ASCII on the way out, everything works well! The servelette actually works! Not a good solution though, as we enter these programs from other ECI callers, which require translation both ways. I believe that that MIME entries in Websphere might be set up incorrectly, but am not sure. Anybody have any ideas? It definitely might be something else, but it appears to be happening in AS, rather than CICS. ========================================================================Date: Fri, 12 Oct 2001 09:28:54 -0600 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Rakesh Kaushika <[log in to unmask]> Subject: Re: Document Api in CICS ts1.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Brian! I am using a Template for creating my first document and then using document insert for adding the selection list. do I still need to create bookmarks?I was assuming that the selection list would be appended at the end of the first document but within the Form Tags so that I can read subsequently. Thanks Regards Rakesh -----Original Message----- From: Elliott, Brian [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 7:57 AM To: [log in to unmask] Subject: Re: Document Api in CICS ts1.3 Use the AT and TO options of the EXEC CICS DOCUMENT INSERT command. You must create "bookmarks" first. See the App. Prog. Ref. manual for assistance... Brian Elliott TSG-CICS/MQ Series West Affiliated Computer Services Phone: 615-221-0801 E-Mail: [log in to unmask] or [log in to unmask] -----Original Message----- From: Rakesh Kaushika [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 9:40 AM To: [log in to unmask] Subject: Document Api in CICS ts1.3 Hi Listers! I am using Document insert command to insert a selection list in a document.The output goes fine and I see the dropdown list on the browser with the document. The problem is when I try to read this selection field in my program by using WEB READ FORMFIELD I get EIBRESP 13 which is Form field not found. looking at the source on the browser I find that this selection list was added at the end after the and I think that is why I am getting Form field not found. what should i be doing so that the selection list gets inserted before the and not at the end after . any suggestions or ideas would be greatly appreciated. Thanks Rakesh ========================================================================Date: Fri, 12 Oct 2001 09:35:26 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Elliott, Brian" <[log in to unmask]> Subject: Re: Document Api in CICS ts1.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit It looks like that's not the case... It appears that you've proven to yourself (and me) that CWS is appending it after all of the HTML in the template (including the and tags)... I would always advise using bookmarks... I think that is the safest way to go, because you are always certain where the HTML is being inserted... Brian Elliott TSG-CICS/MQ Series West Affiliated Computer Services Phone: 615-221-0801 E-Mail: [log in to unmask] or [log in to unmask] -----Original Message----- From: Rakesh Kaushika [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 10:29 AM To: [log in to unmask] Subject: Re: Document Api in CICS ts1.3 Brian! I am using a Template for creating my first document and then using document insert for adding the selection list. do I still need to create bookmarks?I was assuming that the selection list would be appended at the end of the first document but within the Form Tags so that I can read subsequently. Thanks Regards Rakesh -----Original Message----- From: Elliott, Brian [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 7:57 AM To: [log in to unmask] Subject: Re: Document Api in CICS ts1.3 Use the AT and TO options of the EXEC CICS DOCUMENT INSERT command. You must create "bookmarks" first. See the App. Prog. Ref. manual for assistance... Brian Elliott TSG-CICS/MQ Series West Affiliated Computer Services Phone: 615-221-0801 E-Mail: [log in to unmask] or [log in to unmask] -----Original Message----- From: Rakesh Kaushika [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 9:40 AM To: [log in to unmask] Subject: Document Api in CICS ts1.3 Hi Listers! I am using Document insert command to insert a selection list in a document.The output goes fine and I see the dropdown list on the browser with the document. The problem is when I try to read this selection field in my program by using WEB READ FORMFIELD I get EIBRESP 13 which is Form field not found. looking at the source on the browser I find that this selection list was added at the end after the and I think that is why I am getting Form field not found. what should i be doing so that the selection list gets inserted before the and not at the end after . any suggestions or ideas would be greatly appreciated. Thanks Rakesh ========================================================================Date: Fri, 12 Oct 2001 09:44:03 -0600 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Rakesh Kaushika <[log in to unmask]> Subject: Re: Document Api in CICS ts1.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Brian! Since I am using a fixed template for my first document where and how do I create the bookmark.If I do it after the create document (from template) and then insert the selection list using AT (bookmark)it still puts the selection list after the .I guess I am missing something. Thanks for all yr help.I appreciate it. Regards Rakesh -----Original Message----- From: Elliott, Brian [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 8:35 AM To: [log in to unmask] Subject: Re: Document Api in CICS ts1.3 It looks like that's not the case... It appears that you've proven to yourself (and me) that CWS is appending it after all of the HTML in the template (including the and tags)... I would always advise using bookmarks... I think that is the safest way to go, because you are always certain where the HTML is being inserted... Brian Elliott TSG-CICS/MQ Series West Affiliated Computer Services Phone: 615-221-0801 E-Mail: [log in to unmask] or [log in to unmask] -----Original Message----- From: Rakesh Kaushika [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 10:29 AM To: [log in to unmask] Subject: Re: Document Api in CICS ts1.3 Brian! I am using a Template for creating my first document and then using document insert for adding the selection list. do I still need to create bookmarks?I was assuming that the selection list would be appended at the end of the first document but within the Form Tags so that I can read subsequently. Thanks Regards Rakesh -----Original Message----- From: Elliott, Brian [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 7:57 AM To: [log in to unmask] Subject: Re: Document Api in CICS ts1.3 Use the AT and TO options of the EXEC CICS DOCUMENT INSERT command. You must create "bookmarks" first. See the App. Prog. Ref. manual for assistance... Brian Elliott TSG-CICS/MQ Series West Affiliated Computer Services Phone: 615-221-0801 E-Mail: [log in to unmask] or [log in to unmask] -----Original Message----- From: Rakesh Kaushika [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 9:40 AM To: [log in to unmask] Subject: Document Api in CICS ts1.3 Hi Listers! I am using Document insert command to insert a selection list in a document.The output goes fine and I see the dropdown list on the browser with the document. The problem is when I try to read this selection field in my program by using WEB READ FORMFIELD I get EIBRESP 13 which is Form field not found. looking at the source on the browser I find that this selection list was added at the end after the and I think that is why I am getting Form field not found. what should i be doing so that the selection list gets inserted before the and not at the end after . any suggestions or ideas would be greatly appreciated. Thanks Rakesh ========================================================================Date: Fri, 12 Oct 2001 15:44:07 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: David Clancy <[log in to unmask]> Subject: Re: Document Api in CICS ts1.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Twopence worth. If you dont use bookmarks, insert appends to the end of the current document. If you use bookmarks (optional) you specify where it goes. Whatever, the basic problem as identified is that the list is outside the tag. Whichever techninque you choose, you'll need 3 templates not 2 1st template has the beginning stuff
2nd template has your list and other stuff 3rd template has the terminaters
Without bookmarks, you will have to add them to the document in the sequence 1,2,3 With bookmarks you can add them to the document in any sequence. Either technique will work regards David Clancy Circle Computer Group ----- Original Message ----- From: "Elliott, Brian" <[log in to unmask]> To: <[log in to unmask]> Sent: Friday, October 12, 2001 3:35 PM Subject: Re: Document Api in CICS ts1.3 > It looks like that's not the case... It appears that you've proven to > yourself (and me) that CWS is appending it after all of the HTML in the > template (including the and tags)... > > I would always advise using bookmarks... I think that is the safest way > to go, because you are always certain where the HTML is being > inserted... > > > Brian Elliott > TSG-CICS/MQ Series West > Affiliated Computer Services > Phone: 615-221-0801 > E-Mail: [log in to unmask] or [log in to unmask] > > > -----Original Message----- > From: Rakesh Kaushika [mailto:[log in to unmask]] > Sent: Friday, October 12, 2001 10:29 AM > To: [log in to unmask] > Subject: Re: Document Api in CICS ts1.3 > > > Brian! > I am using a Template for creating my first document and then using > document > insert for adding the selection list. > do I still need to create bookmarks?I was assuming that the selection > list > would be appended at the end of the first document > but within the Form Tags so that I can read subsequently. > Thanks > Regards > Rakesh > > > -----Original Message----- > From: Elliott, Brian [mailto:[log in to unmask]] > Sent: Friday, October 12, 2001 7:57 AM > To: [log in to unmask] > Subject: Re: Document Api in CICS ts1.3 > > > Use the AT and TO options of the EXEC CICS DOCUMENT INSERT command. You > must create "bookmarks" first. See the App. Prog. Ref. manual for > assistance... > > > Brian Elliott > TSG-CICS/MQ Series West > Affiliated Computer Services > Phone: 615-221-0801 > E-Mail: [log in to unmask] or [log in to unmask] > > > -----Original Message----- > From: Rakesh Kaushika [mailto:[log in to unmask]] > Sent: Friday, October 12, 2001 9:40 AM > To: [log in to unmask] > Subject: Document Api in CICS ts1.3 > > > Hi Listers! > I am using Document insert command to insert a selection list in a > document.The output goes fine and I see the dropdown list on the browser > with the document. > The problem is when I try to read this selection field in my program by > using WEB READ FORMFIELD I get EIBRESP 13 which is Form field not found. > looking at the source on the browser I find that this selection list was > added at the end after the and I think that is why I am getting > Form > field not found. > what should i be doing so that the selection list gets inserted before > the > and not at the end after . > any suggestions or ideas would be greatly appreciated. > Thanks > Rakesh ========================================================================Date: Fri, 12 Oct 2001 09:51:51 -0500 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: "Elliott, Brian" <[log in to unmask]> Subject: Re: Document Api in CICS ts1.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit You must create the bookmark BEFORE you create the DOCUMENT... Brian Elliott TSG-CICS/MQ Series West Affiliated Computer Services Phone: 615-221-0801 E-Mail: [log in to unmask] or [log in to unmask] -----Original Message----- From: Rakesh Kaushika [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 10:44 AM To: [log in to unmask] Subject: Re: Document Api in CICS ts1.3 Hi Brian! Since I am using a fixed template for my first document where and how do I create the bookmark.If I do it after the create document (from template) and then insert the selection list using AT (bookmark)it still puts the selection list after the .I guess I am missing something. Thanks for all yr help.I appreciate it. Regards Rakesh -----Original Message----- From: Elliott, Brian [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 8:35 AM To: [log in to unmask] Subject: Re: Document Api in CICS ts1.3 It looks like that's not the case... It appears that you've proven to yourself (and me) that CWS is appending it after all of the HTML in the template (including the and tags)... I would always advise using bookmarks... I think that is the safest way to go, because you are always certain where the HTML is being inserted... Brian Elliott TSG-CICS/MQ Series West Affiliated Computer Services Phone: 615-221-0801 E-Mail: [log in to unmask] or [log in to unmask] -----Original Message----- From: Rakesh Kaushika [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 10:29 AM To: [log in to unmask] Subject: Re: Document Api in CICS ts1.3 Brian! I am using a Template for creating my first document and then using document insert for adding the selection list. do I still need to create bookmarks?I was assuming that the selection list would be appended at the end of the first document but within the Form Tags so that I can read subsequently. Thanks Regards Rakesh -----Original Message----- From: Elliott, Brian [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 7:57 AM To: [log in to unmask] Subject: Re: Document Api in CICS ts1.3 Use the AT and TO options of the EXEC CICS DOCUMENT INSERT command. You must create "bookmarks" first. See the App. Prog. Ref. manual for assistance... Brian Elliott TSG-CICS/MQ Series West Affiliated Computer Services Phone: 615-221-0801 E-Mail: [log in to unmask] or [log in to unmask] -----Original Message----- From: Rakesh Kaushika [mailto:[log in to unmask]] Sent: Friday, October 12, 2001 9:40 AM To: [log in to unmask] Subject: Document Api in CICS ts1.3 Hi Listers! I am using Document insert command to insert a selection list in a document.The output goes fine and I see the dropdown list on the browser with the document. The problem is when I try to read this selection field in my program by using WEB READ FORMFIELD I get EIBRESP 13 which is Form field not found. looking at the source on the browser I find that this selection list was added at the end after the and I think that is why I am getting Form field not found. what should i be doing so that the selection list gets inserted before the and not at the end after . any suggestions or ideas would be greatly appreciated. Thanks Rakesh ========================================================================Date: Fri, 12 Oct 2001 16:00:25 +0100 Reply-To: CICS List <[log in to unmask]> Sender: CICS List <[log in to unmask]> From: Vaughan Phillips <[log in to unmask]> Subject: Re: Document Api in CICS ts1.3 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Rakesh, Reading between the lines, it sounds like you're building a page of HTML and that the Selection List is a component of this list and it may or may not need to being created dynamically. If it is to be created dynamically, then you need at least 3 templates to get the job done. The first template should be all the HTML up to and including the first