The Sinclair QL Forum

Hi,

I'd love to follow in the discussion about jobs, started at Arrakis topic.
Basically I now know, a job has to start with the header and terminate itself at the end.
Sample header, bottom of the code area: Sample job exit: The Technical Guide also says that the top of the data area holds channel IDs open for a job before it was activated. This part I do not quite understand, are these IDs filled in by EXEC command?

Many thanks
Tom

Tom,

note the example I gave you started with if you change the "bra" to a "jmp" or a "bra.s", the code will either not properly assemble (jmp) or not show the proper job name (bra.s) when you do a "JOBS" - it is important that the dc.w $4afb starts exactly 6 bytes after the code start.

What's in the data area when a job starts:

A job in QDOS can have channels opened for it when it is started. That is done with the "EX" command (note you need TK2).
will connect S*BASIC #3 to a pipe that talks directly to the job, the channelId of that pipe will be handed over to the job in the data area. Anything you "PRINT" to that channel can then be directly read by the job (By calling IO.FBYT with the channel id, for example).

Another possible S*BASIC example would be (If you know a bit of UNIX, something along the line of Would do pretty much the same)

- Provided the programs are written to do what they are expected to, list_exe would list a file, pipe it into paginate_exe that would add page and maybe line numbers, piping it in turn to print_exe that would finally print it to the printer.

With a command line as above, EX creates the channels and hands them over to the jobs (both for input and output). A job that finds such arguments, could (doesn't need to, the channel handling is actually not mandatory) do as above.

The command line argument "flp1_program_asm" above would also end up in the data space as a normal string, after the channel ids. There it is ready to be picked up by the job just started. A nice way to hand over arguments to jobs, like the name of the file to list, as in the example above.

Hope this helps
Tobias

Tobias,

Ah, these are the pipes, now I see.

Sorry, I will stick to bra job_start, but ...

I was curious and tested these three variants, all leave $4afb at 6 byte offset, when job_start is close to code beginning, GST Assembler gives warnings about short branches be used instead. JOBS command reports them equally well with the job name, RJOB works on them too.

bra job_start bra.s job_start jmp job_start I also learnt that the code has to be padded to even size, otherwise it has problems executing, at least on my JS-ROM.
Many thanks
Tom

Tom,

as long as you are aware that you need to insert the correct # of padding bytes between the branch and the $4afb, it actually doesn't matter much what type of branch you use

The issue behind the job crashing when the code length is odd, has actually nothing to do with the code as such. The point is that the job allocation code in QDOS will place the data space at the next byte after the last byte of code - At the other end of the data space, it allocates the stack and the channel and command line parameters - If the data space starts at an odd byte, all that will also be allocated at an odd address and will crash the job as soon as the stack is referenced.

Have fun,
Tobias

This might help with the channels etc, http://qdosmsq.dunbar-it.co.uk/download ... ge_001.pdf and there are a couple of minor corrections here, http://qdosmsq.dunbar-it.co.uk/download ... ge_002.pdf.

HTH

Cheers,
Norm.