cics sep 2004 - cbt · pdf fileseptember 2004 226 in this issue ... 10 redirecting output from...

© Xephon Inc 2004

September 2004

226

In this issue

3 Considerations regarding the Killfunction

10 Redirecting output from Javavirtual machines with CICS TS2.3

21 Tuning CICS TS 2.3 EJB serverutilizing enhanced EJB andJava support – part 2

32 Investigating storage violations46 CICS news

Current Support

Xephon magazine issues are now supported at www.cbttape.org. Please go to www.cbttape.org if you have any support questions.

2

CICS UpdatePublished byXephon IncPO Box 550547Dallas, Texas 75355USA

Phone: 214-340-5690Fax: 214-341-7081

EditorTrevor EddollsE-mail: [email protected]

PublisherNicole ThomasE-mail: [email protected]

Subscriptions and back-issuesA year’s subscription to CICS Update,comprising twelve monthly issues, costs$270.00 in the USA and Canada; £175.00 inthe UK; £181.00 in Europe; £187.00 inAustralasia and Japan; and £185.50elsewhere. In all cases the price includespostage. Individual issues, starting with theDecember 2000 issue, are availableseparately to subscribers for $24.00 (£16.00)each including postage.

CICS Update on-lineCode from CICS Update, and completeissues in Acrobat PDF format, can bedownloaded from our Web site at http://www.xephon.com/cics; you will need tosupply a word from the printed issue.

© Xephon Inc 2004. All rights reserved. None of the text in this publication may be reproduced,stored in a retrieval system, or transmitted in any form or by any means, without the priorpermission of the copyright owner. Subscribers are free to copy any code reproduced in thispublication for use in their own installations, but may not sell such code or incorporate it in anycommercial product. No part of this publication may be used for any form of advertising, salespromotion, or publicity without the written permission of the publisher.

Printed in England.

DisclaimerReaders are cautioned that, although theinformation in this journal is presented in goodfaith, neither Xephon nor the organizations orindividuals that supplied information in thisjournal give any warranty or make anyrepresentations as to the accuracy of thematerial it contains. Neither Xephon nor thecontributing organizations or individualsaccept any liability of any kind howsoeverarising out of the use of such material.Readers should satisfy themselves as to thecorrectness and relevance to theircircumstances of all advice, information,code, JCL, and other contents of this journalbefore making any use of it.

ContributionsWhen Xephon is given copyright, articlespublished in CICS Update are paid for at therate of $160 (£100 outside North America)per 1000 words and $80 (£50) per 100 lines ofcode for the first 200 lines of original material.The remaining code is paid for at the rate of$32 (£20) per 100 lines. To find out moreabout contributing an article, without anyobligation, please download a copy of ourNotes for Contributors fromwww.xephon.com/nfc.

3© 2004. Reproduction prohibited. Please inform Xephon of any infringement.

Considerations regarding the Kill function

The recent introduction of the Kill function in CICS, and theassociated CEKL transaction, leads to a number of considerationsand related behaviour that warrant further information. Thisarticle describes the background to inappropriate use of the Killfunction within CICS, the CICS enhancements to messages anddump information regarding Kill, and gives some guidance onways to approach event investigation within CICS following theuse of the Kill function.

INAPPROPRIATE USE OF THE KILL FUNCTION

If a task is purged while in a CICS dispatcher wait, CICS candetect this and take appropriate action. Normally this will be toinvoke the relevant clean-up routine(s) and then abend the task.An example is that of a CEDF task wait in DFHEDFD. If this taskis purged, the task being stepped through under EDF will beresumed before the CEDF task is itself abended.

With the use of the Kill function, most CICS clean-up routines arebypassed, and so, in this example, the task being steppedthrough with EDF would remain hanging indefinitely in a wait inDFHEDFX. The use of Kill against a task suspended by EDF isan example of an inappropriate use of the Kill function. It does notallow DFHEDFX to be notified of the Kill operation. As such, thiscan result in a CICS Dispatcher domain DFHDS0002 messageand dump (error code X'0071') for the suspended task.

It should be noted, however, that a task waiting within DFHEDFXfor CEDF processing to complete is in a purgable wait, and so Killis not intended for use against such a waiting task. Normal purgeand forcepurge functionality can be utilized in such a case.Remember that purge and forcepurge commands are designedto tidy up the task and system environments as part of theiroperation. The important point to note is that the use of Kill isintended very much as a last resort, and does not guaranteesystem or data integrity. Before Kill is used, it is important to

4 © 2004. Xephon USA telephone (214) 340 5690, fax (214) 341 7081.

understand the type of wait that the target task is in. This can beachieved using tools such as CEMT, the EXEC CICS SPI,CICSPlex SM, or CEKL. Also, purge and/or forcepurge should beattempted before a Kill function is made against any task in CICSanyway.

Certain situations within CICS inhibit purge or forcepurgeoperations to preserve integrity. An example is while a CICS taskis waiting for a VSAM I/O operation to complete. If a Kill requestwere used against such a waiting task, the results would beunpredictable when the I/O did eventually complete. It is for thisreason that all transaction dumps resulting from Kill operationsshould be retained, to allow investigation of the state of the taskwhen it was killed and correlation with any subsequent CICSsystem problems.

RELATED CICS ENHANCEMENTS

A number of new CICS messages are associated with the Killfunction. From an automated operator perspective, these maybe of interest. The message numbers for the new CQ domainwithin CICS are as follows:

DFHCQØØØ1, DFHCQØØØ2, DFHCQØ1ØØ, DFHCQØ1Ø1, DFHCQØ1Ø2, DFHCQØ1Ø3,

DFHCQØ1Ø4, DFHCQØ1Ø5, DFHCQØ2ØØ, DFHCQØ2Ø1, DFHCQØ21Ø, DFHCQØ211,

DFHCQØ212, DFHCQØ213, DFHCQØ214, DFHCQØ215, DFHCQØ216, DFHCQØ217,

DFHCQØ218, DFHCQØ22Ø, DFHCQØ221, DFHCQØ224, DFHCQØ23Ø, DFHCQØ231,

DFHCQØ232, DFHCQØ233, DFHCQØ234, DFHCQØ24Ø, DFHCQØ241, DFHCQØ242,

DFHCQØ243, DFHCQØ25Ø, DFHCQØ251, DFHCQØ252, DFHCQØ253, DFHCQØ254,

DFHCQØ255, DFHCQØ256, DFHCQØ257, DFHCQØ258, DFHCQØ259, DFHCQØ26Ø,

DFHCQØ261, DFHCQØ262, DFHCQØ263, DFHCQØ264, DFHCQØ265, and DFHCQØ266.

Also, DFHDS0010, DFHDS0011, and DFHME0139 messagesreflect CICS dispatcher and message domain responses to Killevents.

Of these messages, there are a number that are worth consideringin more detail:

• DFHCQ0100 – console queue initialization has started.

• DFHCQ0101 – console queue initialization has ended.

• DFHCQ0200 – CEKL transaction enabled.


The above three messages are informational, and relate to theCEKL console environment being initialized. They tell you thatthe use of the CEKL facility is available for this CICS system.

The following message is issued when a CEKL inquire commandresults in one or more tasks that are found matching the optionsspecified on the command:

DFHCQØ243 CEKL INQUIRE: matched selection criteria.

CICS displays information about these tasks on the console andjob log.

The following three messages relate to the use of CEKL toattempt to cancel tasks from CICS:

DFHCQØ252 CEKL SET: PURGE request issued for task number 'task num'.

DFHCQØ256 CEKL SET: FORCEPURGE request issued for task number 'task no'.

DFHCQØ259 CEKL SET: KILL request issued for task number 'task num'.

The following message is issued to confirm the acceptance of a(non-CEKL issued) Kill request against a task:

DFHDSØØ1Ø Kill request accepted for transaction id 'transid',

transaction number 'task num', userid 'userid'.

The following message is issued to confirm the reacceptance ofa (non-CEKL issued) Kill request against a task. In other words,a Kill attempt has been issued against a task for which a Killrequest has already been issued:

DFHDSØØ11 Kill request reaccepted for transaction id 'transid',

transaction number 'tran num', userid 'userid'.

In addition, there are a number of new CICS abend codesintroduced to support the Kill function. These are of the formAKKx. The type of abend code gives details about the nature ofthe Kill request, and so is worth understanding in more detail.

Abend codes AKKA, AKKB, and AKKC signify (CICS SPI/CEMT/CICSPlex SM) Kill request details for tasks in various states ofpurge and forcepurge protection within CICS:

• AKKA

Explanation: a Kill request has been actioned when a taskwas not protected from purge or force purge.


• AKKB

Explanation: a Kill request has been actioned when a taskwas not protected from forcepurge but was protected frompurge.

• AKKC

Explanation: a Kill request has been actioned when a taskwas protected from forcepurge.

Abend codes AKKD and AKKE reflect that CEKL options havebeen used:

• AKKD

Explanation: a CEKL purge has been requested.

• AKKE

Explanation: a CEKL forcepurge has been requested.

Finally, abend codes AKKG and AKKH describe Kill requestsinvolving task runaway:

• AKKG

Explanation: the CICS kernel (KE) domain has detected aKill request from the runaway exit program. The task was notprotected from runaway when the Kill request was actioned.

• AKKH

Explanation: the CICS Kernel (KE) domain has detected aKill request from the runaway exit program. The task wasprotected from runaway when the request was actioned.

Understanding these abend codes can be of use wheninvestigating any unforeseen events within the CICS system thatmay occur as a result of the use of the Kill function.

EVENT INVESTIGATION AFTER THE USE OF KILL

The use of Kill may result in subsequent problems within CICS,


because of the unpredictable effects that the Kill operation canhave on the system and data integrity. To that end, it may benecessary to investigate subsequent problems that arise afterKill has been used.

In addition to analysis of the transaction dumps from the tasksabended by the use of Kill, there are other useful sources ofinformation that can provide additional data.

The CEKL transaction records details of tasks that have beenabended by a CEKL Kill request.

This information is displayed within the CQ VERBX whenformatting a CICS system dump. It can be used in tandem withthe various associated system console messages and CICSmessages.

In the example data below, CEKL was used to issue a Kill requestagainst a transaction TEST.

The command to do this was:

F CICSJOBN,CEKL SET TASK(ØØØ28) KILL

The following information appeared on the console as a result:

+CICSJOBN DFHCQØ259I

