ДНIX: Швециялық нақты уақыт опералық жүйесінің тарихы

Кіріспе

Нақты уақыт операциялық жүйе

DNIX (түпнұсқа жазылуы: D Nix) – швед компаниясы Dataindustrier AB (DIAB) жасаған Unix-қа ұқсас, қолданыстан тоқтатылған нақты уақыт операциялық жүйе. ABCenix деп аталатын нұсқасы Luxor компаниясының ABC 1600 компьютері үшін әзірленген. Daisy Systems компаниясының да кейбір компьютерлік көмекпен жобалау (CAD) жұмыс станцияларында Daisy DNIX деп аталатын жүйесі болған. Бұл жүйе DIAB өнімдерімен ешқандай байланысы жоқ.

Швециядағы DIAB-те басталған

Dataindustrier AB (сөзбе-сөз аударма: компьютерлік индустриялар акционерлік қоғамы) 1970 жылы Ларс Карлссонмен Швецияның Сундсвалл қаласында бір тақталы компьютер өндіруші ретінде құрылды, ол Zilog Z80 негізіндегі Data Board 4680 деп аталатын компьютерді шығарды. 1978 жылы DIAB швед телекомпаниясы Luxor AB-мен бірлесіп, үй және кеңсе компьютерлерінің ABC 80 және ABC 800 серияларын өндіруге кірісті. 1983 жылы DIAB тәуелсіз түрде алғашқы Unix-ке үйлесімді DIAB DS90 машинасын, Motorola 68000 процессоры негізінде әзірледі. AT&T Corporation-ның UNIX System V лицензиясы негізінде D NIX осы жерде пайда болды. Алайда, DIAB – өнеркәсіптік басқару жүйесі (автоматтандыру) компаниясы болғандықтан, нақты уақыт операциялық жүйесіне мұқтаж болды. Сондықтан компания AT&T ұсынған UNIX ядросын өздері әзірлеген, бірақ үйлесімді нақты уақыт нұсқасымен алмастырды. Бұл ядро Литон Индустриз компаниясының Monroe Systems бөлімшесі үшін жасалған OS.8 деп аталатын Z80 ядросынан шабыт алды. Уақыт өте келе компания UNIX стандартты пайдаланушы құралдарының бірнешеуін өз іске асыруларымен алмастырды, нәтижесінде ешқандай код UNIX-тен алынбады және олардың машиналары кез келген AT&T UNIX лицензиясынан тәуелсіз жұмыс істей алды. Екі жыл өткен соң, Luxor компаниясымен бірлесіп, кеңсе нарығы үшін ABC 1600 деп аталатын компьютер әзірленді, ал сонымен қатар DIAB Motorola 68010, 68020, 68030 және ақырында 68040 сияқты Motorola процессорларының жаңа нұсқаларын қолдана отырып, DS90 компьютерінің жетілдірілген нұсқаларын шығаруды жалғастырды. 1990 жылы DIAB компаниясын Groupe Bull сатып алды, ол DS машиналарын DIAB брендімен, DIAB 2320, DIAB 2340 сияқты атаулармен шығаруды және қолдауды жалғастырды, олар әлі де DIAB-тің DNIX нұсқасын қолданды.

ISC Systems Corporation-тегі туынды құрал

