RSX-11M TO RSX-11M-PLUS MIGRATION ---------------------------------------------------------------- SUBJECT: RSX-11M TO RSX-11M-PLUS MIGRATION AUTHOR: Allen A. Watson Manager, Systems Technology BERGEN EVENING RECORD 150 River Street Hackensack, NJ 07602 (201) 646-4111 ---------------------------------------------------------------- TABLE OF CONTENTS GOES HERE 1.0 Reasons for going to M-Plus 1.1 Shadow disk Our main reason for migrating from RSX-11M to RSX-11M-PLUS was the added capability of what is called "shadow disk". We have been, and still are, developing several large applications that will be handling volatile and sensative data: an advertising accounts receivable package, a display advertising layout package, and a newspaper circulation package. All of this data is changing rapidly from day to day. Some of it, such as the ad layout data, is critical to the daily production of the newspaper. In the newspaper computing world we have a saying: "THERE IS NO TOMORROW." In most computing applications in the event of disaster it is possible, although not desirable, to "do it tomorrow". Getting out payroll a day late may be expensive, it may cause alot of discontent, but in the worst case it can be done. Producing Tuesday's newspaper on Wednesday, however, simply cannot be done. For a newspaper, there is no "tomorrow". For applications involved in the production of the paper, therefore, data backup is imperative, and recovery in case of disaster, such as a head crash, must be nearly instantaneous. Typically, in newspaper applications, five minutes is considered a maximum recovery time. It may be nice in movies about newspapers to have someone screaming "Stop the press!", but in real life stopping the press is about the last thing you ever want to do. To stop the press because the computer has lost data necessary to the production of the next pages would cost so much that you could RSX-11M TO RSX-11M-PLUS MIGRATION Page 2 buy a complete secondary computer with the money. In fact, almost every paper I am familiar with has totally redundant computer hardware for just that reason. What we needed was dual recording of critical data on two identical disk packs , so that if a head crash occurred, all that would be necessary to recover would be to boot up from the second disk. That is what "shadow recording" is. A complete, up-to-the-second, mirror image copy of your disk is maintained on another disk mounted on another drive. We briefly considered a transaction log type of system, where any updates to files would be logged onto a disk or a mag tape. This required a lot of support software: each application would have to handle its transaction logging, programs would have to be written to recover from transaction logs and periodically purge them, and so on. Any new application would have to include support of transaction logging, making all the applications larger. We rejected this approach in favor of M-PLUS and shadow disk because shadow disk is transparent to the application and requires no additional code. A nice side benefit of shadow disk from the viewpoint of operations is that it eliminates the need to copy the disk you are shadowing; you have a constant, on-line copy. In our brief experience with shadow disk, we have found that it adds little overhead to the system, especially when you funnel the shadow disk through a separate controller using a unique ACP. Remember, however, that if you have four disks you want to shadow, you will need eight disk drives! If the ability to recover from a head crash in five minutes instead of an hour, or much more (you know what it would take at your site) is worth the price of another drive, you should consider using M-PLUS shadow disk. At THE RECORD we have experimented with combining the Virtual Disk package from the RSX SIG tapes with shadow disk. This allows us to designate selected sets of files that have been assigned to virtual disks, which are located on several disk drives, for shadowing on a comparable set of virtual disks that have been located on a single "shadow" drive. We have limited the files to be shadowed to the critical few, instead of duplicating entire disk packs, and have been able to reduce the number of drives needed to shadow those files. I will be discussing this aspect of shadow disk in a separate session Thursday afternoon at 4:30. RSX-11M TO RSX-11M-PLUS MIGRATION Page 3 1.2 Overlapped seeks for disk M-Plus supports overlapped seeks for disk. This feature allows multiple disk units attached to a single controller to perform seeks (head movement) simultaneously, although only one data transfer can occur at any one time. Most advanced disk controllers support this feature, as ours do. Since we anticipated an operations environment where up to eight drives might be accessed through a single controller, it seemed to us that overlapped seeks would be a considerable help to disk throughput. In our current operations we rarely have more than two drives operating through a single controller, and in most cases we are operating on just one drive, so we have no concrete data yet on savings through overlapped seeks. 1.3 Supervisor mode libraries Available only on 11/70's and 11/44's under M-PLUS, supervisor mode libraries are resident libraries that double a user task's virtual address space by mapping the instruction space of the processor's supervisor mode. That was a near quote from the Executive Reference Manual. For those of you who haven't yet learned to speak DEC, let me give a rough translation. A task or program under RSX-11M is only allowed to have 32K (roughly 32,000) locations of memory to run in because the hardware can't count any higher than that. Supervisor mode is like a second counter, allowing another 32K locations to be used. For a little memory overhead in your program and some run time overhead when your program has to switch modes to get at the stuff in the supervisor mode library, you can double your program size. That was important to us because we are converting a number of programs from an IBM 370 with virtual memory to run on our 11/70. Most of them were just too big to run without overlaying and breaking them up into subtasks, with the attendant overhead in increased execution time. Supervisor mode libraries give us the ability to build bigger tasks. In addition, many of the DEC utilities can be built using a supervisor mode library for File Control Services (FCS). That makes those commonly used programs smaller, and for the larger ones that require a lot of overlaying under RSX-11M, allows DEC to reduce the overlaying, thus reducing the number of overlay calls from disk. In sum, the utilities are smaller and run faster. The option of building FCSFSL utilities is offered during SYSGEN and I RSX-11M TO RSX-11M-PLUS MIGRATION Page 4 advise you to take it. 1.4 Secondary pool Under RSX-11M we had frequent system crashes when we ran out of pool. For you new users, "pool" is a space in the executive used by the system as a work area to contain data structures such as system lists, control blocks, and I/O packets. Every file that is open has a file control block in pool; each installed task has a task control block; active tasks have task headers in pool; each terminal has a user control block, and so on. There's a lot of stuff in pool and only a limited space in the Exec. When it fills up, the system crashes. How many of you RSX users have experienced that problem? Before M-PLUS we tried lots of tricks to get more pool or to keep from crashing. We installed the Pool Monitor Task from the SIG tapes; we put in patches from Jim Downward at KMS Fusion that allowed us to run with fewer tasks installed; we put in a patch to the terminal database to reduce the number of SCB's for terminals. Each thing helped a little, then we'd run out of pool again as the load increased. Under M-PLUS we have yet to come close to running out of pool space. One of the main reasons is secondary pool. Secondary pool is a memory partition that is outside of the Executive, and it can be as large as you want. M-PLUS uses it for more permanent or less frequently used data structures, and thus frees up that space in primary pool. Task headers, for example, go there, so under M-PLUS there is almost no limit to the number of tasks you can install. We had a pool problem under M; no longer. We come up with over 11,000 words of primary pool. We'll run out of memory long before we run out of pool. PMT seems almost superfluous under MPLUS. But we can (and will) buy more memory! and you could never buy more pool. 1.5 Directive common Directive common is another way you get more pool space; some of the executive directives are moved into a common partition thus freeing up more space in the exec. RSX-11M TO RSX-11M-PLUS MIGRATION Page 5 1.6 Multi-user tasks Our system has lots of users. We anticipate having up to 52 terminals on a single 11/70. That many users can fill up memory with tasks awfully fast. M-PLUS allows the building of multi-user tasks, in which a single copy of read-only portions of a task is shared by many users. Even on our development system, the multi-user versions of EDT and PIP have helped reduce checkpointing in the system. We are making some of our application tasks multi-user also. 1.7 Multistream batch processing We wanted batch processing so that users could schedule long, time-consuming tasks to be done in off hours. Batch allows you to do this. In effect you submit a command file to the queue manager just like a print job: SUBMIT MYJOB/AFTER:17:00. Also, when development gets really heavy we can ask users to submit jobs to batch streams rather than running them directly, thus limiting the number of simultaneous compiles and task builds. 1.8 Task and user accounting capability We expect our system to overload before long even under M-PLUS. When that happens we will be able to use the resource accounting facility to determine which tasks are overloading the system, and with what kind of activity: CPU, disk, QIO's, etc. It is possible we may develop a charge-back system to our user departments. 2.0 Transition process from M to M+ I would say we had a rough transition, but largely because of two factors: first, we elected to migrate at exactly the time DEC was discontinuing Version 1.0 and starting on Version 2.0. For several months we couldn't get either version from them. Finally they delivered Version 1.0; about six weeks later, we got Version 2.0. We had barely adjusted to Version 1.0! Second, we had all non-DEC disks and disk controllers. It's very hard to SYSGEN a system when you can't run any of your disks on it. We ran our Version 1.0 GEN from our RSX-11M 3.2 system, and then GEN'ed our Version 2.0 using the Version 1.0 system. Before RSX-11M TO RSX-11M-PLUS MIGRATION Page 6 starting the GEN, we had to modify SAVE, the DB driver, other utilities and the SYSGEN command files to compensate for our foreign controllers. It was frustrating because we spent weeks debugging code for the disk sub-system without being able to see the new system at all. We read the manuals and dreamed great dreams; meanwhile we couldn't even boot the thing. If I were back buying our system in the first place I would include at least one standard DEC disk system for doing SYSGEN's if for no other reason. One nice thing is that DEC had included very clear instructions on how to GEN a Version 2.0 system from a Version 1.0 base -- just what we needed. They even have a special command file for doing it, letting you build the Version 2.0 versions of MAC, TKB and IND that you need for the GEN on your Version 1.0 system. We did it and it works. In general the Version 2.0 SYSGEN manual is much clearer and the SYSGEN procedure is much simpler than any I have done before. Autoconfigure is a new thing DEC has added that eliminates the messiest part of a SYSGEN: specifying CSR's and vectors for all your hardware. Autoconfigure just goes out there, probes around the system to figure out what hardware is attached, and generates all that stuff for you. It then allows you to examine and edit the results in case it goofed or left out something it couldn't recognize. If you have a system put together by DEC with mostly DEC hardware, use autoconfigure; or if you know your CSR's and vectors meet their standards, use it. Our CSR's and vectors are definitely non-standard even for the DEC gear (the system was put together by an OEM) and we found it more convenient not to use autoconfigure, so I can't say how it works. 3.0 Problems encountered in SYSGEN 3.1 Bug in Building the Executive The command file SGNBE.CMD has a bug in it that DEC knows about. When the exec finishes task building the command file attempts to wait for the cross-reference to complete with the statement: .IFINS CRF... .WAIT CRF... For some reason this causes an error message saying "SPAWN FAILURE" and the SYSGEN command file aborts. The only thing that fails is the indirect command file. The task RSX-11M TO RSX-11M-PLUS MIGRATION Page 7 build of RSX11M has worked fine. All you really need to do is make sure CRF has finished and continue with the GEN. I checked SGNBE.CMD and the only remaining executable line was "TKB @DRIVERS". So I typed that in directly, waiting for it to complete, and then re-started the SYSGEN at the next phase after "Build the Executive and Drivers". Worked fine. You could modify SGNBE.CMD (see note on SYSGEN command files below under "Hints from our Experience") by commenting out the line at fault and replacing it with a .PAUSE. When it pauses, just check active tasks. If CRF... is not active, then resume. DEC software support suggested removing CRF... before starting the build of the exec, but that seemed counter-productive to me. 3.2 Getting correct versions of N.P. tasks Pay close attention to the NOTE on page 3-63 of the SYSGEN manual. If you make any changes to the task build files to select options on some of the non-priveleged tasks, and you fail to move them from [1,54] to [3,54] after they are built, you won't get your tailored versions of those non-priveleged tasks when you bring up the system. The versions of those tasks from the distribution tape are in [3,54]. The versions you build, for some reason, go into [1,54]. When SYSGEN creates SYSVMR.CMD file it specifically installs non-priveleged tasks from [3,54] so you get the DEC originals, not the ones with the options you so carefully chose. DEC should build non-priveleged tasks into [3,54] if that's where they expect them to be, and I have complained to that effect in an SPR. 4.0 Helping the users adjust Some of these things probably apply equally well to new users of RSX-11M Version 4.0. In general the transition for the users of our system was painless, but not without some effort ahead of time and behind the scenes. 4.1 Getting used to DCL For someone coming to M-PLUS from M Version 3.2, DCL is something new. We elected to put in DCL as the primary Command Line Interpreter (CLI) and to modify the task build file (see below) to select the option to allow any unrecognized commands to fall through to MCR. If you don't do that, any user of DCL is going to RSX-11M TO RSX-11M-PLUS MIGRATION Page 8 be extremely annoyed when typing PIP fileA=fileB/RE elicits an "UNRECOGNIZED COMMAND" message. You can't get directly at anything through DCL, not even PIP, unless you enable the fall-through-to-MCR option in the task build. Overall falling through to MCR works fine; people used to MCR just go on using it as they always did and never know DCL is there until they get around to reading the new manuals. Almost. There are a few problem spots where MCR and DCL use the same command, as in SET, MOU, MAC, FOR, and INS. A user enters a familiar command like "MAC FILE=FILE" and is given the error message: MACRO -- Extraneous input MAC FILE=FILE ^ That's DCL complaining, because its syntax is different. Simply alert your users that if familiar commands don't work, they should try them with a dot in front of them. For example ".MAC FILE=FILE" will work just fine. The dot tells DCL to schlep the command off to MCR without even looking at it. If they're going to do a lot of that sort of thing, they can set their terminal to MCR as primary CLI with SET TERMINAL MCR. In general, SET TERMINAL MCR and SET /DCL=TI: should be the first two new commands you teach your users if DCL is in your system. 4.2 Command file execution If a terminal is running under DCL many old command files won't work if they use MCR commands like "MAC FILE,FILE/-SP=FILE" because "MACRO" is a DCL command expecting DCL syntax. I happen to like DCL, so what I do is put this into my command files: .setf DCL .if = "DCL" .sett DCL .ift DCL SET TERM MCR | | contents of old command file | | .ift DCL SET /DCL=TI: That could be more generalized if you plan on multiple CLI's: .sett MCR .enable substitution RSX-11M TO RSX-11M-PLUS MIGRATION Page 9 .sets CLI ! Save starting CLI ! .if CLI NE "MCR" .setf MCR .iff MCR MCR SET /MCR=TI: !Assumes MCR command in all CLIs! | | .iff MCR SET /'CLI'=TI: ! Restore starting CLI ! 4.3 Hints to KMS CCL users We still use CCL. It works fine. We have three commandline interpreters: DCL, MCR, and CCL. DCL comes first; any unrecognized commands fall through to MCR; finally, CCL is installed as CA. (catch-all) to handle anything MCR does not know. All I did was to rebuild CCL.TSK on the new system, and since CCL is not priveleged even that was probably unnecessary. None of the Jim Downward patches to system routines were made; most of them exist in MPLUS as distributed. One Downward patch to MCR we miss was the one that forced it to pass everything to CCL (instead of kicking out things like "?" and "LI"). When we want to add a new command it is still ever so much easier to edit two or three lines into SYSCCL.CCL than to master the complex syntax required to build a DCL command table entry, edit the file, assemble it, and double task build DCL! The /CMD parameter to RUN is not exactly like the old KMS /PRM parameter: it expects the task name in the first four characters. In other words, it clobbers the first four characters you pass. You must say: RUN $MAC/CMD="MAC FILE=FILE" instead of RUN $MAC/PRM="FILE=FILE" The CMD parameter does not exist for INSTALL, as PRM did in the KMS mods. One strange annoyance is that you cannot pass parameters to an installed task from the RUN command using CMD; _________ to use RUN/CMD the task must be non-installed. ____ 4.4 New Introduction manual The Introduction To RSX-11M-PLUS book with accompanying files in [200,1] are a great training aid for new users. I did find some of the examples in the book did not work; some files used in the text were missing, but were easy to provide. Mostly they were one-line text files used to illustrate several commands like TYPE and PRINT. Nothing major was missing. I suggest you run thru the RSX-11M TO RSX-11M-PLUS MIGRATION Page 10 book yourself before handing it to a new user, and fix the things that don't work. Even your old hands should work thru this because they will learn DCL and other stuff they probably never knew or have forgotten (e.g. EDT line edit mode for people who always use keypad). One outright error: the manual says the EDT command "T LAST" types the last line of a file; in fact it types the last line referenced. The command should be "T END-1". 4.5 Queue Manager and Error Logger The Queue Manager and Error Logger commands have changed entirely from anything you ever knew. God knows they needed it, but be warned and spend some time looking through the documentation before turning the system loose on your users. You may want to write some memos to frequent users and computer operations personnel, or hold some re-training classes. At least alert them to the excellent HELP files and how to find them. If you have any command files that used to make error report generation easier , throw them out. They'll be useless. Be prepared to rewrite, and to find that it is easier this time. I wrote a file called ERRORS.CMD for our operators to use (it will be in [333,100] on the SIG tape) that walks them through most of the options. The canned report option for the error log REPORT GENERATOR did not work. You are supposed to be able to enter: RPT /RE:DAY to get a full summary report on all today's errors, for example. It bombs. My ERRORS.CMD file could not make use of this switch, unfortunately. I have SPR'ed this. 5.0 Hints from our experience 5.1 Multi-path access to disks Setting up procedures for proper handling of dual-ported disks, disks that in addition are accessible from two or three CPU's simultaneously, was very complex. We have three CPU's, three controllers, and six drives. The disks are each connected to two RSX-11M TO RSX-11M-PLUS MIGRATION Page 11 of the three controllers, and all three controllers are connected to all three CPU's. There are two paths to each disk from each CPU. M-PLUS allows you to specify disk drives as dual-ported. Since that is what we have physically it seemed to make sense to tell the software about it. It took us weeks to find out all the things that could go wrong. We found no actual bugs in the software, just mass confusion for us as users. One rule of thumb: DON'T LIE TO THE SYSTEM. If you SAY there are two paths to a disk there damn well better BE two paths. You see, we have this nice switch panel that can put individual ports on a controller offline... Well, if the second path for DB2: is switched offline, and you try to MOUNT DB2:, mount will time out. If you're booting from DB2:, tasks will start getting load failures in STARTUP right after CON ONLINE ALL is executed (more on the CON tasks below). We also found (with CDC drives and SI controllers) that dismounting a pack on one CPU could knock it offline for another CPU as well. We had one CPU booted from DB5:. A user on a second CPU mounted DB5:/NOWRITE (that's a new switch on MOUNT that is very useful), and when he was done, he dismounted DB5: like a good user should. Bang! down goes the first CPU. For some reason, even though our drives look like RP04's to RSX, the dismount command is trying to unload the disk! And for some reason the disk seems to recognize it even though it can't be unloaded from software. (Could be a hardware bug.) We finally discovered that, to be safe, we should mount disks with a new switch, /LOCK=N, which sets the default for dismount to "no unload". That way users don't have to remember to use DMO DBn:/LOCK=N. We set up a MOUNT.CMD command file and have everyone use it to mount a disk so the right switches are always used. Another switch useful in multi-path situations is /LRU=0. Whenever we mount a disk /NOWRITE we also add /LRU=0, which instructs RSX not to cache directories in memory but to always read from the disk. That may sound inefficient, but when we mount a disk /NOWRITE it is usually because it is mounted for writing from another system. Directories can get strangely out of sync when one system is writing to a directory and another thinks it has the directory cached in memory! What we really need is a mechanism that completely prevents a disk __________ ________ being mounted for writing from two systems at once. We have done that, of course, and the result is hundreds of multiply allocated blocks as each system blithly writes using its own copy of the bitmap of free blocks. One useless disk and lots of grouchy users. We are currently working on some mods to MOU and SAV to accomplish this. RSX-11M TO RSX-11M-PLUS MIGRATION Page 12 5.2 CON, the System Reconfiguration task The System Reconfiguration task is both an enormous boon and a colossal pain. This task enables you to place devices in your configuration either on or offline by software command: CONFIGURE OFFLINE DB0:, for example. You can also display and even change CSR's and vectors! This affords great flexibility. But there is a whole new command set to learn. The pain comes from what I said above: DON'T LIE TO THE SYSTEM. RSX-11M users are used to being able to do peculiar things like spinning down one disk and spinning up another in its place without dismounting it from the system. M-PLUS won't let you do that; the minute you touch the button it dismounts the drive automatically. This particular protection is, I suppose, good. But sometimes I want to lie to the system! Like when I blow a ____ home block on an otherwise good disk and want to recover its files. I've kept a Version 3.2 pack around just so I can play that game. A related difference is the fact that under M-PLUS any access to mag tape requires that the tape be mounted. To initialize a tape you can't just allocate yourself the drive and initialize; you allocate it, MOUNT it /FOREIGN , and then initialize. Same with BRU and other utilities that used to access unmounted tapes and disks under RSX-11M; no more, you have to MOUNT /FOREIGN. In general M-PLUS forces you to be more careful about what you do with the hardware, and to tell the system using CON before you do it. If we are going to switch an access path to disk offline, we first must CON it OFFLINE. Makes sense, but at first it creates strange situations for someone used to M. 5.3 Task Build options Before building non-privileged tasks, I recommend you search thru all xxxBLD.BLD files in [1,20] for all the GBLPAT and GBLDEF lines to see for yourself what options you have in task building the various utilities. These are command files used by SYSGEN to create xxxBLD.CMD files in [1,24] for the related task builds. For example, PIPBLD.BLD contains switches to select options for PIP. There is a point where SYSGEN pauses after creating the command files in [1,24] and asks if you want to edit any of them, and you could wait until then and then do your editing. However, if you re-run SYSGEN for any reason you'll have to repeat the editing. In addition, you can, if you wish, build three versions of many utilities, one regular (overlaid), one using FCSRES, and one using RSX-11M TO RSX-11M-PLUS MIGRATION Page 13 FCSFSL. Then you have to edit three command files in [1,24]. If you edit the xxxBLD.BLD files in [1,20] before starting the non-privileged task part of SYSGEN, then your options will automatically be included in all three versions every time you do a GEN. 5.3.1 PIP - For example, PIP is advertised as having the option to preserve creation date on copies, but nowhere does it tell you that you must edit a global in the PIPBLD.BLD to obtain this option. 5.3.2 INDIRECT - The Indirect Command processor also has nifty options. For example, you can have it default to the system UIC (or another you designate) if the command file is not found in the user's UIC; once again, however, you must edit the Build file to get this. IND is now called ICM just to confuse you. 5.3.3 DCL - DCL has a couple of options, most useful of which is allowing unrecognized commands to fall through to MCR. Edit [1,20]DCLBLD.BLD to get it. 5.3.4 Other tasks with options - Tasks I found having build file options: DMP CMP AT. LPP MAC PIP PRT QCL QMG RMD SHA TKB ACN BYE HEL LBR RPT SAV DCL 6.0 Miscellaneous comments The ability to broadcast to users by name is nifty: finds them even on multiple terminals. The sample DTR reports for Resource Accounting are excellent tools for producing your own customized reports. All of the accounting RSX-11M TO RSX-11M-PLUS MIGRATION Page 14 records are now accesible through Datatrieve. In general, Mplus is easier to manage for an unsophisticated user because it translates more of what you need to know into human-readable form. Be aware that under M-PLUS a task named "...XXX" NEVER RUNS; it is a prototype task only. When TT0 runs it by saying "XXX", it gets a task called "XXXT0". If you have any command files that try to do ".WAIT ...XXX" they will no longer work. Such tasks are not intended for multi-terminal use and should be installed with task names not in the form "...XXX". SIG programs we built under MPLUS (versions on SIG tape): SRD (multiuser, non-overlaid), TECO, UIC, LIST, GREP, COOKIE, RNO, DOC, DUNGEON, C(XCC), PREDAY, TYPE (renamed TIPE), TREK, TCF, BRUDIR, SRDCMD (CMD), ADVENT, RMC, LUT, USERMN, TRUNC, RATFOR, PACMAN. Most required no modification, only a few required other than minor mods to the build files. The HELP files on Version 2.0 are fantastic, in some cases more accurate than the manuals. I wrote three TECO macros, HDX, HFL, EDH, and TEH (all with both TES and TEC extensions), to help me step through all of them and index what is there. See [333,100] on the current RSX tape. (The text of this handout -- possibly with updates after 15-OCT-82 -- will be there, too as M2MPTALK.DOC.) 7.0 SUMMARY Table of Contents 1.0 Reasons for going to M-Plus . . . . 1 1.1 Shadow disk . . . . . . . . . . . . 1 1.2 Overlapped seeks for disk . . . . . 3 1.3 Supervisor mode libraries . . . . . 3 1.4 Secondary pool . . . . . . . . . . . 4 1.5 Directive common . . . . . . . . . . 4 1.6 Multi-user tasks . . . . . . . . . . 5 1.7 Multistream batch processing . . . . 5 1.8 Task and user accounting capability . 5 2.0 Transition process from M to M+ . . 5 3.0 Problems encountered in SYSGEN . . . 6 3.1 Bug in Building the Executive . . . 6 3.2 Getting correct versions of N.P. tasks 7 4.0 Helping the users adjust . . . . . . 7 4.1 Getting used to DCL . . . . . . . . 7 4.2 Command file execution . . . . . . . 8 4.3 Hints to KMS CCL users . . . . . . . 9 4.4 New Introduction manual . . . . . . 9 4.5 Queue Manager and Error Logger . . . 10 5.0 Hints from our experience . . . . . 10 5.1 Multi-path access to disks . . . . . 10 5.2 CON, the System Reconfiguration task 12 5.3 Task Build options . . . . . . . . . 12 5.3.1 PIP . . . . . . . . . . . . . . . 13 5.3.2 INDIRECT . . . . . . . . . . . . . 13 5.3.3 DCL . . . . . . . . . . . . . . . 13 5.3.4 Other tasks with options . . . . . 13 6.0 Miscellaneous comments . . . . . . . 13 7.0 SUMMARY . . . . . . . . . . . . . . 14