The SERVICE_GET command allows JSM client applications to access the keyword / value properties from the properties file associated with the currently loaded service.
Client applications can access the value of properties associated with the service, but, perhaps more usefully, they can access application specific property values too, using the service properties file as a common medium for holding such values. When used in this way, there is a possibility of conflict between application-defined keyword names and those used by LANSA Integrator. To reduce the possibility of conflict, your application should prefix the property keyword with a global unique name. The examples below use com.acme.property as the prefix for this purpose.
The service property keyword value is returned in the JSM message field. If the keyword does not exist, then a status of NOT_EXIST is returned.
SERVICE_GET -------- PROPERTY ----- value -------------------->
>-- TRACE ------- *PATH ---------------------|
Provide a keyword / value to be checked on the service properties file.
The service property keyword value is returned in the JSM message field. If the keyword does not exist in the service property file a status of NOT_EXIST is returned.
*PATH – get trace folder path.
*SERVICE - read service trace file.
*TRANSPORT - read transport trace file.
The examples retrieve the value of the com.acme.property.messagetype (an application-defined property) in the service properties file. This property might be defined in the service properties file with a line like this (the value "html" will be returned to the application in this case):
USE BUILTIN(JSM_COMMAND) WITH_ARGS('SERVICE_GET PROPERTY(com.acme.property.messagetype)') TO_GET(#JSMSTS #JSMMSG)
#jsmcmd := ' service_get property(com.acme.property.messagetype)'
use builtin(jsmx_command) with_args(#jsmhandle #jsmcmd) to_get(#jsmsts #jsmmsg)