Re: WDSC doesn't know an interactive command when it sees one

David,

Based on your findings I wasted some more time on this nonsense (because
it is kind of fun), and found out:

GO: I assumed it was accepted, but that is not quite true: Just GO or GO
with a space is accepted; as soon as you type anything after the space the
whining starts.

STR: When you type 'STR' WDSC starts to moan. When you stubbornly go on
and a) end the command with SVR, b) specify 'output (*print)', c) specify
'outfile(<something>)' or d) complete the command as STRSEU and specify
'option(6)' WDSC stops moaning.

Why on earth would someone program this, while you only have to
investigate the *CMD object to know for sure?

Joep Beckeringh


wdsci-l-bounces@xxxxxxxxxxxx wrote on 08-04-2008 17:05:40:

J.Beckeringh@xxxxxxxxxxxxxxxxxxxxxxxxxx wrote:

I would be perfectly happy if WDSC looked at the ALLOW property of the

command, but it doesn't.

FWIW: I poked around in WDSC and found the terms "GO ", "EDT", "STR",
and "WRK", hard coded in the CmdSubSystemImpl.class file.

I'm assuming this class is checking the command name being entered to
see if they begin with any of those terms and stopping the command if
you don't have the interactive job hook active.

I also found the constants "SVR", "DSP", OUTPUT(*PRINT)", "STRSEU", and
"OPTION(6)" in the file ... so I'm guessing it will allow you to start a

server and (possibly) print a member, without requiring the interactive
job hook.

david

--
IBM System i - For when you can't afford to be out of business