Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CICS/TS Journal Close Exit DFHXJCC

24 views
Skip to first unread message

Mondy, Stephen , US - Texas

unread,
Jun 7, 2017, 11:39:55 AM6/7/17
to

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

 

Frank M. Ramaekers

unread,
Jun 7, 2017, 11:53:30 AM6/7/17
to

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.

Mondy, Stephen , US - Texas

unread,
Jun 7, 2017, 12:36:24 PM6/7/17
to

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

Frank M. Ramaekers

unread,
Jun 7, 2017, 2:03:15 PM6/7/17
to

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).

Frank M. Ramaekers

unread,
Jun 7, 2017, 2:10:53 PM6/7/17
to

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”.

Mondy, Stephen , US - Texas

unread,
Jun 7, 2017, 3:33:13 PM6/7/17
to

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

Frank M. Ramaekers

unread,
Jun 7, 2017, 3:49:22 PM6/7/17
to

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.

0 new messages