CEKL SET: KILL request issued for task number ØØØ28.

+CICSJOBN TAS(ØØØ28) KIL SUS QR TEST USE(CICSUSER) ATT(ØØØ29) CPU(*****)

RUA(ØØØ2Ø)

+CICSJOBN HTI(ØØØ3Ø) HTY(ICWAIT) HVA(V111)

CICS issued the following messages:

DFHAC22Ø6 15:35:33 CICSJOBN Transaction TEST failed with abend AKKA.

Updates to local recoverable resources backed out.

DFHDUØ2Ø3I Ø2/27/2ØØ4 15:35:33 CICSJOBN A transaction dump was taken for

dumpcode: AKKA, Dumpid: 1/ØØØ1.

DFHAC2236 Ø2/27/2ØØ4 15:35:33 CICSJOBN Transaction TEST abend AKKA in


program DFHECID term V112. Updates to local recoverable

resources will be backed out.

An examination of the data in the CQ VERBX from a CICSsystem dump revealed the following:

==CQ: CQ TCB TRACE ENTRIES

XM_TXN was located at: 146Ø9Ø3Ø

Transaction number: ØØØ28

CEKL purge status: KIL

TCB: QR

Dispatcher status: SUS

Transaction id: TEST

Transaction class:

User id: CICSUSER

Attach time (seconds): ØØØ29

CPU time (seconds): *****

Run away interval (seconds): ØØØ2Ø

Suspend time (seconds): ØØØ3Ø

Suspend reason: ICWAIT

Suspend value: V111

Using the combination of data items shown above, it is possibleto establish the environment that was in place at the time a taskwas abended by use of the Kill function. This information can beof use when investigating any subsequent problems that mayoccur after this point in time. Once again, it is important toemphasize that the use of the Kill function is intended very muchas a last resort. Such problem determination should be regardedas an important technique, but one that would rarely be expectedto need to be employed.


POINTS TO NOTE REGARDING THE KILL FUNCTION

When the Kill function is used to terminate a task, the subsequentabend cannot be handled by an application (via an EXEC CICSHANDLE command), nor via other recovery routines that otherproducts may have in place.

In addition, the abend of the task will result in a dynamictransaction backout (DTB), where any changes to recoverableresources that were made within the task’s Unit Of Work (UOW)are backed out. This is also the case when a task is purged orforcepurged. As such, the task being terminated may not leavethe CICS system immediately; there will be a period of timerequired for it to back out its modifications as part of abnormaltermination. It is possible to determine the state of a task bymeans of the EXEC CICS INQUIRE UOW command. Thisreturns information on the UOWs within the CICS system, suchas their age (in seconds), associated transaction identifier andtask number, and also the state of the UOW – whether it is inflight,in backout, indoubt, etc. If a UOW is shown to be in backout state,then this shows that CICS is backing out the recoverablechanges made during its lifetime. This approach can reveal whya task that was Killed has yet to leave the system (it also appliesto those tasks that were purged or forcepurged, for that matter).

As described above, the use of Kill can lead to unpredictableresults. One of these is that the termination of tasks that arecurrently within backout processing can result in CICS beingterminated as a result. Such tasks are protected from beingpurged or forcepurged, but Kill requests are allowed to beperformed against them. As such, an initial examination of theirstate (by means of the CEMT INQ UOW or EXEC CICS INQUOW SPI options) is worthwhile. This approach requires that theQR TCB be available to process such requests against the UOW.

It is not always possible for CICS to honour purge, forcepurge,or Kill requests. For example, if CICS is Short On Storage (SOS),the act of abending a task can result in the request not being ableto complete for lack of available CICS storage anyway.


Redirecting output from Java virtual machines withCICS TS 2.3

Java applications running under the control of CICS TransactionServer can produce both output and error messages. These mayneed to be handled in specific ways for different applications.CICS TS Version 2 Release 3 provides a mechanism to intercept,modify, and redirect these messages.

This article explains how the output redirection mechanism canbe customized and configured. It describes in detail the samplecode provided by CICS, which illustrates how this mechanismcan be tailored. This article is primarily intended for Javaprogrammers who are designing new applications that will runwithin CICS, and who wish to influence the way messages arehandled. It may also be of interest to systems programmers whoare responsible for setting up the environment that supports Javaworkloads within CICS.

INPUT AND OUTPUT OPERATIONS IN JAVA

Java applications may perform both input and output operationswhen they execute. Output is directed to one destination forstandard output and a second one for standard error output.Similarly an application can read input from a device. These

CONCLUSION

I hope this article has helped give a background to some of theconsiderations regarding the implementation of Kill supportwithin CICS and offered some guidance on the associatedmessage, dump and usage issues pertaining to the Kill function.

Andy Wright ([email protected])CICS Change Team ProgrammerIBM (UK) © IBM 2004


locations are referred to as STDOUT, STDERR, and STDIN,respectively, throughout the CICS documentation.

The way this is supported though the Java programming modelis a consequence of the fact that all Java programs automaticallyimport the java.lang package. This package defines, amongstother things, a class called System, which controls run-timefunctions including those used for input and output by a program.

In Java, the input a program receives and the output it producesare considered as streams of data. In the System class there arethree predefined variables representing an input stream and twooutput streams (one for normal output and the other for erroroutput). These are identified as in, out, and err respectively.

These fields are declared as public and static within the Systemclass, permitting them to be used within a Java program withoutthe need to refer to a specific instance of a System object. In thisway the program does not have to be concerned about how itreceives its input, or how it delivers output or error messages.

OUTPUT FROM JVMS RUNNING UNDER THE CONTROL OF CICS

CICS TS has provided support for Java programs for a numberof releases. It makes use of information in a file known as theJVM profile to control the launching operation for the JVMs thatCICS manages. A second file, the JVM properties file, defines theoperational characteristics of a JVM.

CICS takes responsibility for defining the location of the input,output, and error streams when it starts up a JVM. It does so bylooking for a number of different options in the JVM profile thatit reads prior to launching the new JVM. The WORK_DIR optiondefines the directory in the local Unix Hierarchical File System(HFS), where three files are defined or reused as the input,output, and error streams. The STDIN, STDOUT, and STDERRoptions indicate the name of the files to be used. If any or all ofthese options are missing, then CICS assumes default values forthose components that are not defined in the JVM Profile.


If a number of JVMs use the same profile, they will share acommon set of files. This may result in messages from differentJVMs becoming interleaved. To avoid this situation, there is a -generate parameter that can be included with the STDOUT andSTDERR option in a JVM Profile. This causes a unique name tobe generated for that file when a JVM starts, identified by a timestamp and the applid of the CICS region. In this way, output anderror messages can be directed to separate files for each JVM.However when a JVM is reused by several program invocations,all messages from these programs are then written to the sameoutput and error files.

Prior to CICS TS 2.3 no provision was made for the furtherseparation of messages produced from within a single JVM bya series of transactions running there. There was no way toaugment messages with additional information when they werebeing delivered, other than to do this by the Java application thatissued them. This makes it difficult to distinguish those messagesthat originated from a single application instance running in areusable JVM. It was also only possible to send these messagesto a destination in the Unix file system.

OUTPUT REDIRECTION WITH CICS TS 2.3

Release 2.3 of CICS permits a single Java class to be named ina JVM profile, which is to be used to redirect output fromapplications running in any JVM using that profile. The class isdefined using the USEROUTPUTCLASS option. There is nodefault class for this option, and, if it is not included in a JVMProfile, then those JVMs referencing that profile when they arelaunched have the output redirection mechanism turned off.

THE OUTPUT REDIRECTION MECHANISM

CICS starts up JVMs only in response to requests to run Javaprograms. When a new JVM is created, CICS identifies the nameof a JVM Profile from the resource definition for the program ithas been asked to run. The JVM Profile is read, and theinformation in it is used to launch the new JVM.


Once the JVM has been started, a special class, which CICSprovides, known as the Wrapper, is invoked within the JVM, andis used to perform some state initialization functions. However,the main purpose of the Wrapper is to carry out pre- and post-processing around the execution of each Java application that isrun within a JVM.

Once a JVM has fully initialized, CICS calls the main method ofthe Wrapper with an argument list that CICS has set up. Thisargument list consists of two parts. The first is the name of theinitial Java class defined by the JVMCLASS property of the Javaprogram’s CICS resource definition. The second is optional and,when included, contains the name of the Java class that is to beused for output redirection, which was found from theUSEROUTPUTCLASS option when the JVM’s Profile wasoriginally read.

The Wrapper is used to carry out operations before and after theexecution of the real Java application. Prior to running theapplication, the Wrapper looks to see whether there is an outputredirection class in its argument list, and, if found, an instance ofthe class object is created for output and another for errors foruse by the current application. If no class is found, output anderror messages will be routed to the destinations identified fromthe STDOUT and STDERR options defined in the JVM’s Profile,or from their default settings if these options are missing.

When a Java application finishes executing, control passes backto the Wrapper, which then discards the instances of the objectsused to redirect standard output and standard error messages.

The output redirection class must be placed on the trustedmiddleware classpath for the Wrapper to be able to locate it. Thisis done by adding the class name to the TMPREFIX or TMSUFFIXoption in the JVM Profile. Once successfully loaded, controlpasses to the writeRecord() method of this class whenever theJVM attempts to use System.out or System.err. This method canbe tailored to suit the needs of a particular workload.

CICS provides a Java interface, called


OutputRedirectionPlugin.java, which is used by the Wrapper tocreate instances of the output redirection object. Any user-written class must implement this interface if it is to be used forthe purpose described here.

THE OUTPUTREDIRECTIONPLUGIN INTERFACE

This interface is provided in the com.ibm.cics.server subdirectoryof the CICS TS route directory in the HFS. This is also where theWrapper class is located.

The interface has the following signature:

import java.io.*;

