Specman e: How to pass a verbosity in a variable to a message() action? - specman

I need to set a message verbosity using a variable, e.g.:
my_write(my_verb : message_verbosity) is {
message(BUS, my_verb, vt.text_style(PURPLE, "txt txt txt"));
// other logic
};
This code causes the next compilation error:
*** Error: The verbosity parameter must be a constant of type 'message_verbosity'.
But actually even when I've defined the verbosity as constant field:
const my_verb : message_verbosity;
my_write() is {
message(BUS, my_verb, vt.text_style(PURPLE, "txt txt txt"));
};
I've got the same compilation error.
How the message verbosity can be passed in a variable to the message() action?
Thank you for your help

You are misunderstanding the message verbosity concept.
Every message has a fixed verbosity. Then you control from the prompt, what the unit's verbosity is, which has the message.
The content of the message doesn't change. You want to control, if the unit (with the message) is talking more or less.
You control the unit's verbosity using the "set verbosity ... sys.path.to.unit.inst" command.

Related

com.sap.conn.jco.AbapException: (126) ERROR: ERROR Message 172 of class 29 type E

I am getting below exception while executing the JCoFunction.
JCoFunction functionBOMCreation = destination.getRepository().getFunction("CSAP_MAT_BOM_CREATE"); functionBOMCreation.execute(destination);
Getting this exception
com.sap.conn.jco.AbapException: (126) ERROR: ERROR Message 172 of class 29 type E
at com.sap.conn.jco.rt.MiddlewareJavaRfc$JavaRfcClient.execute(MiddlewareJavaRfc.java:1824)
at com.sap.conn.jco.rt.ClientConnection.execute(ClientConnection.java:1120)
at com.sap.conn.jco.rt.ClientConnection.execute(ClientConnection.java:953)
at com.sap.conn.jco.rt.RfcDestination.execute(RfcDestination.java:1317)
at com.sap.conn.jco.rt.RfcDestination.execute(RfcDestination.java:1288)
at com.sap.conn.jco.rt.AbapFunction.execute(AbapFunction.java:302)**
Generally speaking, when you get AbapException, it means that the called function has explicitly found an error. It may be an error in the arguments you pass to the function or an error due to data in SAP system.
You may possibly receive a message number with it. If so, you may obtain the text by either logging into SAP system manually (via SAP GUI) and run SE91 transaction code to display the messages, or your program can do an additional call to the function BAPI_MESSAGE_GETDETAIL to get the full message text (input parameters: ID, NUMBER, MESSAGE_V1, MESSAGE_V2, MESSAGE_V3, MESSAGE_V4; output parameter: MESSAGE).
In your case, the message ID 172 of class 29 corresponds to the text Enter a quantity. I don't know CSAP_MAT_BOM_CREATE so I can't tell you what exact parameter is concerned.

What does the "pseudo-register number" argument to windbg StopOnException do?

Here's the help text for the windbg command StopOnException (aka soe for short):
0:000> !soe
usage: StopOnException [-derived] [-create | -create2] <type name>
[<pseudo-register number for result>]
ex: StopOnException -create System.OutOfMemoryException 1
What is the argument "pseudo-register number for result" for? The example uses the value 1 but without any follow up.
The only other documentation I can finds says just this:
StopOnException [-derived] [-create | -create2] <Exception> <Pseudo-register number>
Causes the debugger to stop when the specified exception is thrown,
but to continue running when other exceptions are thrown.
The -derived option catches the specified exception and every
exception that derives from the specified exception.
...no mention of this argument at all in the text. Nor any other use of the word "pseudo" on that page, or "register" with the same meaning.
There is additional help text within windbg that does explain it. Took me a while to realize this, maybe it will be useful to others new to windbg:
0:000> !help stoponexception
produces:
!StopOnException [-derived]
[-create | -create2]
<Exception>
[<Pseudo-register number>]
!StopOnException helps when you want the Windows Debugger to stop on a
particular managed exception, say a System.OutOfMemoryException, but
continue running if other exceptions are thrown. The command can be
used in two ways:
When you just want to stop on one particular CLR exception
At the debugger prompt, anytime after loading SOS, type:
!StopOnException -create System.OutOfMemoryException 1
The pseudo-register number (1) indicates that SOS can use register
$t1 for maintaining the breakpoint. The -create parameter allows
SOS to go ahead and set up the breakpoint as a first-chance
exception. -create2 would set it up as a 2nd-chance exception.
When you need more complex logic for stopping on a CLR exception
!StopOnException can be used purely as a predicate in a larger
expression. If you type:
!StopOnException System.OutOfMemoryException 3
then register $t3 will be set to 1 if the last thrown exception on
the current thread is a System.OutOfMemoryException. Otherwise,
$t3 will be set to 0. Using the Windows Debugger scripting
language, you could chain such calls together to stop on various
exception types. You'll have to manually create such predicates,
for example:
sxe -c "!soe System.OutOfMemoryException 3;
!soe -derived System.IOException 4;
.if(#$t3==1 || #$t4==1) { .echo 'stop' } .else {g}"
The -derived option will cause StopOnException to set the
pseudo-register to 1 even if the thrown exception type doesn't exactly
match the exception type given, but merely derives from it. So,
"-derived System.Exception" would catch every exception in the
System.Exception heirarchy.
The pseudo-register number is optional. If you don't pass a number,
SOS will use pseudo-register $t1.
I highlighted the relevant portions.
Essentially, this option allows you to specify which pseudo-register should be used to keep track of the breakpoint. Perhaps in some cases if you don't want to overwrite an existing important value, specifying your own register selection can avoid that.
More info on pseuo-register values: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/pseudo-register-syntax

JasperReports: report parameter as an argument for message bundle lookup

How to look up a particular internationalized property based on a report parameter?
This works, but is static:
$R{some_literal_string}
This works too, but is not internationalized:
$P{key_to_parameters_map_element}
What I need is:
$R{$P{key_to_parameters_map_element}}
Unfortunately, I get a pile of error messages:
Caused by: net.sf.jasperreports.engine.JRException: Errors were encountered when compiling report expressions class file:
1. Syntax error on token "}", delete this token
value = str("$P{key_to_parameters_map_element")}; //$JR_EXPR_ID=13$
This doesn't change anything:
$R{$P{key_to_parameters_map_element}.toString()}
Is this possible at all?
It's
str($P{key_to_parameters_map_element})
Quite intuitive, isn't it?

