[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

1590.0. "DECWindows & VMS accounting???" by KIPPIS::RUUSKANEN () Wed Oct 18 1989 11:18

        Hello,

I found strange behaviour in DECWindows & VMS accounting.

Monday morning I was logged in to my VAXstation and I entered command:
$SHO PROC/ACCO/ID=<pid> ! pid belongs to the session manager process

18-OCT-1989 13:25:02.17   User: RUUSKANEN        Process ID:   38600086
                          Node: KAR31            Process name: "RUUSKANEN"

Accounting information:
 Buffered I/O count:       513  Peak working set size:       2217
 Direct I/O count:         180  Peak virtual size:           6141
 Page faults:             8649  Mounted volumes:                0
 Images activated:           9
 Elapsed CPU time:      0 01:12:55.23
 Connect time:          2 20:17:12.09


    Connect time of process is almoust 3 days!!!!!!! 
    Elapsed CPU time is quite huge too.

    Is this realy the right feature?
    If I have to pay my used CPU time this will cost to me some extra dollars.
    
    Any ideas why I have to pay those cost?

                Kari

T.RTitleUserPersonal
Name
DateLines
1590.1fixed in next releaseSTAR::ORGOVANVince OrgovanWed Oct 18 1989 15:058
    I believe that this is fixed in VMS V5.3. In VMS V5.1 (and 5.2?),
    the DECwindows loginout image didn't zero out the connect and cpu
    times when a login completed. As a result, the process that 
    eventually runs your session manager was charged for all the time
    that loginout was blinking the cursor.
    
    If you're running T5.3 and this is still broken, please file a QAR. 

1590.2Thanks VinceKIPPIS::RUUSKANENThu Oct 19 1989 17:469
    
    
    	It's nice to hear that this is already fixed in V5.3. 
    
    	I will file a QAR as soon as possible.
    
    		Best regards,
    			Kari Ruuskanen