public interface OutputRedirectionPlugin {

public void initRedirect( String inDest,

PrintStream inPS,

PrintStream inStderr,

String inApplid,

String inProgramName,

Integer inTaskNumber,

String inTransid

);

When the Wrapper uses this interface, it substitutes either the‘stdout’ or the ‘stderr’ character string for the inDest. This is thelabel that the intended destination is known by.

The inPS parameter is the PrintStream, which represents theoriginal destination for this particular category of messages –STDOUT or STDERR. The inStderr parameter is the PrintStreamof the original STDERR for the JVM. It is included to permit anyclass implementing the interface to know where messageswould be routed if it were not used, and also to provide somewhereto write error messages should the redirection mechanismencounter a problem when it is being used.

The remaining fields in the interface allow the Wrapper to handon values that may be useful to the output redirection class.These might then be used to extend a message or to create anew one.


SAMPLES PROVIDED BY CICS

Two samples are provided with CICS TS 2.3 to illustrate differentways to use the output redirection mechanism. Both of theseinherit from a common abstract superclass,com.ibm.cics.samples.SJStream. All of these can be found inthe HFS directory /usr/lpp/cicsts/cicsts23/lib, where cicsts23 is auser-defined value that is selected for the CICS_DIRECTORYvariable used by the DFHIJVMJ job during CICS installation.

THE SJSTREAM CLASS

This superclass extends the outputStream class and implementsthe OutputRedirectionPlugin interface. It defines default methodscalled close(), flush(), write(byte[]), write(byte[],int,int), write(int),openHFS(), and an abstract method called writeRecord(). It alsocontains an initRedirect() method, which is where the interfaceimplementation is found. This method does nothing more thanreturn the Boolean value of false. The Wrapper uses thisBoolean value to indicate whether or not it has successfullycalled the interface.

This failure reported by the superclass forces any class thatinherits from it to include an initRedirect() method, which can beused to create and initialize some objects, and which returns aBoolean value of true, indicating that it has been successful.Such a class must also include a writeRecord() method, whichcontrols the redirection of the messages that are written throughit.

THE SJMERGEDSTREAM CLASS

The com.ibm.cics.samples.SJMergedStream classdemonstrates how to send output and error messages to differentTransient Data queues. The queues that are named in thesample are CSJE and CSJO. Resource definitions are providedby CICS for both of these queues and need to be installed priorto using this particular class.

The initRedirect method initializes the state of the object instance


of this class. Because there are separate object instances forstandard output and standard error message handling, theinstance responsible for output messages makes use of theCSJO TD queue, and the one for error messages uses CSJE.

During the initialization of these object instances, a fully-qualifiedfile name is generated, which indicates where in the local HFSmessages are to be written should a failure occur while using theTD queue.

The writeRecord() method implements the code, which redirectsthe data being sent from the application executing in the JVM. Itextends each message that is being redirected by addinginformation to the beginning. It uses the Date class, from thejava.util package, to obtain a time stamp for each message. Thisis concatenated together with the applid, transid, task number,and program name, which were all determined by the Wrapperand fed in using the interface. This data is then added to thebeginning of the current message, which is being processed,before it is written out to the redirected destination.

Next, this method attempts to write the message to a TD queue.There is the restriction that CICS resources are accessible fromonly the initial process thread of a Java application. Attempts todo so from other threads would result in unnecessary errors,which are avoided in this sample by carrying out a test to seewhich thread is currently being used. If the initial process threadis not the current one, the message is written to the file whosename was previously generated by the initRedirect() method.

Much of the code in the writeRecord() method is contained withina single try/catch block and, as a result, all exceptions that areencountered are handled in the same way. This is one area in thesamples that could be extended to allow specific conditions –such as a failure occurring because the data is too large for theTD queue’s record size – to be dealt with differently from, forinstance, the one raised if the queue is not found or is disabled.

When an error condition is encountered within the writeRecord()method, some care has to be taken if there is a requirement to


write out a message reporting this event, because this messagemay get dispatched into the failing method and an infinite loopmight be entered. The sample deals with this problem withrecursion. It looks to see whether this object represents redirectionfor STDERR or for STDOUT. If it is STDERR then any messagesare sent directly to the original STDERR for the JVM, avoidingfurther attempts to redirect them; if it is, it is safe to attempt tosend an error message to the redirected STDERR.

Once the error has been reported, the writeHFS() method iscalled to send the message to the file system. This methodsupersedes the one defined in the SJStream class. It deals withfailures to write to the file in a similar manner to the writeRecord()method. In doing so, messages are always written somewhere.If they cannot go to the TD queue, an attempt is made to sendthem to a file, and, if this fails, they end up in the original STDOUTor STDERR destination.

THE SJTASKSTREAM CLASS

The com.ibm.cics.samples.SJTaskStream class has a similarinitRedirect method to set up and maintain state informationused by subsequent redirection operations. However, the maindifference in this class is that each task that executes in a singleJVM has its own unique file for output and a second one for errormessages.

The Date class is again used to derive a timestamp. This isconcatenated with the string ‘.task.’, which is in turn concatenatedwith the task number to produce a unique file name. In addition,a directory name is derived for the file. This is made up fromlooking up the system property user.dir and then adding to it theCICS region applid followed by either the ‘stdout’ or the ‘stderr’string, depending on which type of message this output redirectionobject is intended to process. If this system property is not set,/temp is used as the root directory, which is then extended withthe applid and either stdout or stderr. An example of this directorymight be /usr/lpp/cics/cicsts23/IYKABC1A/stdout/.


The initRedirect() method then uses the File(String) constructor,provided by the java.io package, to create an instance of thisdirectory and then the File(File, String) constructor to create aninstance of the file itself. If either of these fails, the method returns‘false’ to indicate to the Wrapper that output redirection is notpossible for the JVM. The main cause of errors during theseoperations is that the security permission settings in some partof the HFS prevent the new file or its directory from being created.

Another difference in this version of the initRedirect() method isthat it instantiates an object called ‘baos’, which is created usingthe ByteArrayOutputStream class. This class is an implementationof an output stream that uses a byte array as the destination. Theconstructor that is used for this has no arguments and results ina 32-byte output buffer being created for use by this object. Asecond constructor is available and could be used if a different-sized buffer is needed.

When a message is written by a program running in the JVM thatis using this sample for output redirection, the writeRecord()method is invoked. This method attempts to open the file if it hasnot been used thus far and if no file open errors have beenreported by any previous calls to this method. It does this bychecking the content of the buffer outBuffer, which belongs to thebaos object and which is set to null before it is used. If a failureoccurs while attempting to open the file, a flag is set to preventfurther attempts from taking place should the method be calledagain.

A new String is created from the concatenation of a timestamp,the applid, transid, task number, and program name, followed bythe content of the record that is being written by the Javaapplication running in the JVM. The record content is retrieved bycalling the toString() method on the baos object. Once built, thisnew extended message, even if it cannot be redirected to thepreferred destination, is the one that will appear in the originalSTDOUT or STDERR file.

If there was no error when opening the file, an attempt is madeto write a new record to it. Three methods are called on the


outBuffer object. The first is used to write the record into thebuffer. The second adds a new line character to the end of therecord, and the third method is used to flush the buffer. Thereset() method is then called on the baos object to clear its bufferfor use by any subsequent request that may be issued from theJava application running in the JVM.

Any errors that occur during these operations are handled in asingle catch block. This block determines whether or not thecurrent record is being redirected for stderr, and, if it is, amessage reporting the error is written to the original STDERR,followed by the current record. This prevents an infinite loop frombeing entered while attempting to write an error message to aredirected destination that is failing, and ensures that the originalmessage is still written somewhere.

If, instead, this is a record that is being redirected for stdout, thenan attempt is made to send a message to stderr reporting theproblem, which message itself may then be redirected. Followingthis, the original message is written to the original STDOUTdestination for the JVM.

The last part of the writeRecord() method deals with the situationwhere the file could not be opened. If there is some data in thebuffer belonging to the baos object, and if the destination isSTDERR, there is nothing to do at this point because this is thebottom of a recursive sequence resulting from a failure with theredirected error destination. As the recursion rolls back, themessage will get written to the original STDERR for the JVM. Theonly remaining option is to deal with data that is being written toan output stream. The redirected version of this stream has failedand here an error message is written to the redirected STDERRbefore the current record is written to the original STDOUT.

MODIFYING THE SAMPLES OR WRITING ALTERNATIVE CLASSES

The samples can be used unchanged so long as any CICSresources that they depend on are installed and enabled on theregion that controls JVMs that make use of them. However, theyare unlikely to suit the needs of a broad variety of Java workloads.


They could form the basis of a template that customers mightthen tailor or extend to suit their own requirements. The generalstructure of these samples provides the logic needed to allowerrors to be dealt with, avoiding recursive problems when errormessages are issued from within the methods. The error handlingis very basic in both the samples, and this is one area that mightbe customized to separate out the actions taken when somespecific condition is encountered.

If, instead, new classes are written for this purpose, they couldinherit from the SJStream class or they could simply implementthe OutputRedirectionPlugin Java interface. Whichever approachis adopted, care should be taken when using CICS resourceswithin an output redirection class to avoid inadvertently trying touse them when dealing with output from a multithreaded Javaapplication. CICS resources can be used by such a class onlywhen accessed from the initial process thread.

Finally it is worth pointing out that the generation of output anderror messages is comparatively expensive and that this overheadbecomes worse when output redirection is used. As a result, thismechanism should be used only when there is a real need andshould be avoided in a production system wherever possible.

FINDING FURTHER INFORMATION ON THIS SUBJECT

The CICS Infocentre provides a wealth of information on the useof Java in CICS and describes output redirection in some detail.A good Java 2 programming reference is another place to lookfor information on the classes and interfaces that are provided bythe java.io package. The CICS samples use only a small subsetof the classes and methods that are provided by the Javalanguage. As a result, there is considerable opportunity toenhance output redirection beyond what is demonstrated inthese samples.

Mike BrooksSenior IT SpecialistCICS Development, IBM Hursley Park (UK) © IBM 2004


Tuning CICS TS 2.3 EJB server utilizing enhancedEJB and Java support – part 2

This month we conclude the article looking at tuning CICS TS 2.3EJB server, utilizing enhanced EJB and Java support.

LE enclave allocation:

• A system heap contains system class objects that persist forthe lifetime of the JVM. JVMs never perform garbagecollection on this heap. Worker JVMs do not have a systemheap because they use the master JVM’s system heap.

• An application-class system heap contains class objectsrepresenting sharable application classes, which persist forthe lifetime of the JVM and are reinitialized if the JVM is reset.JVMs never perform garbage collection on this heap. WorkerJVMs do not have an application-class system heap becausethey use the master JVM’s system heap. Continuous andsingle-use JVMs (those with REUSE=YES, REUSE=NO orXresettable=NO in their JVM profile) do not have anapplication-class system heap because these types of JVMare not reset after use.

• A non-system heap comprises two other heaps of variablesize:

– A middleware heap, which contains objects whose lifetimeis greater than a single transaction. JVMs performgarbage collection on this heap. All types of JVM havea middleware heap.

– A transient heap, which contains objects whose lifetimeis the same as the transaction using it. The segregationof this heap from the middleware heap improves theperformance of garbage collection. JVMs can performgarbage collection on this heap if it runs out of space inthe non-system heap. It is also completely deleted if theJVM is reset.


If you are using continuous JVMs, you need to be aware that thestorage heaps in these JVMs are not automatically cleaned upafter each program invocation. As a result of this, the continuousJVM might require either larger storage heap sizes or morefrequent garbage collection. A resettable stand-alone JVM runningthe same workload can potentially have lower storagerequirements, depending on the application design and theextent to which each program cleans up after itself. You also needto remember to set aside storage in each region for the sharedclass cache itself.

You need to pay special attention to how JVM standard classpaths are defined. The standard class path is the only class paththat is taken from the profile for the worker JVM itself, rather thanfrom the profile for the master JVM. Classes on this class pathare loaded into the individual worker JVMs and are not cachedin the shared class cache. Do not add classes to this class pathbecause it is detrimental to performance for a resettable workerJVM, since the classes are reloaded every time the JVM is reset.For a continuous worker JVM, these classes are kept intact fromone JVM reuse to the next, so there is no need to reload them buthaving the classes in every JVM uses more storage than havinga single copy in the master JVM. To reduce heap storagerequirements, you should avoid using the standard class path forworker JVMs in a production environment.

For better performance, choose the shareable application classpath for application classes that you want to be cached. Forstand-alone JVMs, the classes will be cached in the JVM, keptacross JVM reuses, and reinitialized if the JVM is reset. Forworker JVMs, they will be obtained from the shared class cache.Adding application classes to a sharable application class path,rather than to a standard class path, produces the bestperformance in a resettable JVM, and it should be your normalchoice for loading application classes in a production environment.

As for xmx settings, my suggestion is to set the initial value highand tune it down, based on the statistics you collected. Toincrease the accuracy of the results, you should purge any JVMs


with the profile that you are tuning, around the time of a statisticsreset. This ensures that the statistics collected in the nextstatistics interval are a more accurate reflection of the storageusage for those JVMs.

Suggested initial HEAP size setting can be as follows and shouldbe tuned based on garbage collection (GC) output:

• Xmx=60M (set higher than you could possibly use)

• Xinitth=500K (not applicable for a continuous JVM)

• Xms=30M

• Xmaxf=1 (turns off heap shrinkage)

• Xmaxe=1M (with Xmine setting, sets heap expansions to500K)

• Xmine=1M

• Do not specify Xinitsh (will default to 128KB)

• Do not specify Xinitacsh (will default to 128KB).

GARBAGE COLLECTION

For CICS TS 2.3, a full garbage collection is automaticallyrequested by CICS for each JVM after every 101 transactions. Ifa JVM runs out of space in one of its storage heaps in betweenthese automatic garbage collections, and is unable to allocateany more objects (an allocation failure), the Garbage Collector(GC) tries to expand the storage heap. If there is not enough freestorage available to do this, because the middleware heap andthe transient heap have already been expanded to fill the amountof storage specified by the xmx option in the JVM profile, a fullgarbage collection is triggered to free some storage. It isgenerally better to tune the heap settings to avoid this situationso that, if possible, the automatic garbage collections are theonly full garbage collections performed.

From the output produced by GC, you can see whether the JVMprofile for the JVM contains the right settings for the initial and


maximum sizes of the storage heaps and check that you havespecified appropriate storage for the needs of the programs thatrun in the JVM. When you have optimized your use of virtualstorage for each JVM, you might be able to increase the numberof JVMs in your CICS region, if needed.

GC collection is set by specifying VERBOSE=gc in the JVMprofile that you want to tune. By default, the messages are outputto the file that is specified by the STDERR option in the JVMprofile (the default name is dfhjvmerr) in the HFS directory thatis specified by the WORK_DIR option in the JVM profile.

These ‘action’ fields in the GC report are in order of severity andhave the following values:

• 1 – a pre emptive garbage collection cycle

• 2 – full allocation failure

• 3 – a heap expansion takes place

• 4 – all known soft references are cleared

• 5 – stealing from the transient heap is done.

The example below shows output from GC, where the xmxsetting is too low. Output from this garbage collection reportshows an allocation failure, where there is insufficient space inone of the storage heaps for the JVM to allocate an object,causing heap expansion. In this case the middleware heap andthe transient heap have already been expanded to fill the amountof storage specified by the xmx option in the JVM profile. Thisoutput shows that the value for the xmx option in the JVM profileis insufficient for the requirements of the Java programs, and itcan indicate that the JVM has not been correctly tuned.

.

<AF[7]: Allocation Failure. need 524 bytes, 1894 ms since last AF>

<AF[7]: managing allocation failure, action=3 (1962672/3471872)>

<GC(53): GC cycle started Fri Mar 5 Ø9:16:12 2ØØ4

<GC(53): freed 114688 bytes from Transient Heap 96% free

(5Ø7376/523776) and>

<GC(53): freed 247144 bytes, 62% free (2Ø78744/334Ø8ØØ), in 6 ms>


<GC(53): mark: 5 ms, sweep: 1 ms, compact: Ø ms>

<GC(53): refs: soft Ø (age <= 32), weak Ø, final Ø, phantom Ø>

<AF[7]: completed in 7 ms>

To ensure that you do not encounter too frequent garbagecollection (which might indicate that the xmx value is too low),please review JVM monitoring data, the JVMRTIME field, whichshows the elapsed time spent resetting the JVM environment toits initial state, including any garbage collection that takes placein the JVM.

CHOOSING APPROPRIATE MAXJVMTCBS LIMIT

The MAXJVMTCBS system initialization parameter limits thetotal number of TCBs in the pool of J8- and J9-mode open TCBsthat CICS uses for JVMs. CICS decides how many of themshould be J8 TCBs and how many should be J9 TCBs, accordingto the number of requests that specify each execution key. TheJM TCB, for the master JVM, which initializes the shared classcache, does not count towards the MAXJVMTCBS limit.

The default setting for MAXJVMTCBS is 5, where the minimumpermitted value is 1 (meaning that CICS is always able to createat least one open TCB). You have to be careful not to over specifythis value. Each JVM runs in its own LE, and uses MVS storage.For this reason, you need to choose a MAXJVMTCBS limit foryour CICS region based on the amount of MVS storage availablefor the use of the region and the amount of MVS storage used byeach of your JVMs. If you set a MAXJVMTCBS limit that is toohigh, CICS might attempt to create too many JVMs for theavailable MVS storage, resulting in an MVS storage constraint.You may want to do volume testing in your developmentenvironment, issuing frequent statistics and setting theMAXJVMTCB value relatively low (under 8). Reviewing the CICSshutdown statistics will help you determine how much of MVSstorage is used by each JVM, and will enable you to calculatewhat the MAXJVMTCB limit should be for optimum performance,while leaving enough of a cushion in unallocated MVS storage forthe CICS address space.


You can change the setting for MAXJVMTCBS without restartingCICS by using the CEMT SET DISPATCHER MAXJVMTCBScommand.

To estimate how many JVMs you need to support a desired levelof transaction throughput, use the following formula:

ETR x Response time = Number of JVMs

where:

• ETR is the desired level of transaction throughput.

• Response time is the time taken to run your transaction in aJVM.

If you have determined that your CICS region could benefit froman increase in the number of JVMs, you now need to calculatethe maximum number of JVMs that your CICS region couldsupport. To calculate the maximum number of JVMs your CICSregion can allocate, perform the following calculation:

Free storage available in the CICS address space/storage needed per JVM

JVM STORAGE MANAGEMENT

JVMs use storage that is managed by MVS, and so they cannotmake use of the storage management facilities available fromthe existing CICS storage manager. This was an issue underCICS TS 2.2 when testing with a high number of EJB JVMs.When MVS storage above the 16MB line was exhausted, I haveseen it spilling into MVS storage below the line and causing asituation CICS could not recover from. An example of CICSshutdown statistics showing this condition is below.

CICS TS 2.2 statistics:

Private Area Region size below 16Mb . . . . . . . . : 1Ø,216K

Max LSQA/SWA storage allocated below 16Mb (SYS) . : 556K

Max User storage allocated below 16Mb (VIRT). . . : 9,668K

System Use. . . . . . . . . . . . . . . . . . . . : 2ØK

RTM . . . . . . . . . . . . . . . . . . . . . . . : 25ØK

__________________________________________________________________

Private Area storage available below 16Mb . . . . . : -278K <===


With CICS TS 2.3, IBM made great enhancements to this area.Now there is a new storage monitor provided for managing MVSstorage. As JVMs make requests for MVS storage, the storagemonitor checks whether the availability of MVS storage hasdropped below pre-set thresholds and notifies CICS when this isthe case, thus avoiding an outage. Once CICS has been notifiedthat MVS storage is constrained, the actions it takes, dependingon the seriousness of the situation, are as follows:

• When MVS storage is constrained, CICS deletes JVMs inthe JVM pool that are not currently in use, together with theirTCBs. However, new JVMs can still be created for incomingrequests.

• When MVS storage is severely constrained, CICS temporarilyprevents the creation of new JVMs for incoming requests,and behaves as though the MAXJVMTCBS limit has beenreached and the JVM pool is full. CICS then terminates allJVMs as soon as they finish running their current Javaprograms. If limited MVS storage is available, and thestorage monitor is still receiving requests from CICS tocreate JVMs, it queues any such requests that cannot obtainsufficient MVS storage.

• When CICS manages to reduce its use of MVS storage bythese methods, and the availability of MVS storage has risenabove the pre-set thresholds, the storage monitor informsCICS that it can return to normal operation. As it does so,operator messages inform you when MVS storage is nolonger constrained.

You can now run Java programs in a JVM that executes in userkey. A new type of open TCB, the J9 TCB, is used for these JVMs.Running applications in user key extends CICS storage protection,and the J9 TCB uses less storage below the line than other TCBs.When you set the EXECKEY parameter on the PROGRAMresource definition for a Java program to USER, a J9 TCB is usedfor the JVM, and MVS storage is obtained in user key. When theEXECKEY parameter is set to CICS, a J8 TCB is used, and MVSstorage is obtained in CICS key.


The default for the EXECKEY parameter is USER. As runningapplications in user key extend CICS storage protection, it couldbe beneficial to let most of your Java programs run in a JVM inuser key. However, you might need to execute a JVM in CICS keyif the program that uses the JVM is part of a transaction thatspecifies TASKDATAKEY(CICS). If this is the case, you need toinvoke the JVM using a PROGRAM resource definition thatspecifies EXECKEY(CICS).

For enterprise beans, CIRP (the default transaction forREQUESTMODEL definitions) specifiesTASKDATAKEY(USER), and the PROGRAM resource definitionfor DFJIIRP (the default request processor program) specifiesEXECKEY(USER), so by default enterprise beans run in userkey. The master JVM that initializes the shared class cache isinvoked in user key, so that worker JVMs that were invoked inuser key can read and write to the shared class cache. Even ifall the worker JVMs that share the class cache are invoked inCICS key, the master JVM and the shared class cache are stillin user key.

Z/OS SHARED LIBRARY REGION – REDUCING THE AMOUNT OFREAL STORAGE

Another area that presents a tuning opportunity, which mostCICS system programmers may not be aware of, is a sharedlibrary region z/OS feature that enables address spaces to shareDynamic Link Library (DLL) files. This feature enables CICSregions to share the DLLs that are needed for JVMs, rather thaneach region having to load them individually. This can greatlyreduce the amount of real storage used by MVS, and the time ittakes for the regions to load the files.

The amount of storage that is allocated is controlled by theSHRLIBRGNSIZE parameter in z/OS, which is in the BPXPRMxxmember of SYS1.PARMLIB. The minimum is 16MB, and the z/OS default is 64MB. The storage that is reserved for the sharedlibrary region is allocated in each CICS region when the first JVMis started in the region.


You can issue the command D OMVS,L to display the librarystatistics and tune down the shared library allocation whenappropriate. The DLLs needed for the JVM use around 10MB ofthe region and you can set the allocation as low as 16MB.

Please note that if you under-allocate SHRLIBRGNSIZE, you willnot benefit from the sharing facility, since when the shared libraryregion is full, the files will be loaded into private storage instead.

USING CICS MONITORING FACILITY TO MONITOR CPUOVERHEAD

The CICS monitoring facility can be used to monitor the CPUtime used by a transaction that invokes a JVM program, includingthe amount of CPU time used by the JVM on a J8 or J9 TCB. The

Figure 1: Monitoring data fields


CICS monitoring facility also includes the elapsed time spent inthe JVM and the number of JCICS API requests issued by theJVM program.

When reviewing JVM reset time, note that for a continuous JVMthe JVM reset time is usually zero, but not always. This isbecause although continuous JVMs are not reset after each use,CICS still requests garbage collection for these JVMs every 101transactions. This process takes place after the 101st use of theJVM, and garbage collection is recorded as JVM reset time.

Watch out for unnecessary CPU time used by JVMs. In particular,look out for the use of tracing, the use of the USEROUTPUTCLASSoption in JVM profiles, and resettable JVMs that are beingre-initialized instead of being reset. Setting the CICS mastersystem trace flag on and/or activating JVM trace will significantlyincrease the CPU cost of a JVM program execution and shouldnot be used in production.

Figure 1 shows the monitoring data fields that can be used forperformance monitoring.

Figure 2: CICS TS V2.2 and V2.3 performance data

Simple EJB application (null) - 1JVM


PERFORMANCE DATA

John Burgess of IBM Hursley (a member of the CICS PerformanceTeam) documented CICS TS V2.2 and V2.3 performance data,which is shown in Figure 2 and demonstrates a dramaticreduction in CPU, running Java and EJB applications underCICS TS 2.3.

Note: in order to improve JVM start-up performance under CICSTS 2.2, IBM delivered the PQ68286/UQ76199 fix, which madechanges to the processing of JVMs within CICS to reduce thetime taken to initialize a JVM.

You can reduce the start-up time for your JVMs by addingXservice="-Xquickstart" to the JVM profiles that are used by yourJava programs. At JVM start-up, the -Xquickstart option causesthe Just-In-Time (JIT) compiler function of the JVM to run with asubset of optimizations. When the JVM is subsequently reusedby other Java programs, the JIT-compiling process runs again tocompile the code into its optimal form, and this will degradeperformance for those programs. So by specifying -Xquickstart,you are reducing the initial start-up time for your JVMs, butcausing a minor performance impact during later reuses of theJVMs.

So, as you can see, there is close to a three times reduction inCPU overhead for a sample EJB application, and a JVM start-uptime reduction by 60%, using continuous JVM and shared classcache in comparison to CICS TS 2.2 – making CICS TS 2.3 anexcellent choice for developing CICS EJB and Java applications.

SUMMARY

For shops looking to Web-enable CICS applications, using Javaunder CICS and CICS Connectors simplifies development ofnew e-business applications, reduces the overall cost ofcomputing, and allows reuse of existing programming andoperational skills without requiring a fundamental re-education ofthe system programmers and operators. CICS TS 2.3 not onlyprovides functional enhancements in Java functionality under


CICS, but also addresses the issue of performance, which hasbeen inhibiting some shops from making use of CICS EJBserver, because of the very high CPU overhead.

CICS TS 2.3 provides a robust high-performance environmentfor enterprise applications written in Java. It exploits SDK V1.4.1and has an architecture which ensures that Java applicationshave a high degree of isolation from each other. Java applicationsrunning under CICS now have reduced storage and start-uprequirements for each JVM and enhanced execution broughtabout by improve behaviour under stress. CICS also enablesconstruction of reusable business logic components that arebinary portable between CICS and WebSphere and may bedeployed in either environment using the same tools, by exploitingthe WebSphere EJB container.

Elena NanosIBM Certified Solution Expert in CICS Web EnablementZurich NA (USA) © Xephon 2004

Investigating storage violations

This CICS Global User Exit will collect in an in-core table all the‘linked to’ programs in CICS key.

The reason for writing this exit is that over the years and withdifferent CICS releases, we have suffered a storage violationfour to six times each year. As all storage protection features areON, the program forcing the violation must be in CICS key.

The violation hits CICS domains like program, load, TS, in thechaining of resource entries, and system X'85' TIOAs.

When the violation occurs, a sysdump is taken by CICS, and inthis sysdump we can investigate the in-core table and see thenames of the last used programs in CICS key. There are twotables: one collects the programs as a summary, the other


collects the programs as a single entry in a wraparound table.Programs in CICS key and not linked to should get an entrysaying ‘Link to a CICS key program’ (if the source is available...).I have never seen DFH-named programs collected by the exit.

ASSEMBLER PROGRAM CODE*ASM CICS (SP)

EPCC TITLE 'CICS PC EXIT GLUEXPCC XPCREQ '

MACRO

&LABEL CICWTO &MSG MESSAGE

.* CHECK THE MESSAGE PARAMETER

AIF ('&MSG' EQ '').NOTE1 MISSING MESSAGE

.* THE ADDRESS OF THE MESSAGE HAS BEEN SPECIFIED

LA 1,&MSG ADDRESS THE MESSAGE

DS ØH

WTO MF=(E,(1)) ISSUE WTO SVC

MEXIT

.* PARAMETER ERROR

.NOTE1 ANOP

MNOTE 2Ø,'MESSAGE MISSING'

MEXIT ,

MEND

EJECT

***********************************************************************

* CICS GLUE EXIT: XPCREQ INVOKED BEFORE A PROGRAM LINK IS PROCESSED

* CICS RELEASE: 5.3 / 6.2

* PROGRAM NAME: GLUEXPCC

* REASON: FIND THE LAST DRIVEN CICS-KEY PROGRAMS OF A STORAGE

* VIOLATION SYSDUMP

* PURPOSE: COLLECT CALLER AND CALLED PROGRAM NAMES

* OF CICS-KEY PROGRAMS IN A WRAP AROUND TABLE 'COLLTABL'

* THE LAST DATA-LINE FOLLOWS A WRAP-LINE TO FIND THE WRAP

* POINT OF THE TABLE (THE WRAP POINT CAN BEE SEEN TOO

* IN THE EIBTIME TABLE ENTRY)

* COLLECT CICS-KEY PROGRAM USAGE COUNT IN A TABLE 'OFTLTABL'

* SOLUTION: COLLECT REQUESTS IN 2 CWA CHAINED OFF IN-STORAGE TABLES

* CWAPOINTER: CWAEXIPL

* CALL ENVIRONMENT: API + XPI

* START AND STOP THE EXIT

* 1. CEMT COMMAND ENABLE... DISABLE... PROGRAM (GLUEXPCC)

* EXIT (XPCREQ) GALENGTH (2Ø48) START / STOP

* SAVE THE COLLECTED DATA: A PLTSD PROGRAMS PRODUCES A TRANSACTION

* DUMP OF THE TABLE 'OFTLTABL' CONTAINING PROGRAM SUMMARY USAGE

* VIEW THE COLLECTED DATA ONLINE: AN ONLINE CORE DISPLAY TRANSACTION

* DISPLAYS THE COLLECTED DATA, BASED ON THE POINTER IN CWA FIELD

* CWAEXIPL (IF TRANSACTION IS AVAILABLE)


***********************************************************************

EJECT

***********************************************************************

* PROGRAM REGISTER USAGE :

* RØ - WORK REGISTER

* R1 - POINTS TO DFHUEPAR PLIST ON ENTRY

* WORK REGISTER

* R2 - DFHUEPAR PARAMETER LIST AFTER ENTRY

* R3 - CODE BASE REGISTER 1

* R4 - CWA

* R5 - XPI PARAMETER LIST

* R6 - UNUSED

* R7 - CODE BASE REGISTER 2

* R8 - COMMAND PARAMETER LIST UEPCLPS

* R9 - DSECT COLLTABL COLLECT TABLE STORAGE PER QUEUE

* R1Ø- DATAREG FOR DFHEISTG

* R11- EIBREG

* R12- DSECT TABSTORA COLLECT TABLE STORAGE HEADER AND QUEUES

* R13- ORIGINAL SAVE AREA

* KERNEL STACK FOR XPI CALLS

* R14- WORK REGISTER

* R15- WORK REGISTER

***********************************************************************

EJECT

*--------------------------------------------------------------------*

* DSECTS FOR COLLECT-TABLE STORAGE

*--------------------------------------------------------------------*

* HEADER AND ENTRIES PER LINK REQUEST

* ALWAYS DEFINE PAIRS OF 8: TO GET A GOOD VIEW INTO STORAGE

SPACE

TABSTORA DSECT

* H E A D E R

TABEYECA DS D 8 EYECATCHER

TABJOBNA DS CL8 8 JOBNAME

TABDISP DS A DISPLCMENT TO TABTCOMA

TABEMPTY DS CL12 16 EMPTY

SPACE

DS ØC T I M E S, D A T E S, R C - S

TKBFIENT DS CL4 EIBTIME FIRST ENTRY EYECATCHER

TABFIENT DS CL4 8 EIBTIME FIRST ENTRY

TKBLAENT DS CL4 EIBTIME LAST ENTRY EYECATCHER

TABLAENT DS CL4 8 EIBTIME LAST ENTRY

TKBDATE DS CL4 EIBDATE FIRST ENTRY EYECATCHER

TABDATE DS CL4 8 EIBDATE FIRST ENTRY

PKEEXIRC DS CL1 RC OF PREVIOUS EXIT EYECATCHER

PREEXIRC DS CL2 RC OF PREVIOUS EXIT

DS CL5 8 EMTPY, FILLER TO DOWO

SPACE

DS ØC C U R R E N T C A L L

PROGINEY DS CL8 8 INVOKING PROGRAM EYECATCHER


PROGINVO DS CL8 8 INVOKING PROGRAM

PROGLIEY DS CL8 8 LINK TO PROGRAM EYECATCHER

PROGLINK DS CL8 8 LINK TO PROGRAM

PROKLIEY DS CL8 8 INQUIRE PROGRAM EYECATCHER

PROKLINK DS CL8 8 INQUIRE PROGRAM NAME, ERROR

RFPROKLI DS PL8 8 INQUIRE PROGRAM NAME, ERROR COUN

RFEMPT2 DS PL8 8 UNUSED

SPACE

DS ØC L A S T C A L L

LASTEYEC DS CL8 8 LAST CALL EYECATCHER

LASTPOIN DS CL4 4 LAST TABLE POINTER

LASTSYSI DS CL4 4 LAST SYSID

LASTCALD DS CL8 8 LAST CALLED PROGRAM NAME

LASTCALR DS CL8 8 LAST CALLER PROGRAM NAME

SPACE

DS ØC C O U N T E R S

RFENR DS PL16 88 ENTRY COUNTER FOR ENTRY MESSAGE

RFTABFU DS PLØ8 8 TABLE IS FULL COLLTABL

RFTABVO DS PLØ8 8 TABLE IS FULL OFTLTABL

RFERROR DS PLØ8 8 NUMBER OF ERRORS

RFERROR1 DS PLØ8 8 UNUSED

RFENTRY DS PLØ8 8 USED ENTRIES

RFEMPT1 DS PLØ8 8 UNUSED

SPACE

* T A B L E E N T R I E S

* COLLECTED LINKS TABLE, PROGRAM SUMMARY

SPACE

TABOCOMC DS CL16 88 EYE CATCHER BEGIN OF TABLE

SPACE

* S U M M E N T R I E S LENGTH

LCLA &O

&O SETA 32 LENGTH OF TABLE ENTRY

SPACE

* S U M M E N T R I E S PHYSICAL

TABOCOMA DS ØCL&O *COLLECTED PROGR* TABLE FOR COLLECTED PROGRAMS

QSENTRY DS ØCL32 OFTL ENTRY

QSID DS CL4 TABLE ID OFTL

QSCALLED DS CL8 CALLED PROGRAM NAME

QSCALLER DS CL8 CALLERS PROGRAM NAME

QSCOUNT DS PL4 UNUSED

QSTASKN DS CL4 TASK NUMBER

QSTIME DS CL4 TIME

SPACE

* DS 1ØCL&O FURTHER TABLE ENTRIES

DS 6ØCL&O FURTHER TABLE ENTRIES

* DS 2ØCL&O FURTHER TABLE ENTRIES TEST

* DS Ø6CL&O FURTHER TABLE ENTRIES TEST

TABOCOME DS CL&O TABLES END END MARKER

SPACE 2

* COLLECTED LINKS TABLE, SINGLE LINK


SPACE

TABTCOMC DS CL16 88 EYE CATCHER BEGIN OF TABLE

SPACE

* L I N K E N T R I E S LENGTH

LCLA &A

&A SETA 32 LENGTH OF TABLE ENTRY

SPACE

* L I N K E N T R I E S PHYSICAL

TABTCOMA DS ØCL&A *COLLECTED LINKS* TABLE FOR COLLECTED LINKS

PSSYSID DS CL4 SYSID OF CICS

PSCALLED DS CL8 CALLED PROGRAM NAME

PSCALLER DS CL8 CALLERS PROGRAMNAME

PSTASKN DS CL4 TASK NUMBER

PSDATE DS CL4 DATE

PSTIME DS CL4 TIME

SPACE

DS 4999CL&A FURTHER TABLE ENTRIES CICS5 4ØØØ

* DS 2ØCL&A FURTHER TABLE ENTRIES TEST

* DS Ø6CL&A FURTHER TABLE ENTRIES TEST

TABTCOME DS CL&A TABLES END END MARKER

SPACE

TABSTORE DS ØD END OF TABSTORA

SPACE

* ENTRIES FOR COLLECTED LINKS

* BASED ON AND TO BE KEPT IN STEP WITH TABTCOMA

* L I N K E N T R I E S LOGICAL

COLLTABL DSECT COLLECTING LINKS

DSKEY DS ØCL2Ø KEY OF TABLE ) KEY

