So, in order to allow users to RESPR additional extensions after loading the Ser-USB driver, I changed the mechanism for the way in which it starts its Queue Manager task. It was quite elegant, really: setting a flag bit the first time that Queue Manager services were needed to be picked up later by the scheduler loop task which would start the manager.
Under SMSQ? No problem. Sorted. Under QDOS? BLAM!!!!!!!! *&*^%%^$£$£ Now I have probably missed some important piece of documentation somewhere that says you're not allowed to do trap 1, mt.cjob in a scheduler loop task under QDOS, but you are allowed to in SMSQ. The QDOS documentation that I have doesn't say that you can't do this - but, fair enough, thinking about it I suppose the call would mess with the job table and might muck things up when a return is made to the scheduler. OK, that's that, it can't be done. I accept it. I'm moving on. But what I would really like is some kind of document that sets out a list of things that fall in the category: "This should work under QDOS, it says it should, but it doesn't but we went ahead and fixed it in SMSQ" This is not just for me, but for any other poor sod who has to try developing system level code to run under both platforms. This is not the first time that I've encountered things that should work under QDOS but don't, yet they work fine under SMSQ. It's fixed now. The QDOS "underclass" will have to manually issue a USB_START command after they've loaded any other extensions, while SMSQ users can be confident that the driver will automatically start queue management when needed. Further down my list is to start testing under Minerva. I'm dreading it. :( Adrian _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
