System abends and User abends :

If an abended program is analysed in JMR, there will be some

informations displayed in the beginning, which looks -

T14410 BATCHTSO STEP08 - ABEND=S000 U0100 REASON=00000000

The abending step is followed by system abend code and user abend
code. A job abends due to one of the above two (both can not cause abend
together..) Hence when there is a valid system abend code is seen, the user
abend code will be U0000 and vice-versa.

System abends :
System abends are caused due to some system related problem
such as Problem with the allocation of space for an output/sort work
file(S*37), when divisor in compute statement get value 0 (SOCB), when
program tried to access non-executable value in memory location(SOC7)
and also when time out for jobs (S322) or when job is cancelled by system
automatically or by operations(S22).

User Abends :
User abends are the which are purposely expected by the
programmer/user on some specific conditions spaced by the job. This may
be due to the problem with the data, source code or application. All the
negative sqlcodes and all the user abend codes which are going to be
discussed here will come under user abends.

Solving abends with User Abend codes :

Index :
1.U0020
2.U0022
3.U0023
4.U0061
5.U0064
6.U0066
7.U0068
8.U0070
9.U0099
10.U0171
 11.U3303
12.S*37

* For the abends which involve files, there are some abending info
displayed in the JMR, in the statements starting IEC****
So search for IEC in JMR.

________________________________________________________________________

U0020 :

Ref: DSD T0610804 on 99/04/20

U0020 abend is due to some problem with Scheduler CA7 and not due to the
application program.

Easy ways to get information about this abend is to search for CMT (Catalog
ManagemenT) first and also, see in JMRSEP2.

Messages usually left at the top, bottom or in JMRSEP2.

T0610804 RMS@2X CA07RMS - ABEND=S000 U0020 REASON=00000000

:
:
:
U11-109 * PROC-STEP=STEP01 STEP=ALLOC POSTED WITH CC=0000
U11-031 * PROC-STEP=STEP02 STEP=BATCHTSO
U11-051 ON RESTART - GDG DATA SET ADDED - DDNAME=SYSOUT
DSN INDEX=T006.T0610804.MDLCAL.ACR

DSN = T006.T0610804.MDLCAL.ACR
U11-042 CANNOT RESTART - CMT ENTRY INVALID
U11-022 VERIF CODE = 24 PROC/STEP = STEP02 /BATCHTSO DDNAME = SYSOUT
END OF REPORT 01 - TOTAL ITEMS LISTED= 8

There may be messages like CMT NOT CORRECT and even Jcl errors like DATASET NOT
FOUND.

Soln : Search for the dataset T006.T0610804.MDLCAL.ACR using 3.4 option. And decide
whether to create new dataset /catalog the dataset.

U0022 & U0023 :

Ref: T15420 in Mervyns on 99/4/25

Jobs abend with U0022 for vareities of errors in the application.

T15420 STEP03 - ABEND=S000 U0022 REASON=00000000

:
:
:
JMRSEP6
PREVIOUS SATURDAY 1999-04-24 / 99114, PREVIOUS WEEK = 3
RECORD COUNT FOR PART 01: 010168223
RECORD COUNT FOR PART 02: 003759418
RECORD COUNT FOR PART 03: 014022616
RECORD COUNT FOR PART 04: 007882696
CURRENT DEPT :0990
CURRENT CLASS :0004
CURRENT ITEM :0493
CURRENT STORE :0060

PRIOR DEPT :0990

PRIOR CLASS :0004
PRIOR ITEM :0493
PRIOR STORE :0060

KEYS OUT OF SEQUENCE

Soln:Different Solution is given after analysing the job.For the above job, the file sequence need
to be corrected. Hence, sorting was done and the job was run.

All U006* abends are due to some problem with sort.

U0061 :

Ref: T2670502 in Mervyns on 99/03/04

This abend is due to some problem with the output sort file.

********************************* Top of Data **********************************

******************************************************************************
**
* JOBLOG MANAGEMENT AND RETRIEVAL - VERSION 4.5 *
* DATE - THU 04 MAR 99 *
* RETRIEVE JOB#15685 JOBNAME T2670502 *
******************************************************************************
**
JMR170W ** DATE GIVEN COULD NOT BE FOUND IN MASTER FILE
JMR140W ** NO DATA AVAILABLE WHICH SATISFIES RETRIEVAL CRITERIA
******************************** Bottom of Data ********************************

Soln: The JCL was analysed .In this job, since the output file is new(ly created,) the job is
restarted.

U0064 :

Ref: T13311 in TARGET on 99/05/01

T13311 RMS@2X CA07RMS - ABEND=S000 U0064 REASON=00000

:
:
:
* PROC-STEP=STEP04 STEP=SORT
LOCATE UNSUCCESSFUL - DSN = T013.T13311.MTHLY.LC.BOB.TAR(+001)
**WARNING** - DO NOT ATTEMPT TO RESTART - CMT NOT CORRECT
* PROC-STEP=STEP05 STEP=SORT
GDG IN 'P' PROCESSING - DSN=T013.T13311.MTHLY.LC.AMEND.BOA.G0043V00
* PROC-STEP=STEP06 STEP=SORT
GDG IN 'P' PROCESSING - DSN=T013.T13311.MTHLY.LC.AMEND.NW.G0043V00
* PROC-STEP=STEP07 STEP=SORT
LOCATE UNSUCCESSFUL - DSN = T013.T13311.MTHLY.LC.AMEND.BOB.TAR(+001)
**WARNING** - DO NOT ATTEMPT TO RESTART - CMT NOT CORRECT
:
:

