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

[J.Beckeringh@xxxxxxxxxxxxxxxxxxxxxxxxxx]

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