DSSYSID DS CL4 SYSID OF CICS ) KEY

DSCALLED DS CL8 CALLED PROGRAM NAME ) KEY

DSCALLER DS CL8 CALLERS PROGRAMNAME ) KEY

DSTASKN DS CL4 TYPE OF CALL LINK OR XCTL

DSDATE DS CL4 DATE

DSTIME DS CL4 TIME

SPACE

* S U M M E N T R I E S LOGICAL

OFTLTABL DSECT COLLECTING LINKS SUMMARY

OSENTRY DS ØCL32 OFTL ENTRY

OSID DS CL4 TABLE ID OFTL

OSCALLED DS CL8 CALLED PROGRAM NAME

OSCALLER DS CL8 CALLERS PROGRAMNAME

OSCOUNT DS PL4 UNUSED

OSTASKN DS CL4 TYPE OF CALL LINK OR XCTL

OSTIME DS CL4 TIME

SPACE

* P R E D E F I N E D

* P R O G R A M N A M E S LOGICAL

DABONAME DSECT COLLECTING LINKS SUMMARY

DABONAM1 DS CL8 PREGENERATED PROGRAM NAMES

SPACE


EJECT

*---------------------------------------------------------------------*

* CWA LAYOUT

*---------------------------------------------------------------------*

SPACE

