ERROR: A lock is not available for TEMPLATE.TEMPLAT.ITEMSTOR.

[KevinViel]

I have placed an itemstore in a shared folder and added the following to the autoexec.sas:

libname __Tmplt_

        "L:\PROD\SHARE\SAS\TEMPLATES"

        ;

ods path ( prepend )

            __Tmplt_.templat

         ( read )

         ;

Attempting to add a new style resulted in:

ERROR: A lock is not available for TEMPLATE.TEMPLAT.ITEMSTOR.
ERROR: Template 'Styles.Fda_arial' was unable to write to template store!

This concerns me for several reasons; can the programmers uses the styles if other programmers have SAS open and why would their read access lock the file (which almost seems reasonable)?

An obvious solution would be to add the style definition to the autoexec.sas and write it to the (temporary)

SASUSER.TEMPLAT(UPDATE).

I appreciate any suggestions or references.

Thank you,

Kevin

[Tim_SAS · Accepted solution]

No user can update the template store while any user has the template store open for reading. You're right, if you need to make updates to an template store, do it in SASUSER (or some other, non-shared, library) until you can get sole access the shared template store.

[KevinViel]

Thanks, Tim.

So my choices are to change the access to (UPDATE) or put the styles in the SASUSER.TEMPLATE of each user.  I wonder how the big shops configure it?  At least when it is in the AUTOEXEC.SAS, then I can tell from the log of the program whether they template has changed.  Otherwise, an external program could update the shared resource with an obvious sign in the current program's log.

Kind regards,

Kevin

[Tim_SAS]

What are you trying to do? I assume that generally folks don't update a template very frequently, and generally multiple people don't update the same template at the same time.

[Cynthia_sas]

Hi:
Here's my .02.

When I've had to share a template, I generally test it thoroughly and then when I know that no one else is using the shared drive, I will open a folder with UPDATE access on the shared drive to create the item store 1 time. Then, I put the LIBNAME statement and ODS PATH statement (with READ) access into service for myself and other programmers to use on a day-to-day basis.

Generally, I recommend that the other programmers put the statements into their usual AUTOEXEC or startup program or if in EG, add it to their statements before a project.

If EVERYONE points to the same 'L:' drive across the company, than using drive letters will work. But if one person can map it as an L drive and another person can map the shared folder as an S drive and someone else map it as the P drive, then using your drive letter may not work and you may have to use the network resource name (the machine name and folder) instead of the mapped drive folder.

cynthia

[KevinViel]

The big issues is that even in this small shop, SAS is open, so it would always be locked.  Interestingly, since the configuration here keeps the directory for the SASUSER permanently, what I stated earlier was incorrect.  The user could update the style external to the program of interest and it would not be perceptible in the current log.  I guess one cannot get around this, but the risk should be neglible.

I wrote the following macro to check for the existence of a style in an itemstor and delete it if it exists:

%macro m_u_delete_style

   ( style =

   , store =

   ) ;

  %if     &store. ne %str()

      and %sysfunc(exist( &store. , itemstor )) = 0

  %then

     %do ;

         %put ER%str(ROR: ) The itemstore &store. does not exist. ;

         %goto __END ;

     %end ;

  filename __st temp ;

  proc printto

     print = __st

     new

     ;

  run ;

  proc template ;

    list / store = &store.

           where = ( upcase( path ) = upcase( "&style." ))

           ;

  run ;

  proc printto ;

  run ;

  data _null_ ;

    infile __st ;

    input ;

    if prxmatch( "/&style./i" , _infile_ )

    then

      do ;

         call execute( "proc template ;" ) ;

         call execute( cat( "delete "

                          , "&style."

                          , "/ store = &store. ;"

                          )

                     ) ;

         call execute( "run ;" ) ;

         stop ;

      end ;

  run ;

  filename __st clear ;

  %__END:

%mend m_u_delete_style ;

Please let me know if you see any errors or areas to improve.

HTH,

Kevin 

[Cynthia_sas]

Hi:
My only suggestion is NOT to update SASUSER. I do not write templates to SASUSER because when you install SAS, the SASUSER library goes away.

If you ARE going to write to SASUSER, then I recommend highly that you SAVE all your code that creates the templates in the item store.

cynthia

[KevinViel]

I understand.  I needed a solution and could not even hope to track down all of my users to log out of SAS, if they even could.

The shared autoexec.sas re-writes the template with each invocation of a session.  For production work, they should be submitting one program from a fresh session only.  It makes for a bit of a lengthy log from the autoexec and echo, but we have the font we need 🙂

Thank you,

Kevin

[SASKiwi]

Our approach is to store TEMPLATE updates in the SAS WORK library as WORK.TEMPLATE then add an ODS PATH to every job's setup (could be in a SAS CONFIG) pointing to WORK.TEMPLATE.

The advantage of this approach is the avoidance of any locking or sharing problems. The disadvantage is every job/session has to create (or copy) the templates from scratch. If there aren't very many then the overhead would be minimal.