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

problem with db2 drda

100 views
Skip to first unread message

Alberto Baljak

unread,
Dec 21, 2016, 6:00:03 AM12/21/16
to

Hi everybody

First, sorry for my bad english, I’m from Italy.

I have a strange problem with db2 e drda. This is my scenario:

zVse 5.2

DB2 7.5

DRDA on Db2

Cics connected to db2 by CIRB

Batch with sql cobol programs

 

We use DRDA to let servers perform query on our db2 on zvse.

The problem is the following: when I have a cics conversational transaction or when I use ISQL from Cics with query having multiple answer screens or when I have a long batch program using db2, the DRDA seems to block and the servers cannot perform any query: the tasks on servers are in waiting state. When the transactions or the isql query or the batch program normally ends then DRDA resumes to work and the query on servers can make their job.

My question is: has anyone experienced this problem? Can anyone try to duplicate my scenario to see the behavior of his DRDA?

 

I hope I wrote all correctly

 

Thanks

 

Alberto Baljak

 

 

Kevin Corkery

unread,
Dec 21, 2016, 9:55:24 AM12/21/16
to

Alberto …

 

Your problem is well communicated.  I don’t know anything about DB2 but would suggest that some resource controlling connection to the database has been exhausted.  All of the situations you mention would seem to hold a resource for a long period (hint: conversational CICS transactions).  I’d look for something along those lines.  Good luck.

 

 

Kevin P Corkery

Independent Consultant

Voorhees, New Jersey

Mike Riggs

unread,
Dec 21, 2016, 10:09:31 AM12/21/16
to

Alberto,

 

We saw similar issues when running DB2 in zVSE.  The number of connections allocated could be an issue. We also saw severe table locking when queries (Browse) were executing due to not having the proper ‘with ur’ clause stated.

 

Mike Riggs

SCV/OES

Baljak Alberto

unread,
Dec 21, 2016, 10:48:24 AM12/21/16
to

Thanks Kevin
the only resource I can see involved is the user agent of db2. This is
the response of SHOW COMMAND when the problem rises:

FA 0010 0 Remote users are active.
FA 0010 0 Remote users are waiting.
FA 0010 5 Remote users are inactive.
FA 0010 8 Agents are available.
FA 0010 7 Remote connections are available.
As you can see I have 8 agents available, no remote users active and
no remote users waiting because DRDA seemms to be freezed.

Alberto Baljak

On Wed, 21 Dec 2016 14:55:15 +0000
Kevin Corkery <kcor...@live.com> wrote:
> Alberto ...
_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu
https://lists.lehigh.edu/mailman/listinfo/vse-l

Baljak Alberto

unread,
Dec 21, 2016, 10:52:24 AM12/21/16
to
Thanks Mike
no problem with connections as you can see in my preceeding mail.
I also thougth about lock problem BUT:
1) the problem rises with every table I use on mainfram task
2) the problem rises when i use one table on mainframe a different
table on server
3) the SHOW LOCK command doesn't show lock contention.

Alberto Baljak


On Wed, 21 Dec 2016 15:09:18 +0000
Mike Riggs <mri...@vacourts.gov> wrote:
> Alberto,
>
> We saw similar issues when running DB2 in zVSE. The number of
>connections allocated could be an issue. We also saw severe table
>locking when queries (Browse) were executing due to not having the
>proper 'with ur' clause stated.
>
> Mike Riggs
> SCV/OES
>From: VSE-L
>[mailto:vse-l-bounces+mriggs=vacour...@lists.lehigh.edu] On Behalf
>Of Kevin Corkery
> Sent: Wednesday, December 21, 2016 9:55 AM
> To: 'VSE Discussion List' <vs...@lists.lehigh.edu>
> Subject: RE: problem with db2 drda
>
> Alberto ...

Duerbusch, Tom

unread,
Dec 21, 2016, 12:42:14 PM12/21/16
to
 I believe that the default in ISQL is Repeatable Read.  This will lock your pages (by default) until you end the ISQL query.  

Also, try doing a SHOW ACTIVE and SHOW LOCK ACTIVE to see what you might be hung on.

Tom Duerbusch
THD Consulting

_______________________________________________
VSE-L mailing list
VS...@lists.lehigh.edu
https://lists.lehigh.edu/mailman/listinfo/vse-l




--
 

Baljak Alberto

unread,
Dec 21, 2016, 3:15:13 PM12/21/16
to

Hi Tom
SHOW LOCK doesn't show any lock contention. We can work with one table
on mainframe and a different table in the server with different
dbspace and DRDA always hang. The hearth of problem seems to be one:
when there is an user agent active in db2 then DRDA is blocked, when
the user agent became free then DRDA works.

Alberto Baljak

Duerbusch, Tom

unread,
Dec 21, 2016, 3:37:04 PM12/21/16
to
Can you send the INITPARM?

NCUSERS is the only thing I can think of that will single thread DB2.
Mine is set for 21 concurrent users.

Tom Duerbusch
THD Consulting
--
 

Alberto Baljak

unread,
Dec 22, 2016, 1:47:33 AM12/22/16
to

Here is my INITPARM:

10 SHOW INITPARM                                                    

FA 0010                                                             

FA 0010 Initialization parameters at 2016-12-22  07:43:48           

FA 0010                                                             

FA 0010 DSPLYDEV L             DUALLOG  N             ALTLOG   N       07:

FA 0010 RMTUSERS 12            TCPDISPB 50            SYNCPNT  Y       07:

FA 0010 ACCOUNT  D             DUMPTYPE F             LOGMODE  Y       07:

FA 0010 STARTUP  W             SYSMODE  M             EXTEND   N       07:

