NonStop Servers
1827835 Members
9097 Online
109969 Solutions
New Discussion

NonStop #DEF macro does not accept parameters

 
Kee_aus
Advisor

NonStop #DEF macro does not accept parameters

#DEF macro does not seem to resolve its parameters %1%, %2% etc. anymore. Wrote a little short macro and it does not work. 

?tacl macro
[#DEF listparam MACRO |BODY|
#output %1%
]
listparam abcdefg

Run the above and I expect to see the output and got nothing. If I do this, below (load and run listparam)  it works. I expect this to be the same. Both are macros.

?section listparam macro
#output %1%

 

4 REPLIES 4
Mr_Techie
Trusted Contributor

Re: NonStop #DEF macro does not accept parameters

Hi @Kee_aus

You may refer the below link for more information: https://support.hpe.com/hpesc/public/docDisplay?docId=a00045838en_us&page=id-21359.html&docLocale=en_US

The behavior you're encountering with TACL macros seems to stem from the difference between how inline #DEF macros and macros defined in sections (?section) are resolved and executed.

Here's how you can fix your test case:

?tacl macro
[#DEF listparam MACRO |BODY|
#output %1%
]
listparam abcdefg

This works only when you explicitly invoke listparam abcdefg. Alternatively, ensure you define and test inline execution clearly:

?tacl macro
[#DEF listparam MACRO |BODY|
#output %1%
]
#CALL listparam abcdefg

?tacl macro
[#DEF listparam MACRO |BODY|
#output %1%
]
#CALL listparam abcdefg


Or, to align with ?section behavior, define and execute immediately:

?tacl macro
[
#output abcdefg
]

If you want the ?section macro and #DEF macro to behave identically, always explicitly invoke #DEF macros after definition.

I hope this helps. Let me know

Kee_aus
Advisor

Re: NonStop #DEF macro does not accept parameters

Thanks for the reply. Yeah the reference as said doesn't make this clear or how it is resolved. Is #CALL a TACL builtin? I just got a syntax error. 
The whole idea is to pass a parameter, obviously '#OUTPUT abcdefg' works. My macro is much more involved than this but reduce this down to a simple case to show that it is not consistent. The reference says 

MACRO

specifies that variable is a TACL macro.

And it should behave like one. 

Mr_Techie
Trusted Contributor

Re: NonStop #DEF macro does not accept parameters

@Kee_aus 

You're absolutely right—TACL documentation can be ambiguous when it comes to the behavior of #DEF macros, particularly around parameter resolution. Let's clarify the concepts further and address your points:

1. Is #CALL a TACL Built-in?
No, #CALL is not a TACL command or keyword. I mentioned it incorrectly earlier, and I apologize for the confusion. TACL doesn't need a separate #CALL command to invoke a macro; you simply call the macro by name. For example, after defining listparam using #DEF, you invoke it directly by its name and pass arguments: listparam abcdefg

2. The MACRO Behavior
When a variable is defined as a MACRO, TACL treats it as a template that can accept parameters (e.g., %1%, %2%) at runtime. However, defining the macro with #DEF doesn't execute it—it merely stores the definition. You must call the macro explicitly for parameter substitution to occur. Here's a minimal example: 

?tacl macro
[#DEF listparam MACRO |BODY|
#output %1%
]

listparam abcdefg

Out put: abcdefg

 

3. Why Doesn't It Behave Like ?section?- The ?section keyword works differently because it loads and executes the code immediately when the section is loaded. 

4. Why Does It Seem Inconsistent? - This inconsistency arises because TACL evaluates macros and sections at different times:

#DEF: Creates a reusable macro, executed only when explicitly invoked.
?section: Executes immediately, with no reusability unless explicitly designed.

 

Am not a expert here, just found the information for you. Let me know if that helped? 

Kee_aus
Advisor

Re: NonStop #DEF macro does not accept parameters

2. The example you provide will not work. That was my original example to show it does not output that value.

3. This isn't true. If it is true then the load would have produce a syntax. It only errors if run.
Example:
\TAND1 $AUD01 TEMP 71> load /keep 1/ tst1
Loaded from $AUD01.TEMP.TST1:
LISTPARAM
\TAND1 $AUD01 TEMP 72> fup copy tst1
?section listparam macro
rubbish text
2 RECORDS TRANSFERRED

It is fine, it is what it is. Just inconsistent. TACL is interpretive, it only evaluates when it is asked to evaluate.