About AndrewHowell

AndrewHowell · ‎02-18-2018

I'm playing with stored process prompts - dates & metadata objects, specifically. What I'm now after is a stored process prompt to select a metadata folder (rather than a metadata object or objects within a folder). Can't find anything in documentation, but hoping there's a solutions there somewhere. Any thoughts? Thanks.

AndrewHowell · ‎02-12-2018

Chris, Why not put word out for client sites willing to beta-test? I'm at a site which is keen to use Git not just for source-code control, but also to mange SDLC promotion from Dev-Test-Prod. I've played with (*.sas) code in versioning software, and am keen to test how it handles (*.spk) metadata packages, inter-object dependencies, etc. Regards, Andrew.

AndrewHowell · ‎02-07-2018

-noexecute: good to know, produces report without making change. I'll try & let you know. Thanks.

AndrewHowell · ‎02-06-2018

General recommendations for the sequence of migrating metadata objects: 1. Security objects (Access Control Templates, users, groups, roles) 2. Libraries 3. Tables 4. ETL flows 5. Mid-tier content (reports, etc) Catalogs will most likely be required to be recompiled from their source on the target platform For a 9.1 to 9.4 migration, security objects may have to be recreated. (And there were no roles in 9.1)

AndrewHowell · ‎02-06-2018

Thanks @ronan. I'm feeling the challenge, since I was invited to present at last year's SGF, specifically on managing SLDC across SAS environments & within a single environment - although I had presumed a linear Dev-to-Test-to-Prod scenario. I hadn't considered how to manage parallel development across multiple Dev environments, and this is the first time I've had to deal with it at a client site. As you indicated, my first thought is the only way for this to work is to ensure all Dev metadata repositories are synched. There will be changes underway in each Dev environment, but presumably these will be checked out into project repositories, so (in theory) any metadata not checked out should be identical in each environment. So now I'm looking at: how to compare metadata packages & report on differences how to flag if an object in a package is checked out in one of the Dev environments. Hope this kicks off some good discussions.

AndrewHowell · ‎02-06-2018

A site with multiple, separate Dev environments (different departments, different solutions, different release cycles - some Devs are permanent, others are fired up only when required). These separate Dev environments DO share some metadata-defined resources (database tables, in particular). In each environment, changes are done using DI Studio (CheckIn/CheckOut project repositories, etc). Currently, SAS packages are exported from each Dev environment, and carefully (with lots of manual checking) imported/merged into a Test environment. Now, SAS Metadata can manage metadata objects (properties, associations, etc) within any one environment, but not across multiple environments. Scenarios: Modify a table metadata definition and/or a DI job (which may also change table definitions) in one Dev platform Modify a parameterised stored process (which is not metadata-associated with any specific table and/or job) in one Dev platform Probably others, but they are the main ones Wondering about security models (ACTs, user groups, etc) Issues: How to determine impact analysis on other Dev platforms. How to merge changes from different Dev platforms into a Test environment. Mandating a linear SDLC (one shared Dev, promote to Test, promote to Prod) is not an option. A (non-SAS) suggestion for a solution has been made to export every metadata object (many!) as separate SPK packages, and check all of them into GitHub, and use Git to check the package's XML against what is already checked into Git. I'm uncertain if this suggestion includes each object's dependencies (I'm presuming not, as the aim is to break the multi-platform solutions into their individual objects and check each one in/out independently.) I am NOT a Git expert (in fact, I'm a novice), but I'm having difficulty seeing how this is viable. One concern I have (feel free to add more or correct me): the more granular (atomic?) we export each object (table, job, etc), the more we lose the relationships between the objects. That said, I also cannot come up with a thorough-enough "SAS" solution to manage change across multiple Dev environments, either. Constructive suggestions would be appreciated.

AndrewHowell · ‎02-05-2018

If it's working well, then theoretically you don't need any logs! It's when things start NOT working well, you need to have enough log files to diagnose & fix the issue. Provided your server's file system has regular back-ups - including the log files, which can therefore be retrieved if required - you should only need the most recent log files (couple of days, a week at the most). But this does assume you have a filesystem backup of older log files.

AndrewHowell · ‎02-05-2018

I wouldn't advocate the "any" informats in a critical operational environment. But the need which created the "any" informat highlights that there are inputs where we cannot mandate a consistent date/datetime informat. (That may or may not be the case here.) Any use of an "any" informat MUST come with the presumption that the date might be incorrectly informatted.

AndrewHowell · ‎02-05-2018

Don't forget the optional 4th INTNX() parmeter: "B" - beggining of period "M" - middle of period "E" - end of period "S" - same place in period

AndrewHowell · ‎02-04-2018

Data Test; Length A $60.; A='20180205092045'; B=input(A,anydtdtm.); run;

AndrewHowell · ‎02-02-2018

Unsure if there's a definitive list - it depends what you have & how often it's used. (May also depend on your logging options.) My general rule of thumb is to zip any existing log files and remove any more than 24 hours old.

AndrewHowell · ‎02-01-2018

At a former site, we would run a scheduled monthly O/S script which would check a list of log folder locations. For each log folder: Compress all log files older than 24 hours into a "monthly-named" zip file. Once compress, remove those log files. Remove any compressed files older than 3 months. So each folder would contain (for example): todays_log_file(s).log 201712.zip 201711.zip 201710.zip other (non log) files That way, admins had access to up to 3 months of logs if required. If older logs were required (unlikely?), revert to the server's filesystem backup. I don't have a copy of the script here at my new site (different role), but it shouldn't be hard to replicate.

AndrewHowell · ‎01-29-2018

Can you post a few lines of data - it's the data which determines the code.

AndrewHowell · ‎01-23-2018

There is a very useful sample macro provided %mduextr() which can most likely do what you want. Suggest you read this blog by Leonard Batkhan https://blogs.sas.com/content/sgf/2016/01/13/sas-administrators-tip-keeping-track-of-sas-users/ More information can be found in the Security Administration Guide Overview of User Bulk Load and Synchronization

AndrewHowell · ‎01-02-2018

If you rename the *.spk file to *.zip, you'll see that the package is actually a zip file containing folders & XML files of all the package's objects, attributes & associations. Hope this helps.

Online Status	Offline
Date Last Visited	‎04-30-2023 01:46 PM