CWADSECT DSECT

CWAKENN DS CL18 JOBNAME FILLED IN PLTPI

CWASYSID DS CL4 SYSID FILLES IN PLTPI

CWAEXIPL DS F GETMAIN POINTER

SPACE

EJECT

*---------------------------------------------------------------------*

* THE FOLLOWING DEFINITIONS ARE FOR PROGRAM WORKING STORAGE. *

*---------------------------------------------------------------------*

SPACE

DFHEISTG DSECT

SPACE

EISTGCA DS CL16'GLUEXPCCDFHEISTG' EYECATCHER

SPACE

RETCODE DS XL4 EXIT RETURN CODE

SPACE

GETMRESP DS F GETMAIN RESP

GETMRES2 DS F GETMAIN RESP2

SPACE

SAVEINQU DS F SAVE R14 PROGINQU

SAVEINKU DS F SAVE R14 PROGINQU

SAVEMSG DS F SAVE R14 ROUTINE MSG

SAVEMSG1 DS F SAVE R1 ROUTINE MSG

SAVELIRE DS F SAVE R14 ROUTINE PC_REQUEST_...

SPACE

ZSPROGIN DS CL8 INVOKING PROGRAM XPI CALL

ASZPINVO DS CL8 INVOKING PROGRAM XPI CALL

