Formats between 32/64 bit and running without a error/warning messages

[Tpham]

I am trying to think about a solution.  We have multiple computers with SAS on it, some have 9.4 64 bit while others have 9.2 32 bit. We have recently notice there are issues with the formatting between these two versions when opening datasets.

So what I proposed as a solution is add the %include statement to load the format.sas file when loading our projects into SAS (we have an autoexec file for every project).  This will reload the format every time for the computer the person is using (32 vs 64 bit). But the downside on that is if the formats.sas file does not exist (typically during early stages of the project), an error message will show up in the log.  Our protocol is quite strict where we cannot have any error messages in the logs, even temporary ones.

I am wondering if there is a solution where we can reformats program file only if it exist, so there is not error message in the log file. Or if anyone can suggest any alternatives so the formats would work on both 32 and 64 bits.

[jakarman]

You have to support different physical locations for the same versions of  the catalogs for every SAS version/bitness.

Having defined a series for the 9.2 32 bit and one for  9.4 64 bit in a DTAP approach the next question how them keep them logical consistent.

When your protocol is quite strict you have a release management proces in place for underpinning to use the correct version of each component.

You can define a library concatenation for common usage (4=D,T,A,P  3=T,A,P 2=A,P 1=P). Moving the components (copy and delete!) is a easy version  control.

That can technically been implemented using the proc/upload/download  for that. With that you can degress components as long as all functionality is supported.

By that you have are more smoothly long time running conversion process for both SAS versions.

[KevinL70]

Using option nofmterr in the autoexec.sas file would eliminate errors when you don't have a formats.sas for a given project, but would not remove the errors if a format made for a different SAS / bit version was loaded.

[SASKiwi]

If I understand your question correctly, one possible solution might be to create a complete set of dummy formats each with the same name as your real format. Then when your real format code is run it will overwrite the dummy version. Since a complete set of formats will always exist there should be no log errors.

A dummy (or empty) format could look like this:

proc format;

value $My_Dummy_Format

other = ' ';

run;

[ndp]

During early stages just create a Formats.sas program with no formats using just following statements:

Proc format library=....;

Run;

Then keep adding values as you need during the project.

[Tom]

Not that I recommend it as what you should do, but you could use %SYSFUNC() with the IFC function to conditionally generate the %INCLUDE statement without have to resort to creating a macro.

%sysfunc(ifc(%sysfunc(fileexist(formats.sas)),%nrstr(%inc 'formats.sas';),))

[jakarman]

The original question of tpham is for me something to be solved as part of platform admin role (metadata). release management version control IT governance.   (Strict protocol)

Wondering why the approach goes into a cowboy style of working.

[BruceBrad]

The method we used to manage 32 and 64 bit on windows is as follows:

autoexec.sas includes the line

%ProjectLocations;

The ProjectLocations.sas file in the sasautos library

includes code

%if %sys64bit %then %let sys64bit=64;

%else %let sys64bit=;

Then it defines macro variables for each project folder which end in &sys64bit. These macro variables are used to the define the libnames and so we then end up with duplicate data folders for every project like

K:\project1\sas

K:\project1\sas64

The 32 bit users use the first folder and the 64 bit the second. When both 32 and 64 bit users are working on the same project (rare for us), they need to both run the setup programs which establish the working datasets and formats.