ISC Systems Corporation (ISC) 1980-жылдардың соңында Motorola 68k негізіндегі банктік компьютерлер желісінде пайдалану үшін DNIX пайдалану құқығын сатып алды. (ISC кейіннен Olivetti сатып алды, ол өз кезегінде Wang-қа сатылды, содан кейін Getronics сатып алды. Бұл корпоративтік ұйым, көбінесе "ISC" деп аталады, жылдар бойы көптеген есімдерге жауап берді.) Бұл код тармағы SVR2 үйлесімді нұсқасы болды және олардың жұмысынан кең ауқымды өзгерістер мен дамуды алды. Бұл операциялық жүйенің ерекше ерекшеліктері сұраныс бойынша беттеу, дискісіз жұмыс станциялары, көппроцессорлық өңдеу, асинхронды кіріс/шығыс (I/O), файл жүйесіндегі каталогтарға процестерді (өңдеушілерді) орнату мүмкіндігі және хабар алмасу болды. Оның нақты уақытты қолдауы тізімдік іздеу механизмдерінен гөрі ішкі оқиғаларға негізделген кезектерден ("көктегі үйірме" болмады), екі кластағы статикалық процесс басымдықтарынан (толық орындау және уақыт бөлісі), үздіріссіз файлдарды қолдаудан (критикалық ресурстардың фрагментациясын болдырмау үшін) және жадты құлыптаудан тұрды. Ортогональды асинхронды оқиғаларды жүзеге асыру сапасы әлі күнге дейін коммерциялық операциялық жүйелерде теңдессіз, бірақ кейбіреулері оған жақындады. (Әлі қабылданбаған тұжырымдама - барлық асинхронды әрекеттің синхронды басқару нүктесі де асинхронды болуы мүмкін, шексіз. DNIX бұл мәселені шеберлікпен шешті.) Асинхронды I/O мүмкіндігі Беркли сокеттерінің таңдауын немесе SVR4 STREAMS сауалнама механизмін қажет етпеді, бірақ сокет семантикасын кері үйлесімділік үшін сақтаған сокет эмуляциясы кітапханасы болды. DNIX-тің тағы бір ерекшелігі - стандартты утилиталардың ешқайсысы (мысалы, ps, жиі бұзушы) өз жұмысын орындау үшін ядроның жадында іздемеді. Оның орнына жүйелік шақырулар қолданылды, бұл ядроның ішкі архитектурасы қажет болған жағдайда өзгеруге еркін болды. Өңдеуші тұжырымдамасы желілік протокол стектерін ядродан тыс орналастыруға мүмкіндік берді, бұл жалпы сенімділікті арттыра отырып, дамуды жеңілдетті және өнімділікті арттырды. Ол сондай-ақ шетелдік файл жүйелерін пайдаланушы деңгейіндегі процестерге мүмкіндік берді, тағы да сенімділікті арттыру үшін. Негізгі файл жүйесі, болса да, ол сыртқы процесс болған (бұл бір кезде болған), өнімділік үшін ядроға тартылды. Бұл болмаса, DNIX микроядро ретінде қарастырылуы мүмкін еді, бірақ ол ресми түрде әзірленбеді. Өңдеушілер кез келген "туған" Unix файлы, каталог құрылымы немесе құрылғысы ретінде көріне алады, ал өңдеуші өңдеуге келмейтін файл I/O сұраныстарын басқа өңдеушілерге, оның ішінде өңдеуші орнатылған негізгіге жіберуі мүмкін. Өңдеуші байланыстары да файл жүйесінен тәуелсіз болуы және таратылуы мүмкін, құбыр сияқты. Мұның бір салдары - мәтіндік терминалға (TTY) ұқсас құрылғылар ядроға негізделген жалған терминалдың қажеттілігісіз эмуляциялануы мүмкін. ISC-тің дискісіз жұмыс станциясын қолдауында өңдеушінің көмегімен шешілген жағдайдың мысалы, іске асырудағы қате жұмыс станциясында атаулы құбырларды қолдану файл серверінде қажетсіз ресурстарды құлыптауға әкелді. Тиісті ядро түзетулері әзірленгенге дейін жұмыс станциясында аталған құбырларға қол жеткізу үшін өңдеуші құрылды. Бұл өңдеушіні жүзеге асыру үшін шамамен 5 килобайт код қажет болды, бұл тривиальды емес өңдеушінің үлкен болуы қажет емес екенін көрсетеді. ISC сонымен қатар DIAB-тің DS90 10 және DS90 20 машиналарын файл серверлері ретінде өндіру құқығын алды. Алайда, DS90 20 көппроцессорлы машиналары мақсатты нарыққа тым қымбат болғандықтан, ISC өз серверлерін жобалап, оларға DNIX-ті порттады. ISC осы файл серверлерімен пайдалану үшін өзінің GUI негізделген дискісіз жұмыс станцияларын жасады және DNIX-ті қайтадан порттады. (ISC Daisy DNIX-ті орындайтын Daisy жұмыс станцияларын DIAB-тің DNIX-ін орындайтын машиналарды жобалау үшін қолданғанмен, ішкі жағынан елеусіз шатасу болды, өйткені жобалау және орналастыру қызметкерлері бағдарламалық жасақтама қызметкерлерімен сирек сөйлеседі. Сонымен қатар, аппараттық жобалау тобы екі жүйе де қолданбады! Ойынның анекдоты былай болды: "ISC-де біз компьютерлерді жасаймыз, біз оларды қолданбаймыз".) DNIX-тің асинхронды I/O қолдауы жұмыс станцияларында оқиғаға негізделген оңай бағдарламалауға мүмкіндік берді, олар салыстырмалы түрде шектеулі ресурстары болғанымен жақсы жұмыс істеді. (GUI дискісіз жұмыс станциясы 7 МГц 68010 процессорымен жабдықталған және тек 512 КБ жадпен ғана пайдалануға болатын, оның жартысын ядро тұтынады. Көптеген жұмыс станцияларында 1 МБ жад болды, бірақ кейінірек 2 МБ және 4 МБ нұсқалары, сондай-ақ 10 МГц процессорлары болды.) Толыққанды орнату бір серверден (16 МГц 68020, 8 МБ жедел жад және 200 МБ қатты дискі) және 64 жұмыс станциясына дейін құралуы мүмкін. Бастауға баяу болғанымен, мұндай массив банк кассирінің жұмысында қанағаттанарлық өнімділік көрсетеді. DNIX-тің өзіндік тиімділігінен басқа, байланысты DIAB C компиляторы жоғары өнімділікке үлкен үлес қосты. Ол әсіресе 68010 үшін жақсы кодты жасады, әсіресе ISC оны жетілдіргеннен кейін. (ISC сонымен қатар оны соңғы жұмыс станциясында қолданылған Texas Instruments TMS34010 графикалық копроцессорына қайта бағыттады.) DIAB C компиляторы, әрине, DNIX-ті құру үшін қолданылды, бұл оның тиімділігіне үлес қосатын факторлардың бірі болды және ол әлі де Wind River Systems арқылы қандай да бір нысанда қол жетімді. Бұл жүйелер 2006 жылы жазылған кезде, бұрынғы Seattle First National Bank бөлімшелерінде, қазір Bank of America деп таныстырылған жерлерде әлі де қолданылуда. ISC клиенттерінің кейбіреулері DNIX-ті әлі де қандай да бір жолмен пайдалануы мүмкін, және бәлкім, солай болар. ISC арқылы Орталық және Оңтүстік Америкада DNIX кең таралған.

