pstat_getproc()
in [Cobol]
|
Prev: For Holly
Next: WTB SPF/PC V4
From: Chris on 11 Apr 2006 16:38 Has anyone had experience calling this routine from COBOL before? If so, would you care to share the structure(s) you created for it? I'm considering this call to obtain some more detailed PID specific information. Right now the program is using (effectively) a kill -0 to check whether the process is "alive" or not. But this isn't a really scientific way of figuring out what is going on (memory usage, CPU usage, etc). I am really not looking forward to converting the pstat.h file to do this ... HP-UX 11.11 MF Server Express 4.0 SP2 Thanks in advance!
From: Chris on 11 Apr 2006 17:16 As a follow up: I generated pstat.cpy using the MF h2cpy utility and coded a quick call to see what I would get from the routine. Here is my code: IDENTIFICATION DIVISION. PROGRAM-ID. testpstat. WORKING-STORAGE SECTION. COPY "pstat.cpy". 01 my-status pst-status. 01 my-elemsize size-t. 01 my-elemcount size-t. 01 my-index int. PROCEDURE DIVISION. initialize my-status move length of my-status to my-elemsize move 0 to my-elemcount move 18059 to my-index call "pstat_getproc" using by reference my-status by value my-elemsize by value my-elemcount by value my-index end-call display RETURN-CODE display "UID: " pst-uid of my-status end-display display "PID: " pst-pid of my-status end-display display "PPID: " pst-ppid of my-status end-display display "UCOMM: " pst-ucomm of my-status end-display goback returning 0 . I get RETURN-CODE = 1, which is what I expect. However, the data fields under my-status seem to be all wrong. Any thoughts? Chris wrote: > Has anyone had experience calling this routine from COBOL before? If > so, would you care to share the structure(s) you created for it? > > I'm considering this call to obtain some more detailed PID specific > information. Right now the program is using (effectively) a kill -0 to > check whether the process is "alive" or not. But this isn't a really > scientific way of figuring out what is going on (memory usage, CPU > usage, etc). > > I am really not looking forward to converting the pstat.h file to do > this ... > > > HP-UX 11.11 > MF Server Express 4.0 SP2 > > > Thanks in advance!
From: James J. Gavan on 11 Apr 2006 18:32 Chris wrote: > I get RETURN-CODE = 1, which is what I expect. > > However, the data fields under my-status seem to be all wrong. > > Any thoughts? Yes. Don't dicker around :-) Post a message under Server Express in the M/F Forum. (That's assuming you haven't already done so). Jimmy
From: Michael Wojcik on 12 Apr 2006 12:16 In article <1144790194.892705.269630(a)t31g2000cwb.googlegroups.com>, "Chris" <ctaliercio(a)yahoo.com> writes: > > I generated pstat.cpy using the MF h2cpy utility and coded a quick call > to see what I would get from the routine. > > Here is my code: > > IDENTIFICATION DIVISION. > PROGRAM-ID. testpstat. > > WORKING-STORAGE SECTION. > > COPY "pstat.cpy". > > 01 my-status pst-status. > 01 my-elemsize size-t. > 01 my-elemcount size-t. > 01 my-index int. > > PROCEDURE DIVISION. > > initialize my-status > move length of my-status to my-elemsize > move 0 to my-elemcount move 1 to my-elemcount From the man page: "The elemcount parameter specifies the number of structs pst_status that are available at buf to be filled in". You have one structure available, so my-elemcount should be 1. NB: I haven't tested this myself. > I get RETURN-CODE = 1, which is what I expect. > > However, the data fields under my-status seem to be all wrong. Since you told pstat_getproc() that you didn't have room for any structures in your array, it didn't fill any in. If what you get back still looks wrong, you might have alignment issues. I'd put a "$set align'4'" at the top of the program. You might want to check that the group item created by h2cpy is the right size. A quick test on an HP-UX 11.11i machine here seems to show that it should be 768 bytes in 32-bit mode and 1176 bytes in 64-bit mode. -- Michael Wojcik michael.wojcik(a)microfocus.com The invigilator is not authorised to give any assistance. -- Peter Howard, "Rubric"
From: Chris on 12 Apr 2006 13:08
Hi Michael. Sorry - I should have been more clear - I am only interested in a single process, and that is the coding I was going for. >From the man page for pstat_getproc: pstat_getproc() ... As a shortcut, information for a single process may be obtained by setting elemcount to zero and setting index to the PID of that process. What is interedting though is that I am not getting stucrture size anywhere near what you describe. I am running in 64-bit mode, and I get 764 as the length of my-status. Any ideas ? # cob -V version @(#)cob.c 1.321 PRN=RXCPR/AAD:9i.T4.40.04 PTI=SP2 PTI=Fixpack40.04_46 committed I see no work # cobmode Effective Default Working Mode: 64 bit Thanks again, Chris Michael Wojcik wrote: > In article <1144790194.892705.269630(a)t31g2000cwb.googlegroups.com>, "Chris" <ctaliercio(a)yahoo.com> writes: > > > > I generated pstat.cpy using the MF h2cpy utility and coded a quick call > > to see what I would get from the routine. > > > > Here is my code: > > > > IDENTIFICATION DIVISION. > > PROGRAM-ID. testpstat. > > > > WORKING-STORAGE SECTION. > > > > COPY "pstat.cpy". > > > > 01 my-status pst-status. > > 01 my-elemsize size-t. > > 01 my-elemcount size-t. > > 01 my-index int. > > > > PROCEDURE DIVISION. > > > > initialize my-status > > move length of my-status to my-elemsize > > move 0 to my-elemcount > > move 1 to my-elemcount > > From the man page: "The elemcount parameter specifies the number of > structs pst_status that are available at buf to be filled in". You > have one structure available, so my-elemcount should be 1. > > NB: I haven't tested this myself. > > > I get RETURN-CODE = 1, which is what I expect. > > > > However, the data fields under my-status seem to be all wrong. > > Since you told pstat_getproc() that you didn't have room for any > structures in your array, it didn't fill any in. > > If what you get back still looks wrong, you might have alignment > issues. I'd put a "$set align'4'" at the top of the program. > > You might want to check that the group item created by h2cpy is the > right size. A quick test on an HP-UX 11.11i machine here seems to > show that it should be 768 bytes in 32-bit mode and 1176 bytes in > 64-bit mode. > > -- > Michael Wojcik michael.wojcik(a)microfocus.com > > The invigilator is not authorised to give any assistance. > -- Peter Howard, "Rubric" |