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

Batch Job Abend

523 views
Skip to first unread message

Harmeson, Steve

unread,
Oct 8, 2002, 1:06:28 PM10/8/02
to
This looks look a problem with your steplib concat. IDMSDMCL is the default
global DMCL so the job can't find your global DMCL. How are these jobs
submitted? I agree with Chris, there might be some other error your getting,
like 1473, not enough erus defined. Also I would increase your XA REENTRANT
pool quite a bit, you should have plenty of storage, here is my XA def's:
XA PROGRAM POOL IS 5000
XA REENTRANT POOL IS 40000
XA STORAGE POOL IS 15000

Steve Harmeson

-----Original Message-----ed.
From: Schepers, John [mailto:jsch...@SEISTL.COM]
Sent: Tuesday, October 08, 2002 11:27 AM
To: IDM...@LISTSERV.IUASSN.COM
Subject:

I have a situation with IDMS batch jobs abending u3134. It only seems to
happen when we have a heavy schedule with jobs using IDMS. I am not a
IDMS/DBA person but am left with the task of resolving the problem, we are
running IDMS 15.0 sp0.
When we cut back on jobs all runs good. The messages I get from the batch
jobs start out like this

+PFS00 DB347019 IDMSDMCL module not found
@PFS00 DC208001 IDMS job abending with abend code 5004
@PFS00 DC208001 #ABEND from Module IDMSBLDR at Location 0A003A20 Offset
008150

The manual says for the first message that the module could not be found or
there is not sufficient room in the (XA) program pool. I increased the xa
program pool by 500k, but the displays look like it might be XA REENT.
DIS ALL PROGRAM POOLS
,
Pool Address Size Space HWM Prog Prog
Loads
Alloc in pool in use to
pool
PROGRAM 00094000 400K 0K 0K 0 0
0
REENT 000F8000 1658K 258K 258K 16 0
16
XA PROG 0A1B9000 2000K 32K 32K 1 0
1
XA REENT 0A3AD000 3685K 3617K 3617K 177 12
177

Our dmcl is called GLBLDMCL, I cant find a IDMSDMCL, I think this is the
default name for dmcl?

This problem just started about a week ago and is intermittent, I increased
the xa prog yesterday and we ran ok last night, but I don't feel
comfortable.

Anybody seen this or could point me to some material which could shed some
light on this for me.

Thanks
John

Linda Campbell

unread,
Oct 8, 2002, 2:16:50 PM10/8/02
to
This issue is an interesting one and we have been having the same problem
ONLY since we went to Release 15.0. The message stating that it is trying
to load the DMCL is misleading because there should never be a reason to
load the global DMCL into a CV mode batch jobs address space. I think Chris
had it when he said that the batch program couldn't connect or lost contact
with the CV and was trying to create a mini-CV (like local mode) in order to
obtain a message from the message area. The few times we've actually caught
this was when a program was in a loop inside the CV, which indicates a
timeout issue (external wait?). All of this sounds vaguely familiar as a
problem I encountered in a previous release, maybe 12.0 and turned out to be
a problem with the communication between CV and batch address spaces and it
was fixed by CA. I do not remember the details unfortunately.

I have a couple of questions/thoughts on this......

1) Why did this only start happening in R15 and didn't happen to us in R14?
2) Where did it get the 5004 message if it can't access the message area to
get the right message? Is 5004 hardcoded in one of the system modules?
3) Is the solution to this adding a DD statement for the message area into
all CV mode batch jobs (what a pain in the #$@ that would be)?
4) This just doesn't sound right! Isn't IDMS is supposed to handle this
more gracefully and give the program an 0069 or something! From what I
remember, that's what it used to do.
5) Is this a problem with not enough ECBs defined to IDMS or is it losing
ECBs somehow?
6) Does RHDCNP3S have some problems in R15?
7) What am I missing?

I am sure that better minds than mine have the answers to this.

Thanks.
Linda Campbell
Informatix, Inc.

Schepers, John

unread,
Oct 8, 2002, 3:40:37 PM10/8/02
to
We are running local.
These jobs do complete after a restart and a reduction of the # of jobs
running?
John

-----Original Message-----
From: Harmeson, Steve [mailto:harme...@NAPTHEON.COM]
Sent: Tuesday, October 08, 2002 11:57 AM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: Batch Job Abend


This looks look a problem with your steplib concat. IDMSDMCL is the default
global DMCL so the job can't find your global DMCL. How are these jobs
submitted? I agree with Chris, there might be some other error your getting,
like 1473, not enough erus defined. Also I would increase your XA REENTRANT
pool quite a bit, you should have plenty of storage, here is my XA def's:
XA PROGRAM POOL IS 5000
XA REENTRANT POOL IS 40000
XA STORAGE POOL IS 15000