Soln: In this case, the sorting dataset is not found. So, find the file which was missing/ not
created.

______________________________________________________________________________

U0066 :

Ref: T46004 in Mervyns on 99/04/25

These abends are due to the sort proc which could not access the volume serial properly.

T46004 SORT STEP01 - ABEND=S000 U0066 REASON=00000000

:
:
:
SYNCSORT 3.6FN TPF5 US PATENTS: 4210961,5117495, OTHER PAT. PEND. (C) SYNCS
OS/390 2.5.0. CPU MODEL 9672
SYSIN :
SORT FIELDS=(1,13,A,17,7,A,54,5,A),FORMAT=BI
WER164B 15,960K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 0 BYTES RESERVE REQUESTED, 15,552K BYTES USED
WER146B 12K BYTES OF EMERGENCY SPACE ALLOCATED
WER108I SORTIN : RECFM=FB ; LRECL= 65; BLKSIZE= 32760
WER110I SORTOUT : RECFM=FB ; LRECL= 65; BLKSIZE= 32760
WER410B 14,932K BYTES OF VIRTUAL STORAGE AVAILABLE ABOVE THE 16MEG LINE,
WER410B 0 BYTES RESERVE REQUESTED, 14,932K BYTES USED
WER036B G=167379,B=117,BIAS=99
WER162B 138,000 PREALLOCATED SORTWORK TRACKS, 90,000 DYNAMICALLY
ALLOCATED,
WER162B 286,350 ACQUIRED IN 460 SECONDARY EXTENTS, 0 RELEASED, TOTAL OF
514
WER046A SORT CAPACITY EXCEEDED
WER066A APROX RCD CNT 344683476
WER449I SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE

Soln: For this case, the sort work area should be increased and the job should be submitted
again.

U0068 :

Ref: T15206 in Mervyns on 99/05/02

T15206 SORT STEP01 - ABEND=S000 U0068 REASON=00000000

:
:
:
SYNCSORT 3.6FN TPF5 US PATENTS: 4210961,5117495, OTHER PAT. PEND.
OS/390 2.5.0. CPU MODEL
SYSIN :
MERGE FIELDS=(1,8,BI,A)
WER164B 6,004K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 0 BYTES RESERVE REQUESTED, 1,029,928 BYTES USED
WER146B 12K BYTES OF EMERGENCY SPACE ALLOCATED
WER109I MERGE INPUT : TYPE=F; LRECL= 34
WER110I SORTOUT : RECFM=FB ; LRECL= 34; BLKSIZE= 32742
WER068A OUT OF SEQ SORTIN22 , BLOCK 804
WER211B SYNCSMF CALLED BY SYNCSORT; RC=0000
WER449I SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE

From JCL,

44 //SORTIN22 DD DSN=T015.T15205V.STORE.HIST,
// DISP=(OLD,DELETE,KEEP)
******************************* Bottom of Data **********************
Soln: In this case, the sequence was not in order; so the dsn T015.T15205V.STORE.HIST is to be
sorted and the job should be rerun.

U0070 :

Ref: T32359

Jobs abended with U0070, leaves displays from program; Hence it can be solved by analysing
the application program.

U0099 :

Ref : T37240 in Target on 05/04/99

PGM/PROC : IDCAMS
STEP NAME : STEP96

APPLICATION NAME: POM 3D DCI

DESCRIPTION OF PROBLEM:
The Job abended in step96 with U099. The step96 deletes the VSAM dataset
"UCCICS01.T037.T37241.MQMSG.BATCNTL" and creates it again. Since there
was contention, the dataset couldnt be created and hence the job abended
with U099.

DESCRIPTION OF RESOLUTION:
Restarted the job from step96. It went thru fine.

U0171 :

From IS-MDS-ABEND-INFO by Reetisnigdha.Mishra

Ref: JOB : T01010 in Target on 98/10/26

PGM/PROC : sort
STEP NAME : step12sl

The different versions of the GDG file used as input had different
record lengths.Some had 88 ( which were all blank ) and other has 82.
RESOLUTION:
I checked the following steps and the case was same with the steps,
step13sl and step14sl. I ran the fil job T13filjk to delete the empty
versions of the dataset which had bad record length (the two record lengths are 88 and 82.)
and restarted the jobs.
.
The job ran fine.

Soln: For these abends, program need to be analysed.

U3303 :

Ref: T15130 in Mervyns on 99/04/26

U3303 is definitely due to problem with IMS database ie Database not available for
access.IMS database problem may be due to the db locked or when IMS region down, it might be
tried to be accessed.

When the step involvs IMSBMP, IMS should be up and while running DLI(T96), IMS
should be down.

In SDSF output, see for IM* (ie PRE IM*) for finding out, the status of IMS region.
(IMSPCTL - Prod ; IMSTCTL - Test ) In that, search for the jobname/database and find the
IMS database accessed by the job.

Then, contact Ospec and DBA further regarding this.