ASZPRETU DS CL8 RETURNING PROGRAM XPI CALL

SPACE

SYSICURR DS CL4 CURRENT SYSID

LINKCURR DS CL8 CURRENT LINK TO PROGRAM

INVOCURR DS CL8 CURRENT INVOKING PROGRAM

SPACE

SWTABFUL DS X TABLE IS FULL

SPACE

PCGROUP DS C COPY FROM PC_GROUP

PCFUNCT DS C COPY FROM PC_FUNCT

SPACE

RØ74RESP DS F PPT INQUIRE RESP

RØ74LANG DS F PPT INQUIRE LANG

RØ74KEYY DS X PPT INQUIRE KEY

RØ74TOKE DS F PPT INQUIRE TOKEN

RØ74PROG DS CL8 PPT INQUIRE PROGRAM CURRENT

RØ74PROK DS CL8 PPT INQUIRE PROGRAM

SPACE


* AID FOR TEST, PRINT R9 VALUE AS A CONSOLE MESSAGE

SPACE

R9PRSAVE DS F UPRO REGISTER SAVE

R9PRR9R9 DS F,CL1 R9 REMEMBER

R9PRRESP DS F R9 WTO RESP

R9PRLENG DS F R9 WTO LAENGE

SPACE

R9PRMESS DS ØCL3Ø MESSAGE

R9PRMESØ DS CL1Ø' GLUEXPCC ' EXIT PROGRAM NAME

R9PRMES1 DS C' R9=' HEADER

R9PRMES2 DS CL8' ' R9 VALUE HEX

R9PRMES3 DS C FILLER + UNPK SIGN

R9PRMES4 DS CL2 LOGICAL POINT OF CALL

R9PRMES5 DS C FILLER

ORG R9PRMESS+L'R9PRMESS

R9PRMESZ DS CL2 SAVE CALLERS POINT

SPACE

* STANDARD MESSAGE BOX, COPIED FROM MSGBOX TO DFHEISTG AND FILLED THERE

* KEEP IN STEP WITH MSGBOX

DS ØF

MSGEISA DFHMSG (MSGEISØ1,CLØ8'GLUEXPCC', NAME OF EXIT X

MSGEISØ2,CLØ1' ', FILLER X

MSGEISØ3,CLØ4'SYSI', SYSID X

MSGEISØ4,CLØ1' ', FILLER X

MSGEISØ5,CL4Ø'MSGBOXMSGBOX') TEXT