ISC Systems Corporation (ISC) purchased the right to use DNIX in the late 1980s for use in its line of Motorola 68k based banking computers. (ISC was later bought by Olivetti, and was in turn resold to Wang, which was then bought by Getronics. This corporate entity, most often referred to as 'ISC', has answered to a bewildering array of names over the years.) This code branch was the SVR2 compatible version, and received extensive modification and development at their hands. Notable features of this operating system were its support of demand paging, diskless workstations, multiprocessing, asynchronous input/output (I/O), the ability to mount processes (handlers) on directories in the file system, and message passing. Its real time support consisted largely of internal event driven queues rather than list search mechanisms (no 'thundering herd'), static process priorities in two classes (run to completion and timesliced), support for contiguous files (to avoid fragmentation of critical resources), and memory locking. The quality of the orthogonal asynchronous event implementation has yet to be equalled in current commercial operating systems, though some approach it. (The concept that has yet to be adopted is that the synchronous marshalling point of all the asynchronous activity could also be asynchronous, ad infinitum. DNIX handled this with aplomb.) The asynchronous I/O facility obviated the need for Berkeley sockets select or SVR4's STREAMS poll mechanism, though there was a socket emulation library that preserved the socket semantics for backward compatibility. Another feature of DNIX was that none of the standard utilities (such as ps, a frequent offender) rummaged around in the kernel's memory to do their job. System calls were used instead, and this meant the kernel's internal architecture was free to change as required. The handler concept allowed network protocol stacks to be outside the kernel, which greatly eased development and improved overall reliability, though at a performance cost. It also allowed for foreign file systems to be user level processes, again for improved reliability. The main file system, though it could have been (and once was) an external process, was pulled into the kernel for performance reasons. Were it not for this DNIX could well have been considered a microkernel, though it was not formally developed as such. Handlers could appear as any type of 'native' Unix file, directory structure, or device, and file I/O requests that the handler could not process could be passed off to other handlers, including the underlying one on which the handler was mounted. Handler connections could also exist and be passed around independent of the file system, much like a pipe. One effect of this is that text terminal (TTY) like devices could be emulated without needing a kernel based pseudo terminal facility. An example of where a handler saved the day was in ISC's diskless workstation support, where a bug in the implementation meant that using named pipes on the workstation could induce undesirable resource locking on the fileserver. A handler was created on the workstation to field accesses to the afflicted named pipes until the appropriate kernel fixes could be developed. This handler required approximately 5 kilobytes of code to implement, an indication that a non trivial handler did not need to be large. ISC also received the right to manufacture DIAB's DS90 10 and DS90 20 machines as its file servers. The multiprocessor DS90 20's, however, were too expensive for the target market and ISC designed its own servers and ported DNIX to them. ISC designed its own GUI based diskless workstations for use with these file servers, and ported DNIX again. (Though ISC used Daisy workstations running Daisy DNIX to design the machines that would run DIAB's DNIX, there was negligible confusion internally as the drafting and layout staff rarely talked to the software staff. Moreover, the hardware design staff didn't use either system! The running joke went something like: "At ISC we build computers, we don't use them.") The asynchronous I/O support of DNIX allowed for easy event driven programming in the workstations, which performed well even though they had relatively limited resources. (The GUI diskless workstation had a 7 MHz 68010 processor and was usable with only 512K of memory, of which the kernel consumed approximately half. Most workstations had 1 MB of memory, though there were later 2 MB and 4 MB versions, along with 10 MHz processors.) A full blown installation could consist of one server (16 MHz 68020, 8 MB of RAM, and a 200 MB hard disk) and up to 64 workstations. Though slow to boot up, such an array would perform acceptably in a bank teller application. Besides the innate efficiency of DNIX, the associated DIAB C compiler was key to high performance. It generated particularly good code for the 68010, especially after ISC got done with it. (ISC also retargeted it to the Texas Instruments TMS34010 graphics coprocessor used in its last workstation.) The DIAB C compiler was, of course, used to build DNIX, which was one of the factors contributing to its efficiency, and is still available, in some form, through Wind River Systems. These systems are still in use as of this writing in 2006, in former Seattle First National Bank branches now branded Bank of America. There may be, and probably are, other ISC customers still using DNIX in some capacity. Through ISC there was a considerable DNIX presence in Central and South America.

