On 13 May 2004 at 22:42, Arnould Nazarian wrote: > 10 JOB_NAME test > 20 REPeat:PRINT 'Hello World' > > 10 JOB NAME launcher > 20 EX 'test' > 30 EW 'test' > > > When I > > EX 'launcher' > > in my SMSQ/E from SBASIC 0,0,0, then the 'test' job that was EXeced > belongs to SBASIC 0,0,0 and the 'test' job that was EWed belongs to > launcher. > > It is the first time I use such features, and after 20 years of readings > about QDOS, I had the impression that both 'test' jobs would have > belonged to 'launcher'. > > One (slight) drawback of that behavior is that I can not simply > > RJOB 'launcher' > > to get rid of the 3 jobs. I must also RJOB 'test'. > > Today I have finished a chain/tree of 18 filters which work from 3 input > files, create 3 temporary files and output 3 result files for my job in > order to interpret data coming from a large but unflexible IBM AS-400 > computer. Some of the jobs are EWed, some are EXeced from a launcher > job, but the complete job tree does not belong to 'launcher'. I am > surprised. > > Arnould You shouldn't be... :-)
It's actually pretty logical (at least to me). When you EW a prog, then you say that you want the job that EW'd this prog to wait until this prog ends. There is thus a definite relationship between the prog and the job. Hence the owner of the prog is the calling job, and, when it activates the prog, it signals that it has to wait until completion of the prog. There is a relationship between both. However, when you EX a program, there is not necessarily any relation between the calling job and the prog that is being EX'd. Example: I routinely launch programs from the command line in an Sbasic daughter job (I practically never use job 0). Do I want these programs to go away when I close this particular Sbasic ? Definitely not!!!! So the keyword was designed that way. What you want is that the EX'd prog be owned by the launcher job, which uis what I definitely wouldn't want. The only solution I can see would be a new keyword. How about "EX_M" (EXec with Me as owner)? This could be a trivial change that I could build into the next version of SMSQ/E. Would that solve your problem? Wolfgang _______________________________________________ QL-Users Mailing List
