2014-09-15 2 views
2

В SAS с использованием опции SASMSTORE я могу указать место, где будет существовать каталог SASMACR. В этом каталоге будет находиться макрос. В какой-то момент мне может понадобиться изменить макрос, и этот момент может произойти, пока этот макрос и, следовательно, каталог будет использоваться другим пользователем. Но тогда он будет заблокирован и недоступен для изменения. Как я могу избежать такой ситуации?Изменение сохраненного макроса SAS

ответ

2

Если вы используете каталог SAS Macro как общедоступный каталог, который совместно используется коллегами, существует несколько вариантов.

Во-первых, используйте SVN или аналогичный вариант управления источником, чтобы у вас и ваших коллег была локальная копия каталога макросов. Это мой предпочтительный вариант. Я бы сделал это, а также, возможно, не использовал сохраненные скомпилированные макросы - я бы просто настроил его как макрос автозаполнения, лично - потому что это упростило разрешение конфликтов (так как у вас есть отдельные файлы для каждого макроса). Используя SCM, вы не сможете разрешать конфликты, поэтому вам нужно убедиться, что все очень хорошо себя ведут о том, чтобы всегда загружать самую последнюю копию, прежде чем вносить какие-либо изменения, и обсуждает любые изменения, поэтому у вас нет двух конкурирующих изменений примерно в то же время. Если SCM важны для вашего конкретного случая использования, вы можете управлять версиями макросов, которые создают SCM, и самостоятельно создавать SCM каждый раз, когда вы обновляете локальную копию источников.

Во-вторых, вы можете и должны отделить разработку от производства здесь. Даже если у вас есть разделяемая библиотека, расположенная в общей сетевой папке, у вас также должна быть копия разработки, которая явно не заблокирована кем-либо, кроме тех случаев, когда она разрабатывает для нее новый макрос (или обновляет текущий макрос). Затем внесите необходимые изменения и по согласованному графику вытащите их, как только они будут протестированы и проверены (желательно в тестовой среде, поэтому у вас есть классические три: dev, test и prod). Что-то вроде этого:

  • Изменения в Dev подвергаются испытаниям по средам. Любой, у кого есть что-то готовое к работе в среду 3pm, помещает его в папку (исходный код макроса, то есть), и он автоматически компилируется в тест SCM.
  • Тест затем проверяется четверг и пятница. Все, что проверено в тесте к 3pm пятницам, в это время помещается в папку исходного кода Dev, обращая внимание на любые потенциальные конфликты в другом новом коде в тесте (ничто не подталкивается к dev, если что-то в настоящее время тестируется, но не проверено, может конфликтовать с ним).
  • Производство затем запускается в 15:00 пятницы. К тому времени все должны быть вне SCM.

Я предлагаю не использовать пятницу для prod, если у вас есть что-то, что работает в выходные, конечно, так как это рискует вам что-то исправить в выходные.

+0

+1 для макросов макросов и контроля версий. Мы используем эту настройку и никогда не сталкиваемся с конфликтами в нашей команде. –

1

Создайте две папки, например. maclib1 и maclib2, и набор данных, который хранит текущий номер библиотеки.

Если вы хотите перестроить свою библиотеку, запросите текущее число, приращение (или сброс до 1, если оно уже равно 2), назначьте свой путь к библиотеке макросов в соответствующую папку, скомпилируйте свои макросы и затем обновите набор данных с помощью новый номер библиотеки.

Когда вы планируете назначать свою библиотеку, запросите текущий номер библиотеки из набора данных и соответствующим образом назначьте путь к библиотеке.