ana/sys sho proc/chan

[Maurizio Savoia]

How do i get to know the number of open channels of each and every running process? Using "analyze/system show proc/channel" is impractical on systems where a huge number of processes is running. Is there a way to get this information from a C program?

[Ian Miller.]

You could loop through all processes and use $GETJPI.
$GETJPI item FILCNT will give you open file quota remaining to subtracting this from FILLM
will give you number of files. However this does not count channels open to devices not files e.g terminals and mailboxes.

What problem are you trying to solve?

[Volker Halle · Accepted solution]

Maurizio,

you can send the SDA output to a file:

$ ANAL/SYS
SDA> SET OUT x.x
SDA> SHOW PROC/CHAN ALL
SDA> EXIT

$ SEA x.x total

Like Ian said, what is your problem ?

Volker.

[Jeff Chisholm]

Volker's answer is the best, sending the output from
SDA> sh proc/chan all
to a file, but it depends on the pageable CCB area being in memory for each process. Not likely on a busy system.

Usually when someone asks this question, they're attempting to see how many channels are being used system-wide, their (incorrect) assumption is that CHANNELCNT is per system rather than per process.

Why do you need a total?

[Ian Miller.]

Jeff, as SDA sends a kernal AST to the target process to obtain the ccb table then I don't think it being pageable is an issue.

The issue is why does Maurizio want this information?

[Jeff Chisholm]

You're right, thanks. I've just gone looking for channels in too many crash dumps. Same SDA, different context.

[Maurizio Savoia]

The reason why I need this info is that some ACMS servers behaved badly; one of the hypothesis made by our development team was that the channelcnt parameter was underestimated, so I needed a per-process total of the number of I/O channel being used by the server processes. I adopted the "SDA> sho proc/chan all" solution to monitor the number of channels in use.

[Ian Miller.]

The memory cost of increasing CHANNELCNT is very low (but does need a reboot) so it may be worth increasing it anyway.