Error message from filter array

So I have tried to get the error message from a filter array in a logic app workflow, this is what i have tried:
#body('Filter_array')['error']
#actions('Filter_array')['outputs']['body']['error']
Am I missing something or doing something wrong here?
Thanks.
UPDATE:
It says: "cannot be evaluated because property 'error' cannot be selected. ".
But i can clearly see the "error" in the body object in the output.
Ok so i managed to figure it out, i missed the fact that the array doesnt give me a single object as i thought i set it up to. so the solution was this:
#string(actions('Filter_array')['outputs']['body'][0]['error'])
Thanks for the help! :)
Can you try with #actions('Filter_array')['error'] ?
You have to distinguish 2 types of errors.
First error can occur during execution of your connector. Eg. The filter did not match. In this case, the connector executed and returns an output with an error-message.
Second error is a runtime error that can occur on the connector. For example if the input of your connector is invalid and the executing of the connector can't be triggered. In this case, the connector does not generate an output or result. In that case, you have to catch the exception with #actions('Filter_array')['error']

How can Perl's Getopt::Long discover arguments with mandatory parameter missing?

In one of my scripts I use the Getopt::Long library. At the beginning of the program I make a call:
&GetOptions ('help', 'debug', 'user=s' => \$GetUser);
The first two arguments are simple: I discover their existance by checking $opt_help and $opt_debug respectively. However the third argument is tricky, because I need to distinguish between no option at all ($GetUser is undefined, which is ok for me), using "--user" alone ($GetUser is also undefined, but this time I want to display an error message) and "--user FooBar" (where the $GetUser receives 'FooBar', which I can use in further processing).
How can I distinguish between using no "--user" option and using it alone, without a username?
You are looking for : instead of =, so 'user:s' => \$GetUser. From Options with values
Using a colon : instead of the equals sign indicates that the option value is optional. In this case, if no suitable value is supplied, string valued options get an empty string '' assigned, while numeric options are set to 0
This allows you to legitimately call the program with --user and no value (with = it's an error). Then you only declare my $GetUser; and after the options are processed you can tell what happened. If it is undef it wasn't mentioned, if it is '' (empty string) it was invoked without a value and you can emit your message. This assumes that it being '' isn't of any other use in your program.
Otherwise, when you use 'user=s' and no value is given, the GetOptions reports an error by returning false and emits a descriptive message to STDERR. So you may well leave it and do
GetOptions( 'user=s' => ...) or die "Option error\n";
and rely on the module to catch and report wrong use. Our own message above isn't really needed as module's messages clearly describe the problem.
One other way of doing this would go along the lines of
usage(), exit if not GetOptions('user=s' => \$GetUser, ...);
sub usage {
# Your usage message, briefly listing options etc.
}
I'd like to add – you don't need & in front of a function call. It makes the caller's #_ visible, ignores function prototype, and does a few other similarly involved things. One common use is to get a coderef, $rc = \&fun, where it is needed. See for example this post