MSGEISE DS ØF END OF MESSAGE BOX

SPACE

EJECT

*---------------------------------------------------------------------*

* COPYBOOK AND DSECTS REQUIRED BY THE EXIT PROGRAM *

*---------------------------------------------------------------------*

SPACE

DFHUEXIT TYPE=EP,ID=(XPCREQ) EXIT SPECIFIC PARAMETERS

SPACE

DFHUEXIT TYPE=XPIENV EXIT PROGRAMING INTERFACE (XPI)

SPACE

COPY DFHXMIQY XPI INQUIRE TRANSACTION CALL

SPACE

COPY DFHSAIQY XPI INQUIRE SYSTEM CALL

SPACE

COPY DFHPGISY XPI INQUIRE CURRENT PROGRAM CALL

SPACE

COPY DFHPCEDS COMMAND LEVEL PLIST DEFINITIONS

SPACE

EJECT

***********************************************************************

* GLUEXPCC - MAIN ROUTINE

**********************************************************************

SPACE

GLUEXPCC DFHEIENT CODEREG=(R3,R7),DATAREG=(R1Ø),EIBREG=(R11)


SPACE

GLUEXPCC AMODE 31

GLUEXPCC RMODE ANY

SPACE

* ADDRESS INCOMING PARAMETERS

SPACE

LR R2,R1 DFHUEPAR PLIST PROVIDED BY CALLER

USING DFHUEPAR,R2 USE R2 TO ADDRESS UEPAR PLIST

SPACE

MVC EISTGCA,=CL16'GLUEXPCCDFHEISTG' EYECATCHER DFHEISTG

SPACE

LA R14,UERCNORM SET OK RESPONSE

ST R14,RETCODE IN WORKING STORAGE

SPACE

SR R12,R12 DE-ADDRESS TABSTORA

SR R9,R9 DE-ADDRESS COLLTABL

B CPEXIØØØ

SPACE

DC C'**I AM GLUEXPCC***' EYECATCHER

VASS

SPACE

* INIT VARIABLES IN DFHEISTG

SPACE

CPEXIØØØ DS ØH

MVC SYSICURR,BLANK BLANK TILL NOW

MVI SWTABFUL,Ø * TABLE NOT YET FULL

SPACE

* ADDRESS EIB

* MAY BE NOT NECESSARY IF NO EXEC CICS CALLS FOLLOW

* OR IF EIB FIELDS ARE NOT USED IN THE TEXT FOLLOWING

EXEC CICS ADDRESS EIB(R11)

USING DFHEIBLK,R11

SPACE

* ASSIGN PROGRAMNAMES

* MAY BE XPI DOES IT BETTER

* XPI DOES THE SAME, I USE XPI

B CPEXIØ2Ø OVERJUMP

SPACE

EXEC CICS ASSIGN INVOKINGPROG (ASZPINVO) X

RETURNPROG (ASZPRETU)

CPEXIØ2Ø DS ØH

SPACE

* COPY MESSAGE BOX, CHECK LENGTH BEFORE..

SPACE

DS ØH CHECK FOR LENGTH EQUAL

CLC =AL2(MSGBOXE-MSGBOXA),=AL2(MSGEISE-MSGEISA)

BNE ERROR14 LENGTH NOT CORRECT

DS ØH

MVC MSGEISA(MSGBOXE-MSGBOXA),MSGBOXA

MVC MSGEISØ5,BLANK


