In order for a process (and its children) to submit to background, two conditions must be met:

The --- SUBMIT PROCESS flag must be set to "Y".
The "Separate Task?" flag must be set to "Y".
The predefined field "--- SUBMIT PROCESS" can be set either of two ways:

In a Disposition Process.

In APPX 4.0, the enduser interactively selects Optional Child "1) Submit to Background" when Disposition is active.

--- SUBMIT PROCESS has a "scope" of 'RELATED'. This means that SUBMIT PROCESS can survive SUBPROCESS and RELATED process invocations, but not a DETACHED invocation.

MENU invocation of JOB and other processes are typically DETACHED. JobStep invocations are typically RELATED. Optional and Automatic children within an INPUT process are typically SUBPROCESS. Processes called from ILF are typically DETACHED.

In order for "--- SUBMIT PROCESS" to have an effect upon a subsequent "Separate Task=Y" JobStep, it can not pass through a DETACHED invocation.

The Separate Task flag is usually set in a JOB process' Job-Step's "Sep Tsk?" Y/N attribute. (See Help text there.)

Setting the Separate Task flag to "Y" means that process runs in a completely separate environment, whether it runs in background or not. This means you can pass information *into* it, but you cannot get anything back from it, except for DISK PERMANENT files.

A potential "gotcha" is if you set --- SUBMIT PROCESS in a JobStep whose "Sep Tsk?" flag is set to 'Y'. Since no information can flow back from that 'Sep Task=Y' JobStep, changing --- SUBMIT PROCESS's value in that JobStep would not take effect in subsequent JobSteps.

Again, both --- SUBMIT PROCESS and 'Separate Task' must be set to 'Y', in order for a process (and its children) to spawn itself into a separate background process.

When it is determined that a process will spin off into background, a 'session' file is created. It contains information defining the current 'context' of the APPX session. This would include such things as the currently selected database, the current process, child constraints, all workfields and copies of all memory- and disk-temporary files, etc.

On Unix systems, a submit script ($APPXPATH/appx_script) is executed. The script can be overridden by the environment variable APPX_BG_SUBMIT. Passed to this script are various fields from the disposition as well as the name of the 'session' file.

The submit script executes a new copy of APPX with the 'session' file passed to it. This provides the initial context in which APPX will run.

Other comments:
A useful explanation from Jean Neron:

When you set Seperate Task to "Y", you are telling APPX this job step *could* be run in background, if the user requested it via a Disposition.

Lets take a couple of examples. Here's a simple report type job:

INPUT <get report params>
QUERY <allow user sort/select>
DISPOSITION <set print options, etc, and background processing>
OUTPUT <some report, with Separate Task = "Y")

If the user requests background processing, then when APPX hits the last OUTPUT, it should run it in background.

NOTE: Setting Seperate Task to "Y" means that process runs in a completely separate environment, whether it runs in background or not. This means you can pass information *into* it, but you cannot get anything back from it, except for DISK PERMANENT files.

Now, what if your job has several steps that you want to execute it background? You need to create a separate job that contains those steps and invoke that job from the first, with Seperate Task turned on:

JOB1:

INPUT <some params>
DISPOSITION <usual stuff>
JOB2 <runs the rest of it, with Separate Task turned on>

JOB2:

UPDATE <some file>
OUTPUT <some report>
UPDATE <some other file>
OUTPUT <some other report>
OUTPUT <some other report>

Note that if a query does not require any user input, it is not necessary to specify it as a job step. You simply fill in the Use Query on the job steps that need the query. The UPDATEs and OUTPUTs in JOB2 could all be using different queries, even tho' I didn't show anything in my example.

It's not necessary to use a disposition just to change forms. If you know what the form is going to be, you can just set --- PRINT FORM ID in the pre invocation event point for the OUTPUT at the JOB level.

More useful explanation from Tom Gilbride:

Submitting something to the background under Windows simply fires off another APPX session that runs the job. In some cases, the focus may remain on the 'background' job, in which case you can ALT+TAB to get back to your original session.

In some situations you need to set --- SUBMIT PROCESS = 1 using code.

I believe Bruce Johnston's utilities (BJUTILS) have a background job manager that I think let's you manage background jobs like the Wang VS OS, but I haven't had a chance to try it yet.