HP3000-L Archives

May 1998, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Hermann Drdxler <[log in to unmask]>
Reply To:
Hermann Drdxler <[log in to unmask]>
Date:
Fri, 15 May 1998 03:53:02 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
May be this answer is stupid because you have done all of this already,
anyway:

I think the most importand is to find out why the job or session hangs. Two
ideas:

1. With GLANCE you could do a TRACE of the hanging process which should tell
you what it is doing (or trying to do).

2. If you are not using to much different applications you could write a
smal program to add a debug function to your cobol sources. For example,
place a debug statement at the begin of a section, at goto markers, before
and after locking, io's, and so on. The debug statement is only to write on
line to a file showing what the program has done already. For example "will
WRITE FILE", ok WRITE FILE", "will DBGET DATASE", "ok DBGET DATABASE", and
so on. Use different files for every program, job and session. Be sure to
have a "global switch" to be able to turn debuging on or off because this
will slow down your system a lot. Define the debug file with ";SHR;NOBUF"
and an FCONTROL,"write to disc immedate, wait for disc write" ( I don't
remember the number, I think it is 2 or 4) to be sure to have the debug
output on disc and not in memory. The next time a session hangs you can look
into the debug output file to see at which point the program hangs.

I was doing something similar already to find out a locking problem and it
worked well.

- Hermann -
PS: Build the debug files very, very large, you will get a lot of io's!

ATOM RSS1 RSS2