I don't think this is the right answer - and I don't think the error
you're getting has anything to do with updating perl module versions.
I suspect that the actual problem here is somewhere earlier in your JSV.
In the code you showed the bit which is triggering the error is:
$href->{$sub} = $val;
..and the issue is that $href, instead of being a hash references is
simply a string (defProj). This is why the program is stopping.
The $href variable itself is simply fetched out of the %param hash using
my $href = $param{$key}; so the core issue is that the GridEngine code is
expecting the values of %param to be hash references and in your case the
value for the key is a string (defProj).
If you turn of strict reference checking then what you're effectively
allowing is :
"defProj" -> {something} = "something else"
..which doesn't do anything - the value is still "defProj" and the whole
function call to jsv_add_param is a no-op.
I suspect that what's happened is that earlier in your JSV script you've
done something else which has messed up the stored value in %param and
that it's only at this later stage where you try to do something else to
it that the earlier problem is apparent.
Simon.
On 13/06/2016, 13:19, "[email protected] on behalf of Manfred
Selz" <[email protected] on behalf of [email protected]>
wrote:
>Thank you to all who spent their time to answer.
>
>While I have still not fully understood why I suddenly have this problem,
>I was able to patch the JSV.pm code in the SGE installation locally and
>add a >no strict "refs"< to the offending "jsv_sub_add_param" function
>there.
>This is good enough for me.
>The function is now for me:
>
>sub jsv_sub_add_param {
> # adding no strict refs here to avoid JSV client issues - mselz -
>06/2016
> no strict "refs";
> my ($key, $sub, $val) = @_;
>
> my $href = $param{$key};
> $href->{$sub} = $val;
>
> jsv_set_param($key, $href);
>}
>
>(for the record - just in case anybody else should need this)
>
>Regards,
>Manfred
>
>-----Original Message-----
>From: [email protected] [mailto:[email protected]]
>On Behalf Of [email protected]
>Sent: Montag, 13. Juni 2016 14:00
>To: [email protected]
>Subject: users Digest, Vol 66, Issue 14
>
>Send users mailing list submissions to
> [email protected]
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://gridengine.org/mailman/listinfo/users
>or, via email, send a message with subject or body 'help' to
> [email protected]
>
>You can reach the person managing the list at
> [email protected]
>
>When replying, please edit your Subject line so it is more specific than
>"Re: Contents of users digest..."
>
>
>Today's Topics:
>
> 1. Re: JSV stderr when running jsv_set_param with parameter 'P'
> (William Hay)
> 2. Re: parallel job does not run on many cups (William Hay)
> 3. Re: parallel job does not run on many cups (Bill Bryce)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Mon, 13 Jun 2016 11:33:59 +0100
>From: William Hay <[email protected]>
>To: Manfred Selz <[email protected]>
>Cc: [email protected]
>Subject: Re: [gridengine users] JSV stderr when running jsv_set_param
> with parameter 'P'
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset="us-ascii"
>
>On Mon, Jun 13, 2016 at 08:03:04AM +0000, Manfred Selz wrote:
>> Since a long time ago, I have been running a standard server JSV
>>script to
>> check and set a few parameters, one of them being the project
>>(parameter
>> P).
>>
>
>>
>> While this still works fine, whenever I copy this script and run it
>> manually on client side like this:
>
>>
>> I get this message:
>>
>>
>>
>> error: JSV stderr: Can't use string ("defProj") as a HASH ref while
>> "strict refs" in use at /cad/eda/sge/6.2u5/util/resources/jsv/JSV.pm
>>line
>> 327, <> line 15.
>>
>> Unable to run job: JSV stderr: Can't use string ("defProj") as a
>>HASH ref
>> while "strict refs" in use at
>>/cad/eda/sge/6.2u5/util/resources/jsv/JSV.pm
>> line 327, <> line 15.
>>
>> JSV stderr is - Can't use string ("defProj") as a HASH ref while
>>"strict
>> refs" in use at /cad/eda/sge/6.2u5/util/resources/jsv/JSV.pm line
>>327, <>
>> line 15..
>>
>I suspect that your clients have a more up to date version of some perl
>module that your JSV uses and that module turns on strict refs. You
>should be able to get it working again by a judicious application of:
>
>no strict 'refs';
>
>Inserting it near the top of JSV.pm after any module imports but before
>the problem code should work.
>
>Alternatively you could patch the JSV code so it doesn't try to
>dereference strings or if you are using something later than the 6.2u5
>you appear to be ask whoever maintains the grid-engine you use to do so.
>
>William
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: signature.asc
>Type: application/pgp-signature
>Size: 819 bytes
>Desc: Digital signature
>URL:
><http://gridengine.org/pipermail/users/attachments/20160613/b9611f48/attac
>hment-0001.sig>
>
>------------------------------
>
>Message: 2
>Date: Mon, 13 Jun 2016 11:47:14 +0100
>From: William Hay <[email protected]>
>To: Ulrich Hiller <[email protected]>
>Cc: [email protected]
>Subject: Re: [gridengine users] parallel job does not run on many cups
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset="us-ascii"
>
>On Fri, Jun 10, 2016 at 07:24:47PM +0200, Ulrich Hiller wrote:
>> Hello,
>>
>> I have a problem submiiting parralel jobs, e.g.:
>>
>
>> Your Open MPI job will likely hang until the failure resason is fixed
>> (e.g., more file descriptors and/or memory becomes available), and may
>> eventually timeout / abort.
>>
>> Local host: karun02
>> Errno: 24 (Too many open files)
>> Probable cause: Out of file descriptors
>> ----------------------------------------------------------------------
>> ----
>This doesn't look like it has much to do with grid engine per se.
>I'd look at ulimit to see what is going on and tweak things to raise the
>number of open files allowed appropriately.
>
>On linux limits.conf would be the first place to look although shell
>startup scripts might lower the limits as well.
>
>William
>
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: signature.asc
>Type: application/pgp-signature
>Size: 819 bytes
>Desc: Digital signature
>URL:
><http://gridengine.org/pipermail/users/attachments/20160613/f0073e77/attac
>hment-0001.sig>
>
>------------------------------
>
>Message: 3
>Date: Mon, 13 Jun 2016 07:55:15 -0400
>From: Bill Bryce <[email protected]>
>To: William Hay <[email protected]>
>Cc: Ulrich Hiller <[email protected]>, [email protected]
>Subject: Re: [gridengine users] parallel job does not run on many cups
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset="utf-8"
>
>Hello as William mentioned it doesn?t look like a Grid Engine issue. Can
>you run your MPI job outside of Grid Engine? I would try that first, get
>it working without Grid Engine then try submitting it to Grid
>Engine?.basically reduce the number of variables to debug simultaneously.
>
>Regards,
>
>Bill.
>
>> On Jun 13, 2016, at 6:47 AM, William Hay <[email protected]> wrote:
>>
>> On Fri, Jun 10, 2016 at 07:24:47PM +0200, Ulrich Hiller wrote:
>>> Hello,
>>>
>>> I have a problem submiiting parralel jobs, e.g.:
>>>
>>
>>> Your Open MPI job will likely hang until the failure resason is fixed
>>> (e.g., more file descriptors and/or memory becomes available), and
>>> may eventually timeout / abort.
>>>
>>> Local host: karun02
>>> Errno: 24 (Too many open files)
>>> Probable cause: Out of file descriptors
>>> ---------------------------------------------------------------------
>>> -----
>> This doesn't look like it has much to do with grid engine per se.
>> I'd look at ulimit to see what is going on and tweak things to raise
>> the number of open files allowed appropriately.
>>
>> On linux limits.conf would be the first place to look although shell
>> startup scripts might lower the limits as well.
>>
>> William
>>
>> _______________________________________________
>> users mailing list
>> [email protected]
>> https://gridengine.org/mailman/listinfo/users
>
>William Bryce | VP Products
>Univa Corporation, Toronto
>E: [email protected] | D: 647-9742841 | Toll-Free (800) 370-5320
>W: Univa.com | FB: facebook.com/univa.corporation | T:
>twitter.com/Grid_Engine
>
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: signature.asc
>Type: application/pgp-signature
>Size: 496 bytes
>Desc: Message signed with OpenPGP using GPGMail
>URL:
><http://gridengine.org/pipermail/users/attachments/20160613/1fc4b108/attac
>hment-0001.sig>
>
>------------------------------
>
>_______________________________________________
>users mailing list
>[email protected]
>https://gridengine.org/mailman/listinfo/users
>
>
>End of users Digest, Vol 66, Issue 14
>*************************************
>________________________________
>
>Dialog Semiconductor GmbH
>Neue Str. 95
>D-73230 Kirchheim
>Managing Directors: Dr. Jalal Bagherli, Carsten Dahl
>Chairman of the Supervisory Board: Rich Beyer
>Commercial register: Amtsgericht Stuttgart: HRB 231181
>UST-ID-Nr. DE 811121668
>
>Legal Disclaimer: This e-mail communication (and any attachment/s) is
>confidential and contains proprietary information, some or all of which
>may be legally privileged. It is intended solely for the use of the
>individual or entity to which it is addressed. Access to this email by
>anyone else is unauthorized. If you are not the intended recipient, any
>disclosure, copying, distribution or any action taken or omitted to be
>taken in reliance on it, is prohibited and may be unlawful.
>
>Please consider the environment before printing this e-mail
>
>
>
>_______________________________________________
>users mailing list
>[email protected]
>https://gridengine.org/mailman/listinfo/users
The Babraham Institute, Babraham Research Campus, Cambridge CB22 3AT Registered
Charity No. 1053902.
The information transmitted in this email is directed only to the addressee. If
you received this in error, please contact the sender and delete this email
from your system. The contents of this e-mail are the views of the sender and
do not necessarily represent the views of the Babraham Institute. Full
conditions at: www.babraham.ac.uk<http://www.babraham.ac.uk/terms>
_______________________________________________
users mailing list
[email protected]
https://gridengine.org/mailman/listinfo/users