FA 0010 CHARNAME INTERNATIONAL DBNAME   SQLFM                          07:

FA 0010 APPLID   SYSARI0C      PARMID   OPTDRDA       TRACDBSS 00000000000

FA 0010 TRACDRRM 0000          TRACDSC  00            TRACRDS  0000000 07:

FA 0010 TRACWUM  0             TRACCONV 0             TRACSTG  0       07:

FA 0010 TRACEBUF 0             ARCHPCT  80            CHKINTVL 300     07:

FA 0010 NCSCANS  30            NCUSERS  17            NDIRBUF  1500    07:

FA 0010 NLRBS    20000         NLRBU    19000         NPACKAGE 220     07:

FA 0010 NPACKPCT 65            NPAGBUF  3500          SLOGCUSH 90      07:

FA 0010 SOSLEVEL 10            DISPBIAS 7             LTIMEOUT 5       07:

FA 0010 DSPSTATS 01            SECALVER N             SECTYPE  DB2     07:

FA 0010 TCPPORT  5677          IPADDR   10.10.1.100                    07:

FA 0010 HOST     VSE_LISTINI.IT                       PTIMEOUT 180     07:

FA 0010 PROCMXAB 0             DB2LEVEL 7.5.0         TAPEMGR  Y       07:

FA 0010 ARCHTAPE UNL           TCPMAXRT 30            TCPRETRY Y       07:

FA 0010 PWENCRYP Y             LETRAP   OFF                            07:

FA 0010                                                                07:

FA 0010 ARI0065I Operator command processing is complete.              07:

 

I have 12 as remote users but in my problem I have only one local user and only one remote user!

I have 17 concurrent users (NCUSERS) and I have a CIRB to cics with 8 users.

 

Alberto Baljak

 

Da: VSE-L [mailto:vse-l-bounces+alberto.baljak=sefi...@lists.lehigh.edu] Per conto di Duerbusch, Tom
Inviato: mercoledì 21 dicembre 2016 21:37
A: VSE Discussion List
Oggetto: Re: problem with db2 drda

Duerbusch, Tom

unread,
Dec 23, 2016, 1:53:44 PM12/23/16
to
NCUSERS doesn't look like it is a problem.

NCUSERS = 17
minus
CIRBs 8 dedicated users (this includes ISQL users)
equals
9 available

These 9 are available for batch and/or DRDA.

RMTUSERS = 12 just defines the size of a queue for remote users.  Any more remote users trying to connect will be rejected.  This queue will feed the remaining 9 agents.

SHOW CONNECT ALL will show all the agents, of the 17, that are currently active.  It should always show the 8 active agents that you have tied up via the CIRB transaction.

I don't see what is single threading your DB2 system.

In my case, I have two CICS systems connecting in.
No more than 8 batch partitions that may be using DB2.
DRDA from 75 DB2 Connect licensed users.

Except for someone, occasionally locking the catalog, they all get along fine.

Tom Duerbusch
THD Consulting

Alberto Baljak

unread,
Jan 3, 2017, 2:35:39 AM1/3/17
to

Hi Tom

Can you try this on your system? Use ISQL with a query that have more screen responses, during a screen response launch a query on a pc using vse db2 tables and look about its behavior. In this way I can understand if the problem is only on my system or it’s a drda on vse problem.

Thanks

Alberto Baljak

 

Da: VSE-L [mailto:vse-l-bounces+alberto.baljak=sefi...@lists.lehigh.edu] Per conto di Duerbusch, Tom

Inviato: venerdì 23 dicembre 2016 19:54

Duerbusch, Tom

unread,
Jan 3, 2017, 1:34:48 PM1/3/17
to
I went into ISQL and did a "select * from tablename".
I retrieved 3 screens of the 50+ that would be returned.
I then went into the DB2 CLP (command line processor).
I did a "select  count(*) from another_tablename".
It came back with a count of 700,000 rows.
I then "exit" the ISQL session.

No performance (or other) type of problems.

Tom Duerbusch
THD Consulting




Alberto Baljak

unread,
Jan 4, 2017, 1:48:19 AM1/4/17
to

Thanks Tom

 

Alberto Baljak

 

Da: VSE-L [mailto:vse-l-bounces+alberto.baljak=sefi...@lists.lehigh.edu] Per conto di Duerbusch, Tom
Inviato: martedì 3 gennaio 2017 19:35

Alberto Baljak

unread,
Jan 12, 2017, 5:55:04 AM1/12/17
to

Hi Tom

I opened a problem with IBM but they are very far to a solution.

I made a db2 trace and I noted that the interface db2-tcpip doesn’t work when there is a db2 user agent connected to a mainframe task (conversational transaction or isql or batch program).

When the user agent closes then the interface db2-tcpip immediately start to work.

My environment is:

zVse 5.2

DB2 7.5

TCPIP from CSI 1.5F

DRDA server support with EZA TCP/IP interface created by ARIS752Z

 

Can you tell me your environment to see the difference and try to understand where is my problem?

 

Thanks

 

Alberto Baljak

 

 

Da: VSE-L [mailto:vse-l-bounces+alberto.baljak=sefi...@lists.lehigh.edu] Per conto di Duerbusch, Tom


Inviato: martedì 3 gennaio 2017 19:35

Alberto Baljak

unread,
Jan 17, 2017, 3:06:51 AM1/17/17
to

Problem solved!

I chanced the initial parameter TCPDISPB from 50 to 1 and all is working perfectly.

Thanks everybody

 

Alberto Baljak

 

Da: VSE-L [mailto:vse-l-bounces+alberto.baljak=sefi...@lists.lehigh.edu] Per conto di Duerbusch, Tom


Inviato: martedì 3 gennaio 2017 19:35

0 new messages