regarding system performance

[Hein van den Heuvel]

>> READS: 00000010 WRITES: 00000000
:
>> P1_COUNT: 00000020 P1_LBN: 00E60770
>> P2_COUNT: 00000010 P2_LBN: 00E78DC0

>> But what can I infer from this.

First of all we notice that you are dealing with a relatively fragmented file. Tiny chunks for a large allocation. :-(.
Secondly we see that the actually IO to this file might not be a problem (low read/write count).
But the most important information would come from the next time you issue the same command: Does it change!? Is the application making progress in the file?

You might also want to use a wonderful SDA extention Volker wrote: PROCIO. See:
http://eisner.encompasserve.org/~halle/

You may also want to use SHOW MEM/CACH=(VOLU=xxx,TOPQIO) to see cached IO activity counts for the suspect file.

I don't know EDI... does is work with RMS sequential files? Indexed? What picture does MONI MODE paint.

And... did you consider that it all might be working just fine? Do you have comparison material to suggest what you see is wrong?

Does the EDI tool have an internal/application level performance/throughput monitor to help show what it is doing?

Steven wrote>> found it. Now, can you attach a copy of Microsoft Word for VMS Alpha

I agree with that sentiment Steven... Ajaydec, the data which you attached is simple text. KISS. Attach it as a simple text file and the retrieval and formatting will be so much easier for teh folks who are trying to help.

Good luck!
Hein.

[#2]

Hi,

1) decedi$csf_2 process works on rms files. It is used to fetch the file from data base and then process it and then save it again in different data base and also on hard disk. Right now there are lots of files to be fetched by decedi$csf_2 process but decedi$csf_2 is not processing those files and now its almost more then 60 hr, since decedi$csf_2 has fetched last file.

2) I have attached output of following commands with the attachment in *.doc format to increase the readability.
a) Monitor system
b) show sys/process=decedi$csf_2 /full
c) show process decedi$csf_2 /locks /brief
d) SDA> show process decedi$csf_2
e) show process /id=xxx /cont
f) monitor mode
g) SDA> show process /chan
h) monitor disk
i) monitor fcp
j) SDA> SHOW PROC/RMS=WCB

Is there any more information I can provide to know why decedi$csf_2 process is not performing.

Regards,
ajaydec

[Steven Schweda]

> 2) I have attached output of following
> commands with the attachment in *.doc
> format to increase the readability.

This must be some new meaning for "increase".

[Volker Halle]

ajaydec,

why do you think you need to put simple text data into a proprietory file format ? A simple .TXT file would have been sufficient ...

EDI seems to be using a RDB database ! The files on $1$DKA300: are .RDA and .RDB files.

You need to troubleshoot this with RDB database utilities.

Volker.

[Hein van den Heuvel]

That does NOT look like an RMS application, but rather an RDB application. Your next tools of choice would be RDB tools.

For example (if memory serves me right) :

RMU/SHOW STATISTICS/SCREEN=STALL


Did you check (operator) log files for simple things as 'disk full' or quota problems?

After so long not processing records, I'd be mighty tempted to re-start the application and/or the database and hope for the best.

At the very least a restart is an opportunity for a clear error/warning message.

Good luck!
Hein.

[Volker Halle · Accepted solution]

ajaydec,

you might need to specify the root db file:

$ rmu/show stat $1$dka300:[audit_db]decedi$audit_db.rdb

To further troubleshoot this, you will probably need to find someone, who understands and is able to support DECEDI !

Volker.

[#7]

I am sorry, I just want to help you to get better picture of the process and then help me.
Now I got something relevant that it is something to do with the database.
Thanks to all for their time and support.

Now can anyone help me how to troubleshoot for the database.

Regards,
ajaydec

[Doug Phillips]

What does this EDI module do? (I don't know DECEDI) Since it has TCPIP open, is it the send or receive or format conversion module?

If your RDB tools don't show that the container is corrupted or full, suspect the EDI data. Maybe your trading partner has sent a new format version? There could be a new record set that is causing a tight logic-loop. The LEF state could also indicate that the program might be trying to send a message to and/or get a response from a device that isn't available.

[#9]

REGARDS
AJAYDEC