Steve Harmeson

-----Original Message-----ed.

William M. Allen, Jr.

unread,
Oct 8, 2002, 3:54:02 PM10/8/02
to
Hello John:

What about the CHKUSER setting in the sysgen? For example if this is set to 5
then only five batch jobs could execute at the same time, any additional
batch jobs would wait and then be subject to the timeouts as previously
mentioned.

Bill Allen
ARCH Consulting Associates, LTD.

Linda Campbell

unread,
Oct 8, 2002, 4:15:59 PM10/8/02
to
Bill,

CHKUSER no longer limits the number of ERUs that can execute in R15. See
APAR #: QI22251 in TCC.

Linda Campbell


-----Original Message-----
From: IDMS Public Discussion Forum [mailto:IDM...@LISTSERV.IUASSN.COM]On
Behalf Of William M. Allen, Jr.
Sent: Tuesday, October 08, 2002 12:50 PM
To: IDM...@LISTSERV.IUASSN.COM
Subject: Re: Batch Job Abend

van de Ven, Peter

unread,
Oct 9, 2002, 3:14:09 AM10/9/02
to
When you are running all the jobs in local mode you probabily run out of
space below the 16 M. The mini-cv in the new release take more M 's .

Regards,
Peter van de Ven Atos Origin

tel: +31(0) 40 2142211 mobile: +31(0)6 22567218
fax: +31(0) 402144423
E-mail: Peter.v...@atosorigin.com


> -----Original Message-----
> From: Schepers, John [mailto:jsch...@SEISTL.COM]

> Sent: Tuesday, October 08, 2002 9:37 PM
> To: IDM...@LISTSERV.IUASSN.COM
> Subject: Re: Batch Job Abend
>
>

> We are running local.
> These jobs do complete after a restart and a reduction of the
> # of jobs
> running?
> John
> -----Original Message-----
> From: Harmeson, Steve [mailto:harme...@NAPTHEON.COM]

> Sent: Tuesday, October 08, 2002 11:57 AM
> To: IDM...@LISTSERV.IUASSN.COM
> Subject: Re: Batch Job Abend
>
>

Leo Gerritsen

unread,
Oct 9, 2002, 11:21:39 AM10/9/02
to
Linda,

I can answer only this :

3) Is the solution to this adding a DD statement for the message area into
all CV mode batch jobs (what a pain in the #$@ that would be)?

The communication fails, the originator part (in the batch region) wants to
giive you a meaning message. To do that it opens the message dictionary
from the hardcoded IDMSDMCL. Yes you can change that, but you will
have to apply an usermod (then you will have an alternative name), if you
have different DMCL names in each CV you either apply the fix < outside >
SMP for each cv or simply allow for an ALIAS (each individual DMCL, in
ist own loadlib will have an alias for IDMSDMCL). I prefer the last method,
because this happens only occasionally.

4) This just doesn't sound right! Isn't IDMS is supposed to handle this
more gracefully and give the program an 0069 or something! From what I
remember, that's what it used to do.

It will when you apply above fix.

I am very interested in the answers of own distinguished collegue DBA's
in the field.

Kind regards,

Leo Gerritsen.

----- Original Message -----
From: "Linda Campbell" <linda.c...@INFORMATIXINC.COM>
To: <IDM...@LISTSERV.IUASSN.COM>
Sent: Tuesday, October 08, 2002 8:08 PM
Subject: Re: Batch Job Abend

Linda Campbell

unread,
Oct 23, 2002, 2:19:26 PM10/23/02
to
Got some answers to this question at IUA, so am passing them
along...........

I was remembering the way 10.2 handled batch programs losing contact with
IDMS. As of Release 12.0, when a batch program is terminated and loses
touch with the CV (due to a timeout, bind failure, etc), it reverts to a
mini CV (like local mode) environment in the batch address space. In order
to return a meaningful message, it has to load the global DMCL to obtain the
info to read the message area. There were two different problems reported
on the list with this, both of which returned a 5004 abend. One problem was
the inability to find the DMCL load module and the other was the inability
to load the DMCL module it had found due to insufficient region. Our
problem was insufficient region.

The only remaining question is why we started having this problem only in
R15. I am opening an issue with CA to see if they can give me the answer.
The most reasonable explanation so far is that some modules grew in size and
we were close to the edge anyhow. Our default region is 1M and many of our
jobs did not have a region parm. If I get a different answer from CA on
this, I'll post it.

Linda Campbell

0 new messages