.PAPER SIZE 60,80 .LEFT MARGIN 8 .RIGHT MARGIN 72 .SPACING 1 .CENTER 72;CATCH-ALL TASK FOR UNMODIFIED RSX11M V3.2 .CENTER 72;========================================= .AP There is a very large scale of services the ...CA. may provide, and only one limitation: .LIT - it must work fast, never wait for anything to complete, to be EVER ready to process new command. .END LITERAL 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 tasking. No modifications to INS !!! It's table-driven, so faster than any file-oriented, and is capable to pass the unknown command to THIRD commands dispatcher. .FG 1 The fly of unrecognized MCR command through CA starts with search of dynamic-installable tasks table. .LIT 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). .END LITERAL 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 dynamic 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 includes enhanced TCF (Terminal Control Function) command, and current table provides substitution of broad DCL commands subset, and simplified form for many frequent standard MCR commands. 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. .TP 7 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: .LIT - complete commands are converted by SCP (very fast) - commands with any parameter missing are passed to CCL which prompts for missing parameter. .END LITERAL 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 allmost 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. .LIT 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