CATCH-ALL TASK FOR UNMODIFIED RSX11M V3.2 ========================================= There is a very large scale of services the ...CA. may provide, and only one limitation: - it must work fast, never wait for anything to complete, to be EVER ready to process new command. For example, CCL from the KMS Kit is very good, but wizzards very often get MCR -- TASK ACTIVE message when trying to use CCL command before the previous one completed, and you have large ...CA. active for the whole time. Following CA. combines approaches from many sources. It is possible to implement it without applying patch to DRSPW (SPAWN with EFN=-1) and it works in the same way. Conditional code allows CA usage on system without parrent-offspring task- ing. No modifications to INS !!! It's table-driven, so faster than any file-oriented, and is capable to pass the unknown com- mand to THIRD commands dispatcher. The fly of unrecognized MCR command through CA starts with search of dynamic-installable tasks table. If match, install this task, que original command line to it, request task marking it for remove on exit, pass OCB to it and immediately exit CA. Or search the table of commands processed by indirect files processor (AT. or any other PIN). If match, chain MCR using appropriet command and immediatelly exit CA. Or call SCP (Substituted commands parser) to try substitution of original command to any other predefined. If match, chain MCR with substituted line and exit CA. Or chain the third commands interpreter - ...CCL. Currently we use original CCL from KMS-Kit (except DCL part). Dynamic install significantly reduces pool requirements (approx. 32 words per task), and you may use all tasks you wish as direct commands, passing MCR command lines to them. Since we use non-standard priority schema to break shuffling to death, and sub-systems spread in various directories, the table for dy- namic install specifies also priority and directory to be used. The table-driven SCP provides very simple and effective tool to define application-specific commands. It internally in- cludes enhanced TCF (Terminal Control Function) command, and current table provides substitution of broad DCL commands sub- set, and simplified form for many frequent standard MCR com- mands. Commands, which can't be processed by SCP, (for example if required parameter is missing), may be returned to CA to pass them to THIRD command dispatcher. PAGE 2 Combined approach of very fast, table driven SCP and very flexible CCL seems to be best solution to all command-language problems. For example, our DCL implementation has two levels: - complete commands are converted by SCP (very fast) - commands with any parameter missing are passed to CCL which prompts for missing parameter. Some DCL commands require more parsing logic, than current CCL provides. Such commands (LINK,COMPILE,COPY) we process using reduced version of AT., installed as ...DCI. Since it is all- most allways stopped and out of memmory, I don't worry about it's size. The table driven ...CA. task requires relinking for every change of tables, but CAGEN.CMD command file does all necessary, including VMR mofification of saved virgin system. Overall CA task size (incl. SCP and tables) for dynamic install of approx 80 tasks, DCL support etc. is only 2kW. Complete CA/CCL set consists of self-doccumenting files: CAGEN.CMD - build or modify CA CCLGEN.CMD - build modified CCL SCPGEN.CMD - build substituted commands tester CA.MAC - CA source SCP.MAC - SCP source CATAB.MAC - CA tables for dynamic instal SCP CCL.MAC - modified CCL source SYSCCL.CCL - system CCL commands file LINK.CMD,COMPILE,COPY - complicated DCL commands Ing.Martin Brunecky Drobneho 28a 60000 BRNO Czechoslovakia