<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Dynamic Locking on SPD Server not working in Administration and Deployment</title>
    <link>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/917550#M28051</link>
    <description>&lt;P&gt;Thank you very much for your replies.&lt;BR /&gt;I played around with the modify statement because it allows to insert a call sleep and to lock the table for a defined time.&lt;BR /&gt;I ran in parallel from two EG instances the following code with table datahilf.test_concurr from above:&lt;/P&gt;&lt;PRE&gt;&lt;CODE class=""&gt;data datahilf.test_concurr;
 modify datahilf.test_concurr;
 a= a + 1;
 call sleep(1,1);
run;&lt;/CODE&gt;&lt;/PRE&gt;&lt;P&gt;The result was that datahilf.test_concurr was modified sequentially. The first instance updated a to 2 in around 60 seconds (call sleep for 60 observations) and the second instance modified a to 3 after another 60 seconds.&lt;BR /&gt;That means the parallel running modifying jobs have been queued.&lt;/P&gt;&lt;P&gt;In a second test I ran the modifying job again in one EG instance and after 30 seconds I ran a reading job in parallel (without call sleep) in the other instance:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;PRE&gt;&lt;CODE class=""&gt;data work.test_concurr;
 set datahilf.test_concurr;
run;&lt;/CODE&gt;&lt;/PRE&gt;&lt;P&gt;The result was that the jobs ran in parallel: In work.test_concurr 20 of the 60 Obs already had the value 4 instead of 3.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I was happy with these results and I tried to activate dynamic locking for another library, but it didn't work.&lt;BR /&gt;Also when I tried to de-activate dynamic locking for datahilf, this didn't work. It was still active after several restarts of the SPDS.&lt;/P&gt;&lt;P&gt;Do you have any ideas for this behaviour?&lt;/P&gt;</description>
    <pubDate>Fri, 23 Feb 2024 10:50:35 GMT</pubDate>
    <dc:creator>macrobo</dc:creator>
    <dc:date>2024-02-23T10:50:35Z</dc:date>
    <item>
      <title>Dynamic Locking on SPD Server not working</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/916492#M28021</link>
      <description>&lt;P&gt;Hallo SAS Community,&lt;/P&gt;&lt;P&gt;I want to use Dynamic Locking on our SAS-SPD-Server to enable concurrent access to tables. I added DYNLOCK=YES to the existing domain definition in the libnames.parm file:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;PRE&gt;&lt;CODE class=""&gt;libname=datahilf pathname=/daten_q/spds/index/datahilf owner=sas
        roptions="metapath=('/daten_q/spds/index/datahilf')
        datapath=('/daten_q/spds/data1/datahilf')
        indexpath=('/daten_q/spds/index/datahilf')"
        LIBACLINHERIT=YES
        &lt;FONT color="#FF0000"&gt;DYNLOCK=YES&lt;/FONT&gt;;&lt;/CODE&gt;&lt;/PRE&gt;&lt;P&gt;I stopped und re-started the SPD-Server and ran the following programm in parallel from two instances of SAS-EG:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;PRE&gt;&lt;CODE class=""&gt;data datahilf.test_concurr;
 do i = 1 to 60;
   a= 1; output;
   call sleep(1,1);
 end;
run;&lt;/CODE&gt;&lt;/PRE&gt;&lt;P&gt;From one of the instances I still get the following ERROR in the Log:&lt;/P&gt;&lt;PRE&gt;&lt;CODE class=""&gt;19 data datahilf.test_concurr;
20 do i = 1 to 60;
21 a= 1; output;
22 call sleep(1,1);
23 end;
24 run;

&lt;FONT color="#FF0000"&gt;ERROR: MEMBER lock is not available for DATAHILF.TEST_CONCURR.DATA, lock held by process 40042846.&lt;/FONT&gt;
NOTE: The SAS System stopped processing this step because of errors.
NOTE: DATA statement used (Total process time):
real time 0.00 seconds
cpu time 0.00 seconds&lt;/CODE&gt;&lt;/PRE&gt;&lt;P&gt;So it seems as if the configuration change in libnames.parm was not successful. I also checked whether the SPD Start-Script uses the correct libnames.parm file.&lt;BR /&gt;The SPD version is (unfortunately still) SAS Scalable Performance Data Server 5.4 (HF 1) Build(Tue Aug 14 11:45:18 EDT 2018) SPDS SNET Server&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;My questions:&lt;BR /&gt;- What is wrong in the domain definition? (I also ensured that record level locking ist not set.)&lt;BR /&gt;- Is there anything else to configure?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks in advance&lt;BR /&gt;Robert&lt;/P&gt;</description>
      <pubDate>Fri, 16 Feb 2024 15:37:11 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/916492#M28021</guid>
      <dc:creator>macrobo</dc:creator>
      <dc:date>2024-02-16T15:37:11Z</dc:date>
    </item>
    <item>
      <title>Re: Dynamic Locking on SPD Server not working</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/916515#M28022</link>
      <description>&lt;P&gt;A DATA step will always&amp;nbsp;&lt;EM&gt;create&lt;/EM&gt; the dataset, and destroy any pre-existing dataset of the same name. That's why it issues a non-breakable member lock.&lt;/P&gt;
