-1

I have the below macro, PARAMETERS, that assigns values to five variables and creates the table MD_WRK.SUB_ID. My issue is that the code within the macro worked fine until I placed it within the macro. Now the variables are not being populated and the PROC SQL for table creation is not being executed. When I remove "%MACRO" the PROC SQL colors change to indicate that it is correct, but when within the macro they are greyed out. I can't understand why the code within the macro is being invalidated.

%MACRO PARAMETERS;
%GLOBAL FDMVAR1 FDMVAR2 UPBOUND LOBOUND GROUPVAR;
    %LET FDMVAR1 ='31Mar2017:0:0:0'dt; /* Start Date */
    %LET FDMVAR2 = '30Apr2017:0:0:0'dt; /* End Date */
    %LET UPBOUND = .01;
    %LET LOBOUND = -.01;
    %LET GROUPVAR = 1;

    PROC SQL;
        CREATE TABLE MD_WRK.SUB_ID
            (SUBSYS_ID char(6));
        INSERT INTO MD_WRK.SUB_ID
            VALUES('CBS')
            VALUES('CDS')
            VALUES('DDA')
            VALUES('IMCOR')
            VALUES('ODL')
            VALUES('OEC')
            VALUES('OEC2')
            VALUES('SAV')
            VALUES('PWRCDS')
            VALUES('SMARTY')
            VALUES('MRKTLN')
        ;
        QUIT;
%MEND PARAMETERS;
Matt Dixon
  • 11
  • 4
  • You don't use the macro variables in your code anywhere. I don't understand what the issue is here either, you haven't clearly specified it. Note that when you create macro variables in a macro like this, they're created with a local SCOPE, so they don't exist outside the macro. If you need to use them outside of the macro, they would need to be defined as global macro variables. – Reeza Jun 22 '17 at 20:15
  • Thank you Reeza. That was the issue. I was defining local variables instead of global variables. The issue I was experiencing was two fold: 1) Since I only had local variables my code referencing the macro was failing. Since that code was failing, it was also not outputting the table MD_WRK.SUB_ID that was part of the process. That is why is appeared as if the macro was failing completely. It really was just the local variables having a large downstream affect. At any rate, thank you for the help. I have posted the updated code. – Matt Dixon Jun 22 '17 at 22:04
  • Glad you got it working. But for the code you posted, MD_WRK.SUB_ID should be created, with or without the `%GLOBAL` statement. – Quentin Jun 22 '17 at 22:09
  • 1
    Why is that coded as a macro anyway? There is no macro logic being used and it does not take any parameters. – Tom Jun 22 '17 at 23:58
  • @Quentin, it is being created. The code that was running the macro (not shown) was failing out due to not receiving the variable values, so it wasn't finishing and creating the table (I think). – Matt Dixon Jun 23 '17 at 13:23
  • @Tom, no macro logic being used? I am not sure I understand. I coded it this way because PARAMETERS is referenced elsewhere in another program so that I can ensure the variables are assigned without having to rerun my entire process flow (several different pieces). – Matt Dixon Jun 23 '17 at 13:25
  • You can wrap code up into a macro so that it can be executed multiple times. But you can also just use %include to include the same code multiple times. Which is easier depends on how your complete project is structured. The advantage of %include is that you do not have to have the macro processor involved and thus you avoid the complexities of local/global symbol tables. This code looks sort of like something that would be part of a project setup file or an autoexec. For a macro that you want to use the re-set in the middle you might want to also have code to clear things. – Tom Jun 23 '17 at 14:05

1 Answers1

0

When you say "PROC SQL colors change" if you are referring to the color of the code as shown in Enterprise Guide or some other client that does automatic syntax coloring for you, I would just ignore the coloring. There are some small glitches in the syntax coloring, but note that these colors are not part of the code, so even when the code coloring suggests something may be wrong, it will execute fine as long as the syntax is correct.

If you turn on options mprint; and invoke your macro, the log should show that the dataset MD_WRK.SUB_ID was created (or give you an error message explaining why it wasn't created).

As @Reeza mentioned, the macro variables your create are probably being created as local macro variables, so they will not exist outside of the macro. If you were to declare them as %global inside the macro, they would exist outside of the macro, because they would be stored in the global symbol table. But usually there are better approaches then relying on global macro variables.

Quentin
  • 5,960
  • 1
  • 13
  • 21