Has anyone written a journal close exit program, DFHXJCC, they would be willing to share? Or could give me direction with the one I am attempting to write? I have a basic understanding of CICS command level programming. I started with the example in PRD1.BASE, DFHXJCC.A. It is working to identifying the CICS job name EC INQUIRE SYSTEM JOBNAME, writing messages to console EC WRITE OPERATOR and submitting our backup job via EC SPOOLOPEN JCL, EC SPOOLWRITE, EC SPOOLCLOSE. It is after the SPOOLCLOSE and when the program does an EC RETURN that it abends with,
CONSOLE:
DFHDU0201 TTOTALDV ABOUT TO TAKE SDUMP. DUMPCODE: DB112
PROCESSED DUMP:
=== DUMP SUMMARY
DUMPID: 1/0001
DUMPCODE: DB112
DATE/TIME: 17/06/20 13:50:19 (LOCAL)
MESSAGE: DFHJC4512 06/06/17 13:50:19 TTOTALDV CICS JOURNAL 03 NO LONGER AVAILABLE - OUTPUT VOLUME-SWITCH FAILURE
SYMPTOMS: PIDS/564805400 LVLS/411 MS/DFHJC4512 RIDS/DFHJCEOV PTFS/UQ75266
And I don’t get the normal journal switch messages,
0222 DFHJC4583 TTOTALDV JOURNAL 03 PRIMARY DATA SET (DFHJ03A) READY TO BE
COPIED. REPLY 'Y03A' WHEN COPIED.
0234 DFHJC4508 TTOTALDV CICS JOURNAL 03. SECONDARY DATA SET NOW RECEIVING
OUTPUT ON 0BE3
From the dump summary message it would seem that I may be stepping on a register?
TIA,
Steve
Steve Mondy
Sr. Systems Administrator
Open Solutions Division
Fiserv
Office: 713-965-8457
Mobile: 281-409-2870
Fax: 281-334-2642
www.fiserv.com
FORTUNE Magazine World's Most Admired Companies® 2014 | 2015 | 2016 |
2017
Facebook: Like Fiserv · Twitter:
Follow @Fiserv
· LinkedIn:
Connect Fiserv
· Careers: Join
Fiserv
Not sure why you want to do this. We simply use the ARCHJCL= in the DFHJCT macro to “submit” a job to archive the journal when a switch occurs. It passes information via SETPARM variables that can be used in the submitted job.
Frank M. Ramaekers Jr.
_____________________________________________________
This message contains information which is privileged and confidential and is solely for the use of the
intended recipient. If you are not the intended recipient, be aware that any review, disclosure,
copying, distribution, or use of the contents of this message is strictly prohibited. If you have
received this in error, please destroy it immediately and notify us at Priva...@torchmarkcorp.com.
Frank,
Primary reason, which is not always a good reason, is history. We have a CICS/23 DFHXJCC exit, which was required to be in macro level. I threw that one away and am attempt to duplicate the functions in a CICS/TS version which is required to be command level. Much simpler in command level except for my level of experience. I did take a quick look at ARCHJCL but didn’t think it would work for our environment. We have multiple CICS client regions, each with a different region identifier which creates a different JCL member to be submitted. I thought that to use ARCHJCL I might have to have a different DFHJCTxx for each region. The region identifier is one of the things our exit handles. I will take another look at the ARCHJCL option. Maybe I can handle the region JCL via the DFHJACD, archive control data set.
Steve
It does pass the SETPARM variable &APPLID, which should be unique to each reagion…this can easily be converted to your “region identifier” (whatever that is).
Here’s a list of SETPARMs that it generates for the ARCHJCL job:
SYST The 4-byte identifier of the CICS region issuing the
journal archive job. (derived from the SYSIDENT
system initialization parameter.)
JJ A 2-digit journal identification (JFILEID), in the range
01 through 99.
D A 1 character dataset identification: A or B.
JOURDSN A 1- to 44-byte journal dataset name.
ODATE A 7-byte journal dataset open date (yyyyddd).
OTIME A 7-byte journal dataset open time (hhmmsst).
CDATE A 7-byte journal dataset close date (yyyyddd).
CTIME A 7-byte journal dataset close time (hhmmsst).
JACDDSN A 1- to 44byte JACD dataset name.
APPLID A 1- to 8-byte CICS APPLID. Note that for an XRF
system, this is the generice, not the specific,
APPLID.
These are documented in “Chaper7. Journal utility programs” in “CICS Transaction Server for VSE/ESA Operations and Utilities Guide”.
Frank,
Thanks for the information. I was just reviewing the same.
Our region id is one character that is used by all the JCL and other name prefix for that region. It is in the VSE/POWER JNM & SLI member type; is the first character of the // JOB name. It is also used at the first character of each disk and tape data set name. And the first character of the APPLID.
Today as we are not using AUTOARCH we have a common DFHJCTXX use by all regions. To use AUTOARCH the ARCHJCL=J03ABKU must be cataloged as J03ABKU.DFHJASP. I don’t see a way to substitute the region id in J03ABKU.DFHJASP JCL member.
Example for our ‘Q’ region below. The ‘Q’ would change to next region id.
* $$ JOB JNM=QCICSTP…
* $$ SLI MEM=CICSTP.Q
* $$ EOJ
CATALOG CICSTP.Q
// JOB QCICSTP
…
APPLID=QONLINE
/*
/&
/+
Journal backup for DFHJ03A;
* $$ JOB JNM=QJ03ABKU…
* $$ SLI MEM=J03ABKU.Q
* $$ EOJ
CATALOG J03ABKU.Q
// JOB QJ03ABKU
…
/&
/+
CATALOG J03ABKU.DFHJASP
$$$$ JOB JNM=QJ03ABKU …
$$$$ SLI MEM=J03ABKU.Q
$$$$ EOJ
No, but this job (the one referred to by ARCHJCL can then in turn submit the proper JCL (from a library member). (Perhaps a simple LIBR PUNCH, which can use the PARM= and substitute SETPARM variables.)
I use a job generator (i.e. SYSIPT to SYSPUN with SETPARM substitution) and it creates the proper job. (I use this method because you can’t substitute SETPARMs in POWER JECL.)
There is a number of ways to accomplish this, we can discuss off-line.