&lt;P&gt;You need to try this with PROC SQL and INSERT statements, once the dataset has been created. You can concurrently run a DATA step which reads from the dataset and calls SLEEP, so that it keeps the dataset open for some time.&lt;/P&gt;</description>
      <pubDate>Fri, 16 Feb 2024 17:09:02 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/916515#M28022</guid>
      <dc:creator>Kurt_Bremser</dc:creator>
      <dc:date>2024-02-16T17:09:02Z</dc:date>
    </item>
    <item>
      <title>Re: Dynamic Locking on SPD Server not working</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/916776#M28028</link>
      <description>&lt;P&gt;Just to clarify, this will work when a statement updates the table in place.&lt;/P&gt;
&lt;P&gt;So data step with modify, or SQL UPDATE are also valid scenarios too, I believe.&lt;/P&gt;
&lt;P&gt;&lt;A href="https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/spdsag/p00j3zfgahpx73n1nhs5bjena764.htm" target="_blank"&gt;https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/spdsag/p00j3zfgahpx73n1nhs5bjena764.htm&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 19 Feb 2024 13:00:58 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/916776#M28028</guid>
      <dc:creator>LinusH</dc:creator>
      <dc:date>2024-02-19T13:00:58Z</dc:date>
    </item>
    <item>
      <title>Re: Dynamic Locking on SPD Server not working</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/917550#M28051</link>
      <description>&lt;P&gt;Thank you very much for your replies.&lt;BR /&gt;I played around with the modify statement because it allows to insert a call sleep and to lock the table for a defined time.&lt;BR /&gt;I ran in parallel from two EG instances the following code with table datahilf.test_concurr from above:&lt;/P&gt;&lt;PRE&gt;&lt;CODE class=""&gt;data datahilf.test_concurr;
 modify datahilf.test_concurr;
 a= a + 1;
 call sleep(1,1);
run;&lt;/CODE&gt;&lt;/PRE&gt;&lt;P&gt;The result was that datahilf.test_concurr was modified sequentially. The first instance updated a to 2 in around 60 seconds (call sleep for 60 observations) and the second instance modified a to 3 after another 60 seconds.&lt;BR /&gt;That means the parallel running modifying jobs have been queued.&lt;/P&gt;&lt;P&gt;In a second test I ran the modifying job again in one EG instance and after 30 seconds I ran a reading job in parallel (without call sleep) in the other instance:&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;PRE&gt;&lt;CODE class=""&gt;data work.test_concurr;
 set datahilf.test_concurr;
run;&lt;/CODE&gt;&lt;/PRE&gt;&lt;P&gt;The result was that the jobs ran in parallel: In work.test_concurr 20 of the 60 Obs already had the value 4 instead of 3.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I was happy with these results and I tried to activate dynamic locking for another library, but it didn't work.&lt;BR /&gt;Also when I tried to de-activate dynamic locking for datahilf, this didn't work. It was still active after several restarts of the SPDS.&lt;/P&gt;&lt;P&gt;Do you have any ideas for this behaviour?&lt;/P&gt;</description>
      <pubDate>Fri, 23 Feb 2024 10:50:35 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/917550#M28051</guid>
      <dc:creator>macrobo</dc:creator>
      <dc:date>2024-02-23T10:50:35Z</dc:date>
    </item>
    <item>
      <title>Re: Dynamic Locking on SPD Server not working</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/917555#M28052</link>
      <description>&lt;P&gt;I don't have access to SPDS at the moment, so I can't try myself.&lt;/P&gt;
&lt;P&gt;When you say doesn't work (activate and de-activate), how have you verified that?&lt;/P&gt;
&lt;P&gt;My guess is that the process of the libnames.parm file is shown in the spdsserv.log file...?&lt;/P&gt;</description>
      <pubDate>Fri, 23 Feb 2024 11:57:03 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/917555#M28052</guid>
      <dc:creator>LinusH</dc:creator>
      <dc:date>2024-02-23T11:57:03Z</dc:date>
    </item>
    <item>
      <title>Re: Dynamic Locking on SPD Server not working</title>
      <link>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/917917#M28061</link>
      <description>&lt;P&gt;I found the problem that prevented the SPD server from accepting changes in the libnames.parm file. The server could shut down correctly before the next startup.&amp;nbsp;&lt;/P&gt;&lt;P&gt;So thank you very much for helping me, the test problem above is solved.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Best regards,&lt;/P&gt;&lt;P&gt;Robert&lt;/P&gt;</description>
      <pubDate>Mon, 26 Feb 2024 15:32:30 GMT</pubDate>
      <guid>https://communities.sas.com/t5/Administration-and-Deployment/Dynamic-Locking-on-SPD-Server-not-working/m-p/917917#M28061</guid>
      <dc:creator>macrobo</dc:creator>
      <dc:date>2024-02-26T15:32:30Z</dc:date>
    </item>
  </channel>
</rss>