MVC MSGEISØ5(L'ERRTEØØ),ERRTEØØ INITIAL TEXT

SPACE

* CHECK UEPGAA, UEPGAL *EXIPCC*

SPACE

L R14,UEPGAL ADDRESS OF GAA LENGTH

LTR R14,R14 EXISTENCE..

BZ ERROR47 NO, BRANCH TO ERROR ROUTINE

SPACE

LH R15,Ø(R14) GET GAA LENGTH

CH R15,=AL2(2Ø48) GET DATA LENGTH

BL ERROR48 TOO SMALL

SPACE

L R14,UEPGAA ADDRESS OF GAA

LTR R14,14 EXISTENCE

BZ ERROR49 NO, BRANCH TO ERROR ROUTINE

SPACE

* ADDRESS CWA PER XPI CALL 1. ENTRY, UEPGAA AFTER 1. ENTRY

SPACE

DS ØH

L R15,UEPGAA STORE CWA ADDRESS IN UEPGAA

CLC ØØ(8,R15),=CL8'GLUEXPCC' EXITPROGRAM NAME EXISTENT

BNE CPEXIØ3Ø NO, DO XPI CALL

ICM R4,15,24(R15) CWA ADDRESS

B CPEXI1ØØ

SPACE

CPEXIØ3Ø DS ØH GET CWA ADDRESS PER XPI CALL

DS ØH

L R5,UEPXSTOR ADDRESS XPI PARAMETER LIST

USING DFHSAIQ_ARG,R5

L R13,UEPSTACK ADDRESS KERNEL STACK

DFHSAIQX CALL, X

CLEAR, X

IN, IN X

FUNCTION(INQUIRE_SYSTEM), X

OUT, OUT X

CWA((R4)), X

RESPONSE(*), X

REASON(*)

SPACE

USING CWADSECT,R4

SPACE

DS ØH

L R15,UEPGAA STORE CWA ADDRESS IN UEPGAA

MVC ØØ(8,R15),=CL8'GLUEXPCC' EXITPROGRAM

MVC Ø8(8,R15),=CL8'XPCREQ ' EXITNAME

MVC 16(8,R15),=CL8'CWAADRES' CWA ADDRESS EYECATCHER

STCM R4,15,24(R15) CWA ADDRESS

SPACE

L R13,UEPEPSA ADDRESS ORIGINAL SAVE AREA

SPACE


CLI SAIQ_RESPONSE,SAIQ_OK CHECK RESPONSE

BE CPEXI1ØØ

* *** CLI SAIQ_REASON,SAIQ_..... CHECK RESPONSE REASON

* *** DS ØH REASON IS NOT CHECKED

* *** BE *

DROP R5

B ERROR1Ø SEND ERROR MESSAGE

SPACE

* CHECK FOR PROPER CWA LAYOUT

SPACE

CPEXI1ØØ DS ØH

CLC CWAKENN+1Ø(2),KTPXYCIC CWA OK JOBNAME

BNE ERROR11 NO

CLC CWAKENN+14(3),KTPXYCIC+4 CWA OK JOBNAME

BNE ERROR12 NO

SPACE

MVC SYSICURR,CWASYSID SYSID IN CURRENT KEY

MVC MSGEISØ3,CWASYSID SYSID IN MESSAGE

SPACE

* CHECK FOR POSSIBLE RECURSION

L R14,UEPRECUR ADDRESS OF RECURSIVE COUNT

LH R14,Ø(R14) FETCH COUNT

LTR R14,R14 HAS EXIT BEEN INVOKED RECURSIV

BNZ ERROR5 YES, BRANCH TO ERROR ROUTINE

SPACE

* CHECK FOR PROPER EXIT ID

SPACE

L R14,UEPEXN ADDRESS OF 1 BYTE EXIT ID

CLI Ø(R14),XPCREQ IS THIS XPCREQ EXIT?

BNE ERROR1 NO, BRANCH TO ERROR ROUTINE

SPACE

* GETMAIN FOR COLLECT-TABLE PER XPI CALL REGISTER R12

* ONLY ONE TIME, THEN SAVE ADDRESS IN CWAEXIPL

* JOB LIFETIME STORAGE

* GETMAIN DONE BY EXEC CICS API TO AVOID FETCH PROTECTIONS

SPACE

USING TABSTORA,R12

CLC CWAEXIPL(2),=CL2'**' LAST TIME AN ERROR

BE CPEXI21Ø YES

OC CWAEXIPL,CWAEXIPL ALREADY GETMAINED

BZ CPEXI21Ø NO

L R12,CWAEXIPL YES, LOAD USING REGISTER

B CPEXI295

SPACE

CPEXI21Ø DS ØH

XC CWAEXIPL,CWAEXIPL CLEAR, IF LAST TIME AN ERROR

SPACE

EXEC CICS GETMAIN *

FLENGTH (TABSTORL) *

INITIMG (X'ØØ') *


SET (R12) *

NOSUSPEND *

SHARED *

RESP (GETMRESP) *

RESP2 (GETMRES2)

CLC GETMRESP,DFHRESP(NORMAL)

BE CPEXI22Ø

SPACE

MVC CWAEXIPL(2),=CL2'**' REMEMBER ERROR CODE

MVC CWAEXIPL+2(1),GETMRESP+L'GETMRESP-1

MVC CWAEXIPL+3(1),GETMRES2+L'GETMRES2-1

B ERROR13 SEND ERROR MESSAGE

SPACE

DS ØF

TABSTORL DC AL4(TABSTORE-TABSTORA) GETMAIN LENGTH

TABENDMA DC &A.X'FF' END MARKER OF STORAGE

SPACE

* SAVE STORAGE ADDRESS IN CWA, INIT STORAGE

SPACE

CPEXI22Ø DS ØH

SPACE

MVC MSGEISØ5(L'MSGTEØ1),MSGTEØ1 TELL ABOUT THIS ACTION

BAS R14,MSG ONE TIME MESSAGE...

B CPEXI23Ø GO TO GETMAIN INIT TAB STORAGE

MSGTEØ1 DC C'CWA ADDRESSED, GETMAIN DONE'

SPACE

CPEXI23Ø DS ØH

ST R12,CWAEXIPL REMEMBER STORAGE ADDRESS

SPACE

SPACE

SPACE

DS ØH INIT HEADER

DS ØH EYECATCHER, VALUES

DS ØH

ZAP RFENR,=P'Ø' INIT ENTRY COUNTER

ZAP RFTABFU,=P'Ø' INIT TABLE FULL COUNTER

ZAP RFTABVO,=P'Ø' INIT TABLE FULL COUNTER

ZAP RFERROR,=P'Ø' INIT ERROR COUNTER

ZAP RFERROR1,=P'Ø' INIT ERROR COUNTER, UNUSED

ZAP RFENTRY,=P'Ø' INIT USED ENTRIES COUNTER

ZAP RFEMPT1,=P'Ø' INIT RFEMPT1

ZAP RFEMPT2,=P'Ø' INIT RFEMPT2

ZAP RFPROKLI,=P'Ø' INIT RFPROKLI

SPACE

MVC TABEYECA,=CL8'GLUEXPCC' EYECATCHER

MVC TABJOBNA,CWAKENN+1Ø JOBNAME

MVC TABTCOMC,=CL16'*BEGIN OF TABLE*'

MVC TABOCOMC,=CL16'#BEGIN OF TABLE#'

SPACE

OC TABDATE,TABDATE DATE FIRST ENTRY


BNZ *+14

MVC TKBDATE,=CL4'DATE' DATE FIRST ENTRY

MVC TABDATE,EIBDATE DATE FIRST ENTRY

SPACE

OC TABFIENT,TABFIENT TIME FIRST ENTRY

BNZ *+14

MVC TKBFIENT,=CL4'TIMF' TIME FIRST ENTRY

MVC TABFIENT,EIBTIME TIME FIRST ENTRY

SPACE

MVC PROGINEY,=CL8'PROGINEY' PROG NAME INVOKING

MVC PROGLIEY,=CL8'PROGLIEY' PROG NAME LINK TO

MVC PROKLIEY,=CL8'PROKLIEY' PROG NAME LINK TO INKU ERROR

SPACE

SPACE

MVC PROGINVO,=CL8'INVOKING' INIT VALUE PROG NAMES INVOKING

MVC PROGLINK,=CL8'LINKTOPR' INIT VALUE PROG NAMES LINK TO

MVC PROKLINK,=CL8'INKUPROK' INIT VALUE PROG NAMES LINK TO

SPACE

SPACE

MVC LASTEYEC,=CL8'LASTCALL' INIT LAST CALL VARIABLES

MVC LASTPOIN,=CL4'POIN' LAST TABLE POINTER

MVC LASTSYSI,=CL4'LSYS' LAST SYSID

MVC LASTCALD,=CL8'LASTCALD' LAST CALLED PROGRAM NAME

MVC LASTCALR,=CL8'LASTCALR' LAST CALLER PROGRAM NAME

SPACE

DS ØH INIT ENDMARKER SUMM TABLE

LA R14,TABOCOMA BEGIN OF TABLE SUMM TABLE

A R14,=AL4(TABOCOME-TABOCOMA) ADDRESS TABLE END

MVC Ø(L'TABOCOME,R14),TABENDMA INIT ENDMARKER

SPACE

DS ØH INIT ENDMARKER LINK TABLE

LA R14,TABTCOMA BEGIN OF TABLE LINK TABLE

A R14,=AL4(TABTCOME-TABTCOMA) ADDRESS TABLE END

MVC Ø(L'TABTCOME,R14),TABENDMA INIT ENDMARKER

SPACE

MVC TABDISP,=A(TABTCOMA-TABEYECA) DISPLCMENT ZU TABTCOMA

SPACE

DS ØH INIT COLLECT-SUMM-TABLE

DS ØH

LA R1,TABOCOMA ADDRESS OF COLLECT-TABLE

USING OFTLTABL,R1

SPACE

CPEXI243 DS ØH INIT COLLECT-TABLE LOOP

MVC OSID,=CL4'OFTL' TABLE ID

MVC OSCALLED,KEMPTY STILL EMPTY CALLED PROGRAM

MVC OSCALLER,KEMPTY STILL EMPTY CALLING PROGRAM

ZAP OSCOUNT,=P'Ø' USAGE COUNT

ZAP OSTASKN,=P'Ø' TASKNUMBER

ZAP OSTIME,=P'Ø' EIBTIME

AH R1,=AL2(L'TABOCOMA) ADDRESS NEXT ENTRY


LA R14,TABOCOMA BEGIN OF TABLE

A R14,=AL4(TABOCOME-TABOCOMA) ADDRESS TABLES END

CLC Ø(L'TABOCOMA,R1),Ø(R14) END OF TABLE

BNE CPEXI243 NO

DROP R1

SPACE

CPEXI245 DS ØH INIT COLLECT-SUMM-TABLE

DS ØH WITH PREDEFINED PROGRAM NAMES

DS ØH

USING OFTLTABL,R1 COLLECT-SUMM-TABLE

USING DABONAME,R15 PROGRAM NAME-TABLE

LA R1,TABOCOMA ADDRESS OF COLLECT-TABLE

L R15,=A(TABONAMØ) ADDRESS OF PROGRAMNAMES

SPACE


MVC OSCALLED,DABONAM1 PREDEFINED NAME

SPACE

AH R1,=AL2(L'TABOCOMA) ADDRESS NEXT ENTRY

AH R15,=AL2(L'DABONAM1) ADDRESS NEXT ENTRY

SPACE

LA R14,TABONAMØ BEGIN OF TABLE NAME-TABLE

A R14,=AL4(TABONAMZ-TABONAMØ) ADDRESS TABLES END

CLC Ø(L'TABONAMØ,R15),Ø(R14) END OF TABLE

BE CPEXI249 YES

SPACE

LA R14,TABOCOMA BEGIN OF TABLE SUMM-TABLE

A R14,=AL4(TABOCOME-TABOCOMA) ADDRESS TABLES END

CLC Ø(L'TABOCOMA,R1),Ø(R14) END OF TABLE

BE CPEXI248 YES

SPACE

B CPEXI247 NO

SPACE


MVC MSGEISØ5(L'MSGTEØ2S),MSGTEØ2S

BAS R14,MSG

SPACE


SPACE

DROP R1

DROP R15

SPACE

DS ØH INIT COLLECT-LINK-TABLE

DS ØH

LA R9,TABTCOMA ADDRESS OF COLLECT-TABLE

USING COLLTABL,R9

SPACE

CPEXI293 DS ØH INIT COLLECT-TABLE LOOP

MVC DSSYSID,CWASYSID SYSID

MVC DSCALLED,KEMPTY STILL EMPTY CALLED PROGRAM

MVC DSCALLER,KEMPTY STILL EMPTY CALLING PROGRAM


MVC DSTASKN,=CL4'TANR' TASKNUMBER

MVC DSDATE,=CL4'DATE' DATE

MVC DSTIME,=CL4'TIME' TIME

AH R9,=AL2(L'TABTCOMA) ADDRESS NEXT ENTRY

LA R14,TABTCOMA BEGIN OF TABLE

A R14,=AL4(TABTCOME-TABTCOMA) ADDRESS TABLES END

CLC Ø(L'TABTCOMA,R9),Ø(R14) END OF TABLE

BNE CPEXI293 NO

SPACE

CPEXI295 DS ØH GATE FOR EVERY EXITS ENTRY

AP RFENR,=P'1' INCREMENT ENTRY COUNTER

SPACE

MVC TKBLAENT,=CL4'TIML' TIME THIS ENTRY

MVC TABLAENT,EIBTIME TIME THIS ENTRY

SPACE

L R14,UEPCRCA PREVIOUS EXITS RC

MVI PKEEXIRC,C'R' REMEMBER FOR DEBUGGING

MVC PREEXIRC,Ø(R14) REMEMBER FOR DEBUGGING

SPACE

LA R9,TABTCOMA ADDRESS OF COLLECT-TABLE

SPACE

* COLLECT THE PROGRAM LINK

SPACE

BAS R14,LINK_REQUEST GO TO COLLECT LINK REQUEST

SPACE

* RETURN TO CICS

RETURN DS ØH RETURN POINT

SPACE

RETURN99 DS ØH RETURN POINT

L R15,RETCODE FETCH RETURN CODE

DFHEIRET RCREG=15 RETURN TO CICS

EJECT

SPACE

Editor’s note: the code for this article will be concluded nextissue.

Hannes BojanCICS Systems Programmer (Germany) © Xephon 2004

Articles, or ideas for an article, should be e-mailed toTrevor Eddolls at [email protected]. A copy ofour Notes for Contributors is available atwww.xephon.com/nfc.

CICS news

Micro Focus has formed a partnership withUnilog to port mainframe applications, such asCICS, to the Microsoft Windows platform.This, they claim, will enable existing COBOLapplications to run at higher performance levelson low-cost platforms. Micro Focus sellsCOBOL application development anddeployment software, and Unilog is an ITsystems integrator.

To prove that the technology works, they havemigrated the time management system forEurocopter, a helicopter manufacturer based inGermany. Eurocopter were using a COBOL-based ZINA time management system on themainframe. They now run ZINA and CICS onPCs.

For further information contact:Micro Focus, 9420 Key West Avenue,Rockville, MD 20850, USA.Tel: (301) 838 5000.URL: http://www.microfocus.com/press/releases/20040505.asp.

* * *

NEON Enterprise Software, which developsCICS and IMS products allowing themanagement of enterprise data, has announcedadditional ways customers can benefit from itssimplified pricing model.

Streamlined pricing, based on broad levels ofCPU capacity, is one method. Most mainframesoftware companies price their products sothere are large price increases for each minorincrease in MIPS capacity.

The new simplified pricing structure allows forgrowth across broad spans of machine capacity.Now, a business can increase hardware MIPSwithout incurring software upgrade feescommon to the mainframe software industry.

For further information contact:NEON Systems, 14100 Southwest Freeway,Suite 500, Sugarland, TX 77478, USA.Tel: (281) 491 4200.URL: http://www.neonsys.com.

* * *

Wily Technology, which supplies J2EE portalmanagement solutions and claims to be first tomarket with software to manage integrationconnections to CICS and Tuxedo, has turned itsattention to business workflows.

The company is looking to fill the gap fordevelopers and architects looking for ways toget more visibility out of their J2EE-basedintegrated legacy networks.

To begin to address the problem, Wily is offeringWily 5, an upgraded application managementplatform that includes enhancements to itsIntroscope line of PowerPack probes andcomponents. The key Introscope’s upgrade isthe ability to monitor dataflows inside Javaadapters/connectors. In this latest release, Wily5 supports IBM’s Websphere BusinessIntegration adapters. Other features include:customizable dashboards to view availabilityand data/workflow information down togranular level in real time; additional systemsmanagement, component-based visibility, anative reporting system, fast-path user interfacenavigation, and integration with enterprisesecurity solutions.

For further information contact:Wily Technology, 8000 Marina Boulevard,Suite 700, Brisbane, CA 94005, USA.Tel: (415) 562 2000.URL: http://www.wilytech.com/solutions/index.html.

* * *

x xephon

cics sep 2004 - cbt · pdf fileseptember 2004 226 in this issue ... 10 redirecting output from...

Documents