Re: Expanded Command Line; // to prefix commands

The '//' prefix to a command [statement] indicates that the /statement/ is a Job Control Statement [i.e. JCS] as with Job Control Language [i.e. JCL] like on mainframe operating systems. This operates theoretically much like described below with OCL in the S36E, such that when the /statement/ is not known to be valid\for Job Control, it is essentially forwarded [without the prefix] to the Command Language processor. I think that it really is just the CL processor accepting the input from the job spooler, which effectively just ignores the prefix. Unlike OCL however, the space character is not required between the two slashes as prefix and the statement that follows; i.e. for the given example of // DSPJOB, apparently //DSPJOB functions equivalently.

I have only ever used //bchjob //data & //endbchjob but there is another //endinp and perhaps others; these four are those I know of with both limits to only *BATCH and a restriction stating either that the "command cannot be entered at a work station" or the "command cannot be run from a work station".

sbmdbjob strdbrdr strdktjob & strdktrdr are the commands that I know of which start a spooler job [input spooling; optionally by a /reader/] against data from a device or file as /batch stream input/ to perform the interpreted CL which may optionally include some /inline data/ file(s).

Regards, Chuck

Mark S. Waterbury wrote:

But, I am not running in the S/36 Environment (never have, never
will...) ?

I never worked on a "real" System/36 either. I came over from IBM
mainframes (MVS, VSE, VM) directly to OS/400 circa 1989.

Douglas Handy wrote:

You can type "//" at the beginning of pretty much any OS/400
command,

Mark wrote:

for example, type:

// DSPJOB

on any command line and then press Enter.

It just ignores the "//" in this case.

What it actually does is try to parse it as an OCL statement
(which on the S/36, begins with //) and when the next word is
not a valid OCL command, will look for a command by the same
name. This is because the S36EE lets you embed native commands
in OCL procedures.

You'd have a problem if your command name happened to match a
valid OCL statement because then it would be parsed as if OCL
instead of a command.