[Imported from gridengine issuezilla ​http://gridengine.sunsource.net/issues/show_bug.cgi?id=2906]

        Issue #:      2906             Platform:     All           Reporter: templedf (templedf)
       Component:     gridengine          OS:        All
     Subcomponent:    kernel           Version:      6.2u2            CC:    None defined
        Status:       STARTED          Priority:     P3
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    templedf (templedf)
      QA Contact:     andreas
          URL:
       * Summary:     JSV API needs to be available for Java platform
   Status whiteboard:
      Attachments:

     Issue 2906 blocks:
   Votes for issue 2906:


   Opened: Thu Feb 5 12:01:00 -0700 2009 
------------------------


Not sure what component to submit against...

The JSV feature includes an API for Perl, Tcl, and Borne shell.  The API should
also be available for the Java platform.  Java platform support would also
enable Python, Ruby, and JavaScript.  The Java platform has significant
performance advantages over Perl, Tcl, and especially Borne shell in server-side
JSV scripts.

   ------- Additional comments from templedf Thu Jun 11 12:12:29 -0700 2009 -------
Assigning it to myself.

   ------- Additional comments from templedf Thu Jun 11 12:13:11 -0700 2009 -------
I have an implementation.  It still needs thorough testing, though.

[Imported from gridengine issuezilla ​http://gridengine.sunsource.net/issues/show_bug.cgi?id=2942]

        Issue #:      2942             Platform:     All      Reporter: mpospisil (mpospisil)
       Component:     gridengine          OS:        All
     Subcomponent:    clients          Version:      6.0         CC:    None defined
        Status:       STARTED          Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: 6.1u7
      Assigned to:    mpospisil (mpospisil)
      QA Contact:     roland
          URL:
       * Summary:     qconf -ke[j] must return non-zero exit code on failure
   Status whiteboard:
      Attachments:

     Issue 2942 blocks:
   Votes for issue 2942:


   Opened: Mon Mar 2 09:44:00 -0700 2009 
------------------------


There is couple of situations, where qconf -ke[j] <host> return zero code, but execd is not shutdown. Displayed message clearly suggests
it's a failure!

This is a problem when users rely on the exit state in their scripts.

I can confirm that in maintrunk this problem exists. I tried the following procedure below with an incorrect exit code.

>qconf -ke host123
failed sending shutdown notification to unknown execd host host123
>echo $?
0

This exit code should definitely not be 0, as this indicates a success when clearly an error occured.

   ------- Additional comments from mpospisil Mon Mar 2 09:48:17 -0700 2009 -------
In the qmaster code, there is no distinction between a failed attempt to kill an execd and a successful attempt. In both cases the status is
marked as STATUS_OK. This needs to be modified to give an error in the case where the attempt failed.

[Imported from gridengine issuezilla ​http://gridengine.sunsource.net/issues/show_bug.cgi?id=2978]

        Issue #:      2978             Platform:     Sun       Reporter: jf222792 (jf222792)
       Component:     gridengine          OS:        All
     Subcomponent:    clients          Version:      6.0beta      CC:    None defined
        Status:       REOPENED         Priority:     P4
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: 6.2u3
      Assigned to:    jf222792 (jf222792)
      QA Contact:     roland
          URL:
       * Summary:     qacct does not resolve complex shortcut names
   Status whiteboard:
      Attachments:

     Issue 2978 blocks:
   Votes for issue 2978:


   Opened: Mon Apr 6 02:56:00 -0700 2009 
------------------------


The qacct -l switch does not behave like for qstat or qsub. Complex Resources requested as shortcut are not resolved and thus no data is
collected.

Example:
Full complex name with usage report
% qacct -l arch=sol-amd64
Total System Usage
    WALLCLOCK         UTIME         STIME           CPU             MEMORY                 IO                IOW
================================================================================================================
           93             0             0             0              0.000              0.000              0.000

Shortcut complex name NO usage report
% qacct -l a=sol-amd64
total System Usage
    WALLCLOCK         UTIME         STIME           CPU             MEMORY                 IO                IOW
================================================================================================================

   ------- Additional comments from roland Thu May 7 07:38:13 -0700 2009 -------
qacct always parses the a complete accounting line, dups some strings (job_name, account_name ...) and then evaluates whether this line is
of interest.

The fix is:
1) Evaluate whether this line is of interest immediatly once a field (taken from strtok()) is ready. The time required to parse the
additional fields is then saved
2) Don't strdup() immediatly when a field is ready. Work on the local storage as long as possible and copy the strings only at the end when
the line is of interest

For a accounting file with 90000 entries this improved the qacct runtime by factor 7. For more entries the improvement will be higher.

   ------- Additional comments from roland Thu May 7 07:39:28 -0700 2009 -------
please ignore my last comment, it was for issue 2510