×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 09-Sep-2011 14:34 , Vinay Gavankar wrote:
<<SNIP>> I changed the program as follows, and it seems to work:
PGM PARM(&MBR &FLG)
DCL VAR(&MBR) TYPE(*CHAR) LEN(10)
DCL VAR(&FLG) TYPE(*CHAR) LEN(1)
DCL VAR(&CMD) TYPE(*CHAR) LEN(42)
CHGVAR VAR(&FLG) VALUE('0')
CHGVAR VAR(&CMD) VALUE('*nlvlibl/addpfm literal' +
|| '/literal ' ||&MBR)
CALL PGM(QCMDCHK) PARM(&CMD 42)
MONMSG MSGID(CPF0000 CPD0000) EXEC(DO)
CHGVAR VAR(&FLG) VALUE('1')
ENDDO
EXIT: ENDPGM
The command string I had given intended to exhibit two aspects of the
invocation for syntax-check.
One aspect shown is the library list. Consideration for how best the
command should be qualified could be important; possibly either *system
or *LIBL might be more appropriate than *NLVLIBL.? Since the original
message suggested that some add member activity would occur later using
the &MBR value, the validation of which command would best match the
eventual command invocation.
A second aspect was that the FILE() parameter could be specified both
as any valid literals with a name qualifier and positionally. Note
however that the parameter could have just one value with the defaulted
library, such as FILE(A) instead of FILE(A/A).
A third aspect which I failed to explicitly include was the MBR() as
a named parameter; instead, that was shown positionally. To best
validate the MBR() parameter, the value passed should be placed inside
that named parameter instead of positionally. Specifying the parameter
name enables detecting the difference between the invocations: "addpfm X
MBR(Y Z)" and "addpfm X Y Z".
Thus, I might instead choose to set the command string to:
VALUE('*nlvlibl/addpfm X/Y MBR(' *CAT &MBR *CAT ')')
Note: Using *CAT prevents potential difficulties for CCSID
translation for the 'bar' characters.
FWiW I prefer to monitor only for the expected conditions. For the
given command string only CPF0006 should be expected, and anything as an
unexpected condition might best effect the unmonitored escape handler;
i.e. instead of a coded assumption that the MBR(&MBR) is invalid due to
an unknown\unexpected error. Also note that the CPD0000 range of
messages are unlikely to be issued as an escape or status message, even
if there were other possible messages; I would remove that from the
MSGID() of MONMSG.
Regards, Chuck
midrange.com
