Language Environment for z/VSE

匹配项： language

System Dumps for LE z/VSE CICS Abend

LEzVSE 标签： dump environment system language cics 1,620 次访问

After the earlier topic on obtaining a z/VSE system dump from an LE application failure, its worth discussing
the same functionality, but in a more CICS specific direction. It is possible to use the CICS/TS dump CEMT
commands to get CICS to produce a system dump for specific CICS and LE z/VSE abend codes. There are
times when these are useful and can be a good tool for analysing a failure. But with the more technically
difficult LE abends that may occur they can be taken by CICS too late and be missing vital information
that is needed for a complete analysis.

Since the elimination of 4083 abends under CICS (via APAR PQ15103 in LE/VSE 1.4.0) the main abend codes
that may now occur under CICS that are application failure related are 4038 or 4088 abends. With the
4038 abend the majority of times there will be related messages issued in the CICS output log that
indicate what language run-time issue occurred which can then be corrected and the application
re-executed. With a 4088 abend there will be no such messages. This means that identifying the
language issue or application problem that is responsible for the abend can be a lot more difficult
and involved. Combine this situation with no LE dump produced and most times only a CICS transaction dump
to use for analysis.

Often the most useful dumps for application analysis are those taken as close as possible (with respect
to time) to when the failure occurred. This minimises the modification of important storage areas by
internal abend processing meaning data available in the dump is more reflective of what happened at the
time of the abend rather than partially descriptive of the abend situation and what processing occurred
afterwards.

To aid in gathering both an early and system dump for these LE abends under CICS, a modified version
of the standard CEEUOPT is provided that can be included into applications that are experiencing such
abends under CICS. This modified version is CEEXUOPT.Z and it is available in your LE z/VSE installation
library - usually PRD2.SCEEBASE.

To use this member you need to tailor it to fit your applications specific abend situation. This will
mean changing the ABPERC value to one that fits the abend being experienced by your application. It is
very important that none of the other settings are changed unless you have been instructed to do so by
IBM service personnel. Once you have set the ABPERC option to what you need you and set the target output
library (marked as "yourlib.sublib") you can then tailor the other JCL statements as required for your
specific z/VSE system. Then submit for execution. Once complete a CEEUOPT.OBJ member will be created in
the library you specified.

Next we need to included this special "debugging" version of the CEEUOPT.OBJ into the application that
is experiencing the abend under CICS. To do this you need to at least re-link (a re-complile can be done
but is not needed) the application with the statement "INCLUDE CEEUOPT" as a linkedit JCL directive.
Ensure that the library you stored the debugging version is ahead of the LE z/VSE installation library
(PRD2.SCEEBASE) in any LIBDEF object search chain otherwise the default CEEUOPT.OBJ will be included
and no system dump will be produced. If you use the linkeditor MAP directive you can review the output
and ensure that the CEEUOPT being included was indeed taken from the correct library.

Now that the application has been re-linkedited with the customized version of the debugging CEEUOPT
we need to ensure CICS uses the updated version. You can accomplish this any way you see fit. One
simple way is to use the CEMT S PROG command with the PHASEIN option. If no previous CEEUOPT had
been included in your application you should see an increase in the size reported by CICS when the
CEMT command is complete.

Now you are ready to run the application again. There is no need to set any CICS dump setting to
capture a system dump. Instead LE z/VSE will perform this function when the specified LE abend
occurs again. The combination of options set in the debugging version of the CEEUOPT gives special
instructions to the LE CICS abend interface to produce a z/VSE system dump when the abend specified
on the ABPERC option matches the abend being issued. This allows LE to take the system dump early
in the abend processing stage to minimise the changes to storage from when the abend occurred.
Using the CICS functions would still produce a system dump however this would be taken by CICS
long after both LE and CICS have finished their respective abend processing.

To control the dump produced you can set in your CICS JCL the // OPTION statements that most reflect
where and what level of information you want to be included in the dump produced.

For those applications where it is not possible to re-link with the debugging CEEUOPT version, another
option is available to get a system dump taken early for LE abend codes. Instead you can use the
supplied CLER CICS transaction to dynamically set the same options as included in the CEEXUOPT.Z
member in the CICS system your application is experiencing the abend. Set the ABPERC abend code
just as you would in the CEEXUOPT.Z member and then also change each of the other listed run-time
options from the CEEXUOPT.Z member in the CLER screen. When complete make sure you save the

options.

After you have done that you can run the ROPC CICS transaction to get a console report of the current
LE CICS run-time options. You should see all your over-rides set as per the same run-time options
shown in the CEEXUOPT.Z member.

Once everything is correct you can run the abending application and if the matching abend occurs again
LE will request a z/VSE system dump to be produced.

You may notice in the LE z/VSE documentation that it states the ABPERC run-time option is not
supported under CICS. So why use it here?
This is true and is still correct even when using the CEEXUOPT or the CLER run-time option
transaction. In this situation the ABPERC run-time options behaviour is not used or
supported under CICS. Instead the ABPERC option is used simply as a method of telling LE what
abend code to "watch" for and when a match occurs when the other run-time option settings
have also been made to take a system dump.

由 LEzVSE 于修改

HLASM and Language Environment Callable Services

LEzVSE 标签： services callable envrionment hlasm assembler language 2,159 次访问

For this entry I thought I would discuss the use of the vast array of language environment callable services within LE-enabled HLASM routines.

Even though the manuals often only show examples of how to use these callable services with COBOL, C, or PL/1 - so long as the linkage and parameter configurations are honoured - these callable services can also be used by LE-enabled assembler routines.

Just as required with use of a callable service by a High Level Language (HLL) program, an LE-enabled assembler routine can setup the services parameters and then call the applicable service routine as described in the LE Programming Reference Guide.

This means all of the date/time, condition handling, memory management and messaging services can all be utilised within an LE-enabled assembler routine. The reason the services are restricted to LE-enabled assembler is that they require a language environment to be present to support the functions and services they use internally.

So what is an LE-enabled assembler routine? Simply put it is an HLASM routine that uses the provided LE macros to establish an environment, restricts use of general purpose registers 12 and 13 (for CAA and DSA addressability), sets up a dynamic storage area on the stack and identifies itself in an LE-conforming manner via the PPA macro. Each of the HLL compilers include a language-specific version of a PPA so any assembler routine needs to include one as well.

So by using the CEEENTRY/CEETERM/CEEDSA/CEECAA and CEEPPA macros in your assembler routine (which will provide all the required setup for your HLASM routine) you effectively make it LE-enabled. Then you can exploit any number of the available LE callable services within your assembler routine to provide date/time formatting, manipulation/calculations, storage management along with condition handling features. All without needing to use low-level operating system services. And each of these services would be very similar to how they would be used within an HLL program. Where it is documented as so and applicable to the service being invoked, the service can be utilised in either the BATCH or CICS environments.

By making your HLASM routines LE-enabled you then expand the capabilities of your HLL programs by now enabling your HLASM routines to be exploited and utilised from within a language environment HLL program.

由 LEzVSE 于修改

“博客条目”的订阅源

博客