Бір-біріне үйлесімділік

Dnix (((2) шақырудан басқа, libc интерфейсінің "стандартты" шақыруларының толық жиынтығы қолданысты болды. ашу ((2), жабу ((2), оқу ((2), жазу ((2) және т.б. Бұлар артқа қарай үйлесімділік үшін ғана емес, сонымен қатар NCR Tower компьютерімен екілік код деңгейінде үйлесімді болатындықтан, осы компьютер үшін құрастырылған екілік файлдар DNIX жүйесінде өзгеріссіз жұмыс істейтін. DNIX ядросының ішінде екі тұзақ диспетчері болды: біреуі DNIX әдісі үшін, екіншісі Unix әдісі үшін. Диспетчерді таңдау бағдарламашының қалауына байланысты болды, және оларды бір-бірімен алмастыра қолдануға болады. Олардың семантикасы функциялардың өзара сәйкес келетін бөліктерінде толықтай бірдей болды. (Бұл машиналарда unix (((2) шақырулары үшін 68000 тұзақ #0 нұсқауы, ал dnix (((2) шақырулары үшін тұзақ #4 нұсқауы қолданылды. Екі тұзақ басқарушы да өте ұқсас болды, бірақ [көбінесе жасырылған] unix(2) шақыруы функция кодын процессордың D0 тіркегішінде сақтаса, dnix(2) оны қалған параметрлермен бірге стекте сақтады.) DNIX 5.2 ішкі жүйеде желілік протоколдар жиынтығына ие болған жоқ (ISC-нің дискісіз жұмыс станцияларын қолдау пакеті үшін қосылған X.25 негізіндегі Ethernet протоколы жиынтығынан басқа), барлық желілік байланыс өңдеушілерге оқу және жазу арқылы жүзеге асырылды. Сондықтан сокет механизмі болған жоқ, бірақ TCP/IP өңдеушісімен байланыс үшін асинхронды I/O қолданатын libsocket ((3) кітапханасы болды. Типик Berkeley негізіндегі желілік бағдарламаны өзгеріссіз компиляциялау және іске қосу мүмкін болды (әдеттегі Unix порттау мәселелерін ескере отырып), бірақ ол сол функцияларды орындайтын, бірақ асинхронды I/O-ны тікелей пайдаланатын бағдарламадан гөрі тиімді болмауы мүмкін.

ISC-нің кеңейтулері

ISC DNIX-тің 5.2 (SVR2-ге үйлесімді) және 5.3 (SVR3-ге үйлесімді) нұсқаларын сатып алды. Сатып алу кезінде DNIX 5.3 әлі де DIAB-те әзірленуде болғандықтан, DNIX 5.2 орналастырылды. Уақыт өте келе, ISC инженерлері 5.3 ядросының көптеген мүмкіндіктерін 5.2 нұсқасына енгізді, ең алдымен ортақ жады мен IPC, сондықтан DIAB және ISC DNIX нұсқалары арасында кейбір ерекшеліктер пайда болды. DIAB 5.3 ISC 5.2-нің соңғы нұсқасына қарағанда көбірек SVR3 мүмкіндіктерін қамтыды. Сондай-ақ, DIAB DNIX 5.4-ке көшті, ол SVR4-ке үйлесімді операциялық жүйе болды. ISC-де әзірлеушілер DNIX 5.2 нұсқасын олардың қажеттіліктері мен Unix индустриясының жалпы тенденцияларына негізделген (тек ядроға қатысты мүмкіндіктер тізімделген) айтарлықтай кеңейтті:

Дисксіз жұмыс станциясын қолдау. Жұмыс станциясының ядролық файлдық жүйесі алынып тасталды және X.25 негізделген Ethernet байланыс тікелей қосылысымен ауыстырылды. Файл серверінің ядросы да қашықтан келетін сұрауларды қабылдап, оларды қызмет көрсету үшін ядролық процестер тобына жіберуге арналған жұптас компонентпен кеңейтілді, бірақ мұны жасау үшін стандартты өңдеуші жазылуы мүмкін еді. (Өнімнің өмірлік циклының соңында ISC стандартты SVR4 негізделген Unix серверлерін DNIX серверлерінің орнына орналастырды. Бұл X.25 STREAMS және арнайы жазылған файл сервері бағдарламасын пайдаланды. Тиімділігі төмен құрылымға қарамастан, пайдаланылған платформалардың жоғары өнімділігі әлдеқайда жылдам серверді қамтамасыз етті. Бұл файл сервері бағдарламасы DNIX серверінің барлық функционалдық мүмкіндіктерін қолдамағаны өкінішті. Атаулы құбырлар сияқты қиын мәселелер ешқашан жұмыс істемеді. Бұл құбырларды өңдеу процесіне тағы бір себеп болды.) ISC-нің MMU мүмкіндіктерін пайдалана отырып, gdb бақылау нүктесін қолдау. Файл жүйесіне асинхронды I/O енгізілді. (Бастапқыда ол тоқтатылды.) Бұл үшін ядролық процестер (kprocs немесе threads) пайдаланылды. Truss немесе strace сияқты бағдарламаға қолдау. Стандартты Unix ptrace бір қадамдық механизміндегі кейбір қателерді жөндеуден басқа, бұл трасердің стандартты бір қадамдық механизмді жұмыс істеп тұрған процестерде пайдалануы үшін уақытша процесс қабылдау құралын қосуды қажет етті. SVR4 сигналдық механизмінің кеңейтулері. Негізінен жаңа STOP және CONT сигналдары үшін, бірақ жаңа сигнал басқару шақыруларын да қамтиды. ISC-де adb және sdb жөндеушілерінің бастапқы коды болмағандықтан, u бетін өзгерту мүмкін болмады, сондықтан жаңа сигналдарды ұстау мүмкін болмады, оларды тек тоқтатуға немесе әдепкі өңдеуге ие етуге болады. Желілік аңсауды қолдау. Бұл Ethernet драйверін кеңейтуді қажет етті, сондықтан бір оқиға бірнеше I/O сұранысын қанағаттандыра алады, ал ымыраға келу режимін қолдау үшін аппараттық сүзгілеуді бағдарламалық түрде шартты түрде жүзеге асыру керек. Дискілерді көшіру. Бұл құрылғы драйверінде емес, файл жүйесінде жасалды, сондықтан сәл (немесе тіпті толығымен) әртүрлі құрылғыларды да бірге көшіруге болады. Флопиге кішкентай қатты дискіні көшіру флопиді шығару арқылы дискідегі қателерді оңай тудыратындықтан, көшіруді сынаудың танымал тәсілі болды. 32 биттік inode, 30 таңбалы файл атауы, символды сілтеме және файл жүйесіне жабысқақ каталогтар. /dev/zero, /dev/noise, /dev/stdXXX және /dev/fd/X құрылғылары қосылды. Процесс тобының идентификатор тізімдері (SVR4-тен). #! тікелей сценарийді орындау. ISC-нің Z 80 негізделген VMEbus байланыс тақталарын пайдалана отырып, сериялық портты көбейту. Жылжымалы ауыстыру бөлімі. Орындалып жатқан процестердің негізгі "сүп-сарты" суреті. Фюзер командасын қолдау. Процесс рениц функциясы. Басымдықтарды өзгерту үшін уақыт бөлісуді қайта реттеу бағдарламасы. Процестерді "қаптау" әдісі, оны барлық жад ресурстарынан бірден айыру. Қазіргі жұмыс жиынтығының қандай екенін анықтау үшін өте пайдалы, оған әлі қол жетімді, бірақ міндетті түрде қолданылмайтын нәрсеге қарама-қарсы. Бұл процестердің жад картасының барлық 1024 беттерінің жағдайын көрсететін графикалық интерфейспен байланысты. (Бұл ISC-нің MMU қолдаған жад беттерінің саны.) Пайдалану кезінде сіз мақсатты процесті оның өмір бойында кезең-кезеңмен "қағып" алатынсыз, содан кейін қанша жад ауыстырылғанын көретін болады. Бұл пайдалы болды, өйткені ISC-нің өндірістік ортасы ұзақ уақыт бойы өмір сүрген бірнеше процестерді ғана қолданды, олардың жадты пайдалануын және өсуін бақылау өнімділікті сақтаудың кілті болды.

Diskless workstation support. The workstation's kernel file system was removed, and replaced with an X.25 based Ethernet communications stub. The file server's kernel was also extended with a mating component that received the remote requests and handed them to a pool of kernel processes for service, though a standard handler could have been written to do this. (Later in its product lifecycle, ISC deployed standard SVR4 based Unix servers in place of the DNIX servers. These used X.25 STREAMS and a custom written file server program. Despite the less efficient structuring, the raw horsepower of the platforms used made for a much faster server. It is unfortunate that this file server program did not support all of the functionality of the native DNIX server. Tricky things, like named pipes, never worked at all. This was another justification for the named pipe handler process.) gdb watchpoint support using the features of ISC's MMU. Asynchronous I/O to the file system was made real. (Originally it blocked anyway.) Kernel processes (kprocs, or threads) were used to do this. Support for a truss or strace like program. In addition to some repairs to bugs in the standard Unix ptrace single stepping mechanism, this required adding a temporary process adoption facility so that the tracer could use the standard single stepping mechanism on existing processes. SVR4 signal mechanism extensions. Primarily for the new STOP and CONT signals, but encompassing the new signal control calls as well. Due to ISC's lack of source code for the adb and sdb debuggers the u page could not be modified, so the new signals could only be blocked or receive default handling, they could not be caught. Support for network sniffing. This required extending the Ethernet driver so that a single event could satisfy more than one I/O request, and conditionally implementing the hardware filtering in software to support promiscuous mode. Disk mirroring. This was done in the file system and not the device driver, so that slightly (or even completely) different devices could still be mirrored together. Mirroring a small hard disk to the floppy was a popular way to test mirroring as ejecting the floppy was an easy way to induce disk errors. 32 bit inode, 30 character filename, symbolic link, and sticky directory extensions to the file system. Added /dev/zero, /dev/noise, /dev/stdXXX, and /dev/fd/X devices. Process group id lists (from SVR4). #! direct script execution. Serial port multiplication using ISC's Z 80 based VMEbus communications boards. Movable swap partition. Core 'dump' snapshots of running processes. Support for fuser command. Process renice function. Associated timesharing reprioritizer program to implement floating priorities. A way to 'mug' a process, instantly depriving it of all memory resources. Very useful for determining what the current working set is, as opposed to what is still available to it but not necessarily being used. This was associated with a GUI utility showing the status of all 1024 pages of a process's memory map. (This being the number of memory pages supported by ISC's MMU.) In use you would 'mug' the target process periodically through its life and then watch to see how much memory was swapped back in. This was useful as ISC's production environment used only a few long lived processes, controlling their memory utilization and growth was key to maintaining performance.