>From reading other messages in the thread, you need a way to automatically
>report CICS abends to the appropriate group. Your plan is to put this
>information to a disk dataset, then process it looking for messages such as:
DFHAC2236 02/14/2012 21:33:56 IMCM Transaction GC3# abend ABM3 in program
GCXSP970 term ????. Updates to local recoverable resources
Is this correct? These messages go out to the MSGUSG DD. Why not just put those
messages to disk directly, perhaps in a GDG. The DSN would include the CICS
region name. Perhaps something like: CICS.MSGUSR.&CICSID.(+1) where &CICSID is
a PROC variable equal to the name of the region. You could easily read this
dataset using the (0) gen, or GDG-ALL processing. If you need it to go to
SYSOUT as well, then just put in an IEBGENER step after the CICS region
execution step.
OK, the problem with the above is that you can't see the messages in "real
time" because you won't be able to browse the output dataset while the region
is up. I understand that this could be a major problem. I have a solution for
this. But it may not be acceptable. Instead of writing the messages to a
sequential dataset, write them to a z/OS UNIX file. One "nice" thing is that
you can read/browse a UNIX file even while it is still being written to by
another job. The DD statement in the CICS JCL would look something like:
//MSGUSR DD PATH='/cics/&CICSID..msgusr.txt',
// PATHDISP=(KEEP,KEEP),PATHOPTS=(OCREAT,OWRONLY,OAPPEND),
// FILEDATA=TEXT,
// LRECL=132,RECFM=V,BLKSIZE=136
The OAPPEND is the UNIX equivalent of DISP=MOD, but it doesn't stop others from
concurrently reading the file. And you will see all the records because UNIX
doesn't "buffer" data the same way that QSAM does. So it's more like SYSOUT in
that respect.
In a subsequent step, copy the file to SYSOUT and/or the aforementioned disk
GDG. Your users will need to learn something new in order to view "real time"
messages.
A plus to this is that your messages are in a UNIX file. Why is that a plus?
Because you can then use UNIX utilities to get the data you need. A short "awk"
program might be:
#!/bin/awk
/^DFHAC2236 / {print $2 " " $3 " " $4 " " $6 " " $8 " " $11 " " $13;}
that one line of code will find all the DFHAC2236 messages. It will then print
the date ($2), time ($3), region ($4), transaction ($6), abend code ($8),
program ($11) and terminal ($13) to "stdout". You can use the redirection
operator, >, to direct this to another UNIX file. In batch, you can then use
IEBGENER to copy that UNIX file to a sequential dataset, if you need to, for
futher processing. Or just process the data directly. If you put those two
lines in a file, say called, /cics/DFHAC2236.awk, you can invoke it:
awk -f /cics/DFHAC2236.awk /cics/PROD1.msgusr.txt >/cics/PROD1.dfhac2236.txt
Invocation JCL could look something like:
// PART1='/bin/awk -f /cics/DFHAC2236.awk '
// PART2='/cics/PROD1.msgusr.txt '
// PART3='>/cics/PROD1.dfhac2236.txt'
//PS001 EXEC PGM=BPXBATCH,REGION=0M,
// PARM='&PART1&PART2&PART3 '
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDIN DD PATH='/dev/null',
// PATHOPTS=(ORDONLY)
//STDENV DD *
/*
I use &PART1, &PART2, and &PART3 in the above for clarity, and to pass a long
PARM without needing JCL continuation, which confuses me. Note that the JCL is
untested and not guaranteed.
Instead of doing the copy in a subsequent step in the CICS JCL, you might want
to have a batch job do it, if you can "trigger" a batch job when the CICS
region terminates. We do this type of triggering in CA-7.
//PRINT EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT2 DD SYSOUT=*
//SYSUT1 DD PATH='/cics/PROD1.msgusr.txt',
// PATHDISP=(KEEP,KEEP),PATHOPTS=(ORDONLY),
// FILEDATA=TEXT,
// LRECL=132,RECFM=V,BLKSIZE=136
Direct SYSUT2 to a disk or tape dataset, if desired.
Eventually, you will want to "reset" the UNIX file. But that is simple.
//RESET EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT1 DD DUMMY,LRECL=132,RECFM=V,BLKSIZE=136
//SYSUT2 DD PATH='/cics/PROD1.msgusr.txt',
// PATHDISP=(KEEP,KEEP),PATHOPTS=(OCREAT,OWRONLY,OTRUNC),
// FILEDATA=TEXT,
// LRECL=132,RECFM=V,BLKSIZE=136
You are coping 0 records into the file. But the OTRUNC tells the system to
reset the file to a zero length file at OPEN time.
Just a strange idea, from the "master" of strange ideas <grin>.
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets®
9151 Boulevard 26 . N. Richland Hills . TX 76010
(817) 255-3225 phone .
[email protected] . www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets® is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA
Life and Health Insurance Company.SM
> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:[email protected]] On Behalf Of Sérgio Lima Costa
> Sent: Wednesday, February 15, 2012 5:59 AM
> To: [email protected]
> Subject: Question about XDC BATCH and automation
>
> Hello List,
>
> We need all days here, Access the SYSOUT from CICS under SDSF
> , then, give the XDC command, to save the sysout on DASD,
> next, Edit this file, for locate all abends, save this file
> on another file, and send this information to development people.
>
> So, we want know, if is possible, made a automation in this
> process, first , using XDC running a BATCH JOB, this is possible ?
> If, Yes, have a way, that I know, what is the last CICS JOBS
> on SYSOUT, because, today, We enter, manually in this SYSOUT,
> for locate the last report.
> The remainder, I know how to do.
> With a sample REXX program, I can extract what We need from
> the SYSOUT.
>
> Thanks very much.
>
> Sergio
>
>
>
>
>
>
>
>
>
>
> ________________________________
> "Atenção: Esta mensagem foi enviada para uso exclusivo do(s)
> destinatários(s) acima identificado(s),
> podendo conter informações e/ou documentos
> confidencias/privilegiados e seu sigilo é protegido por
> lei. Caso você tenha recebido por engano, por favor, informe
> o remetente e apague-a de seu sistema.
> Notificamos que é proibido por lei a sua retenção,
> disseminação, distribuição, cópia ou uso sem
> expressa autorização do remetente. Opiniões pessoais do
> remetente não refletem, necessariamente,
> o ponto de vista da CETIP, o qual é divulgado somente por
> pessoas autorizadas."
>
> "Warning: This message was sent for exclusive use of the
> addressees above identified, possibly
> containing information and or privileged/confidential
> documents whose content is protected by law.
> In case you have mistakenly received it, please notify the
> sender and delete it from your system.
> Be noticed that the law forbids the retention, dissemination,
> distribution, copy or use without
> express authorization from the sender. Personal opinions of
> the sender do not necessarily reflect
> CETIP's point of view, which is only divulged by authorized
> personnel."
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
