BookmarkSubscribeRSS Feed
☑ This topic is solved. Need further help from the community? Please sign in and ask a new question.
elisehoo1
Obsidian | Level 7

Greetings to all!

I'm currently in the content development stage for customized Basel II in SAS Risk Management and have a proactive query regarding best practices in naming conventions.

 

As part of my development process, I am contemplating whether using the same libname across different federated areas could potentially lead to conflicts or issues within the system. Specifically, I'm looking for insights on whether this practice is common and if there are any known implications or best practices to be aware of

1 ACCEPTED SOLUTION

Accepted Solutions
Patrick
Opal | Level 21

In regards of terminology:

CONFIGURATION is very o.k. and IRM provides a lot of flexibility for such, CUSTOMIZATION that changes the product as designed is something you should try to avoid as it will reduce product support and likely also create a lot of additional effort for any upgrade to later releases (=technical debt). 

If you really believe that you have to customize the product/a content pack then I'd advice to first get some feedback from SAS before going ahead.

 

For libnames:

  • They need to be defined in .../config/libnames.txt 
    • Don't create libname statements directly in task code.
  • libnames.txt is content pack specific (=specific to the federated content under which you execute the IRM flow)
    • the same libname definitions under different content packs won't clash. IRM only ever picks the one from the content pack under which you execute.
    • If you need dynamic components in the libname definitions then look into %la, %cs, %bd and especially %mv as part of the libname definition under libnames.txt
  • If you've got for example two versions of the Basel content pack then most of the libnames definitions in the two content pack specific libnames.txt will be the same.
    • But it's in principle possible that task code which is federated content only exists in the earlier content pack (lower priority content pack) and though the same libref in both content packs is actually a must have and "as per design" for the task to work running under either content pack.

Hope that answered your question.

 

 

 

View solution in original post

6 REPLIES 6
Patrick
Opal | Level 21

In regards of terminology:

CONFIGURATION is very o.k. and IRM provides a lot of flexibility for such, CUSTOMIZATION that changes the product as designed is something you should try to avoid as it will reduce product support and likely also create a lot of additional effort for any upgrade to later releases (=technical debt). 

If you really believe that you have to customize the product/a content pack then I'd advice to first get some feedback from SAS before going ahead.

 

For libnames:

  • They need to be defined in .../config/libnames.txt 
    • Don't create libname statements directly in task code.
  • libnames.txt is content pack specific (=specific to the federated content under which you execute the IRM flow)
    • the same libname definitions under different content packs won't clash. IRM only ever picks the one from the content pack under which you execute.
    • If you need dynamic components in the libname definitions then look into %la, %cs, %bd and especially %mv as part of the libname definition under libnames.txt
  • If you've got for example two versions of the Basel content pack then most of the libnames definitions in the two content pack specific libnames.txt will be the same.
    • But it's in principle possible that task code which is federated content only exists in the earlier content pack (lower priority content pack) and though the same libref in both content packs is actually a must have and "as per design" for the task to work running under either content pack.

Hope that answered your question.

 

 

 

elisehoo1
Obsidian | Level 7
I just want to ask if there's any chance you might shed some light on the SAS function in IRM.

i) Does SAS function work in IRM ?
ii) is it similar to libnames.txt , it is restricted within the specific FA?
Patrick
Opal | Level 21

Not sure that I understand your question. libnames.txt is a configuration file to define libnames that IRM will use as input of task header code generation. 

I don't understand what you mean by "Does SAS function work in IRM".

elisehoo1
Obsidian | Level 7

No worries. I'm just asking an additional question: Can we integrate a customized function into IRM? Sorry, I think I should post this as a new topic

Patrick
Opal | Level 21

@elisehoo1 wrote:

No worries. I'm just asking an additional question: Can we integrate a customized function into IRM? Sorry, I think I should post this as a new topic


Agree! Posting this as a new question will help to keep the threads "cleaner" and easier to search for solutions.

 

You will still need to formulate your question clearly. IRM is just orchestrating and executing tasks. It's the tasks that then link to your SAS code (.sas files stored under a .../nodes folder). The SAS code can contain any valid SAS syntax including defining and calling custom functions created via Proc FCMP ...if it's that what you're asking.

himanshucb
SAS Employee

Same library reference in libnames.txt of different federated areas or solutions may create conflict.

 

Example:

FA1 > libnames.txt defines STAGING = %la/%bd

FA2 > libnames.txt defines STAGING = %la/some_folder/%bd

 

Depending on which FA (and consequently libnames.txt) is being picked up by IRM, you may face error of "Data not found". So, it must be avoided.

 

On the other side, library references in output of different job flows can be repeated since each instance runs in its own dedicated folder.

Discussion stats
  • 6 replies
  • 807 views
  • 2 likes
  • 3 in conversation