May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Tivoli Workload Scheduler

News Job schedulers Recommended Links Documentation Tivoli Job Scheduling Console Scheduling Reference
Version 8.2 Version 8.3 Version 8.4 Version 8.5 Tivoli Technical Exchange Webcasts TWS agent  Redbook Maintaining Your Tivoli Environment
TWS Logfile adapter Troubleshooting Gateway Troubleshooting Useful framework commands TEC   Etc

IBM Tivoli Workload Scheduler (TWS ) is a legacy job scheduler  that was the result of acquisition and only formally belongs to Tivoli family.  It is rebranded and modified product that was initially called Maestro  that was originally developed by Unison Inc, the company that has office in Austin close to Tivoli. Unison Software, Inc. was incorporated in California (central office was in Santa Clara) in 1980 and reincorporated in Delaware in July 1995. 

Founded in 1979, Unison was one of the first players in systems management for the Hewlett-Packard marketplace and later, in 1993, has moved into the Unix market.  At peak Unison has had approximately 350 customers of Maestro for Unix. Among them were The Prudential, Home Depot, Northern Telecom, Nike Securities, Signet Bank, and Weyerhaeuser.  It employed 225 people and has sails 40 millions in 1997 before the acquisition.

Maestro was originally released for pretty obscure system, the HP3000, in 1985. So initially it did not have Unix pedigree and as such was a second rate product both conceptually and quality of implementation wise. Maestro was ported to UNIX in 1993 and to Windows NT in 1996.  Still remnants of the ancient past are visible even now: conman (command line interface for TWS) uses idiosyncratic and foreign for Unix and Windows administrators notation for basic regular expressions:

In 1995 signed marketing agreement with Tivoli. At this time Unison Maestro 4.4 was available for HP 9000, IBM RS/6000, Sun SPARC, Microsoft Windows NT, Sequent, and Siemens-Nixdorf platforms. . Pricing started at $14K. In 1997 was acquired by Tivoli (already an IBM subsidiary) for $170 million in stock.

After that  the product was renamed IBM Tivoli Workload Scheduler and all 225 Unison employees became part of Tivoli team.  It was an expensive system: pricing for Unix started at $8K for the first server with scheduler installed with $14K as a minimum usable configuration.  It remains pretty expensive in IBM hands. I think it is the second most expensive enterprise solution after CA Unicenter. Your mileage may very.  In my humble view TWS story has some analogy with the story of subprime mortgages, but in software domain.  One particular fitting part of this analogy is that both products were awarded  triple A rating by rating agencies.  I am not saying the TWS real worth is pennies on the dollar but I suspect that the current price is detached from reality in a way that is very similar with pricing of subprime mortgages pools in 2007.

There is no any exiting ideas in TWS. TWS' architecture is based on a classic scheme: central server which  monitors and control planned jobs and ad hoc batch jobs on clients. Each client generally should have an agent installed (starting from version 8.4 it is possible to run jobs via SSH, but as far as I know this is not a typical deployment mode for TWS).

Remember the old tale that some software billionaire had a sign on his wall saying: "Price! Service!! Quality!!! Pick any 2."

Still despite its drawbacks the product was one of the first successful enterprise schedulers on the marketplace. It looks like the saying  mentioned above is wrong and you can sell a lot of stuff with just "Service" ;-)

Enterprise schedulers now became a commodity with dozens of firms trying to sell their products which are mostly newer and sometimes architecturally superior to TWS (one really funny story is the Oracle scheduler that in some aspects is superior to TWS is free with Oracle database but in many corporation TWS works with database stored in Oracle :-).

The key functionality is providing unattended background executions of scripts ( batch processing ) in multiple, not very compatible, environments. Basic TWS functionality corresponds to Unix cron with typical for enterprise schedulers enhancements such as dependency-based and event-based invocation, multiple time zones accommodation, etc.  I would like to note that while cron is able to perform only time-based invocation on a single server, you can easily extend those capabilities using custom  envelopes for scripts. In any case, TWS, like all enterprise schedulers, replaces cron with there own daemon that has those capabilities built-in.   

The unit of planning in enterprise schedulers is a batch job, which is basically a script written in shell, Perl or other scripting or application specific (SQL) language.  Job can have dependencies. In this case it starts running as soon as all of its dependencies are satisfied. If a job ends in error, enterprise scheduler can handle the recovery process. There is also some integration with monitoring, centralized job repository and push mechanism for jobs to reach clients.   In case of TWS those functions needs additional Tivoli component for implementation (TCM or TPM for distribution, TEC for monitoring). 

Company  probably needs widely use at least four distinct environment for TWS make sense (Unix, Windows plus mainframes and AS400 line). For just two environments (Unix+Windows) TWS problems as a legacy application are too evident. Which from purely logical standpoint limits TWS deployment to Fortune 1000 corporations, financial institutions and government with some AS400 and mainframe deployment. Of course there is not much logic in enterprise IT so you can find TWS deployed in vast variety of scenarios, sometimes with only Unix and Windows servers ;-).

It does not make much sense voluntarily use TWS for pure Unix, pure Windows or mixed Unix/Windows environments. TWS was not created for Unix environment and does things in a way that are completely un-natural for Unix administrators.  In absence of mainframes and AS400 servers in the environment almost any other scheduler is a better deal. TWS  is just too expensive, with too primitive GUI and rather basic capabilities.

For smaller environments a simpler, more modern solutions would be a better deal. For example Open Source Job Scheduler.  Many other, more modern,  alternatives exist: see Job schedulers.  For example CISCO Tidal is one commercial alternative, OpsWise is another but there are many other variants. Much depends on how you plan to integrate it with the monitoring system that you are using. 

The key point is that for smaller, single datacenter environments return on investment from TWS deployment is probably negative due to high administration costs and "per core" pricing of the product.  The other important factor is that generally, if you accept large enterprise mantra "we are using a single provider for out scheduling and monitoring solution"  you need to license this product with some other Tivoli components. If you want to stay within Classic Tivoli components typically TEC and TCM are used with TWS (and IBM reps helpfully navigate you toward this solution), while in "New Tivoli" minimum configuration would be TWS, ITM 6.x and TPM 5.1 as well (Netcool might be needed for non-trivial correlation tasks, if any).  

This is not strictly necessary as TWS can be integrated with any monitoring system including open source. But in this case IBM tech support became much less useful and the quality of IBM technical support is the primary reason to use TWS. Also the question arise why in this case would you want to use TWS ? For example Oracle Scheduler is free with database and is much more modern product  that you can integrate in various ways with various monitoring system including Oracle Enterprise Manager  Both can be leveraged in various ways based on the strengths and programmability of  Oracle database.   You can run into the same Java problems with better and cheaper product that also has an excellent support ;-) 

In any case, I think it is fair to state that  deployment of TWS in large enterprise environment usually involves licensing of several additional Tivoli products and that substantially adds to the costs, especially maintenance costs. The latter can run into quarter or half-million per year even in case of just five hundred servers (or if you unlucky even less then that).  Rule of thumb is one hundred thousand dollars per each hundred servers.  That means that product adds $1K or more to the annualized cost of the server (or $5K for the lifespan). As the share of  Intel servers is quickly growing due to their high price/performance ratio  this can easily double the total cost of ownership of small 4 core servers like Dell PE1950 and Dell PE2950.  For all practical purposes with the current IBM licensing structure TWS is too costly to use on Intel servers.

It also goes without saying that it does not make much sense voluntarily use TWS for pure Unix environment. TWS was not created for Unix environment and does things in a way that are un-natural for Unix administrators.  Recent versions of TWS (starting with 8.4) can use SSH  for "agentless scheduling" using which you can somewhat cut costs, excluding servers that run just one of two jobs a day from the list of clients ( see Agentless scheduling with Tivoli Workload Scheduler). But still the question, why on earth you want to use TWS on Unix remains open.  

TWS 8.5 provides traditional for enterprise schedulers set of  scheduling capabilities including "on event" job invocation. The latter is important for such situations as exceeding threshold of used disk space in a partition. But the real return on investment here is questionable as many of those things with much less effort can be accomplished by using "scripting envelopes" for jobs.  In reality, too complex scheduling is a self-defeating exercise as excessive complexity always backfire. The top complexity that one probably can adopt is "critical path scheduling" when you distinguish jobs on so called critical path (and they are sequential) and peripheral jobs which can run in parallel to critical path jobs and which in case of failure can be rerun, replaced with other jobs or just ignored.

One of the key attractions of  TWS in large enterprise environment is high level of tech support IBM provides ( but see some additional remarks below). Another attraction is high scalability: the maximum number of workstations in a single TWS network according to IBM is 100K (IBM2009). At the same time, scalability is not a big problem for schedulers in general as the amount of work performed per task is not large and is comparable with the mail server processing of one email.  And a regular Sendmail based server on Core Duo 2 based Intel server easily handles loads of up to 100 messages per second. 

On the administration side of the house, the product is also nothing to boast about: archaic, complex and counterintuitive to manage. It  really smells 1970th. While formally it belongs to Tivoli line it has nothing to do with classic Tivoli. It is a separately bought  product and integration with TEC is very superficial and architecturally weak.  TWS also uses a separate client-side agents  (with the most common called fault tolerant agents -- FTA; essentially replicas of  "mothership" TWS without graphical interface) which are not integrated with classic Tivoli framework agent.

Also key features of framework related to job scheduling are completely ignored (ability to distribute scripts to endpoints (central repository option), event based invocation of scripts (it was introduced only in 8.4 using independent and conceptually different implementation).

Documentation is horrible even by IBM standards.  My impression is that it became gradually worse from version 8.2 to version 8.5: some simple concepts adequately explained in 8.2 documentation are completely incomprehensible in the documentation to version 8.5.  Just compare explanation of how to create the first production plan in TWS 8.2 and TWS 8.5 documentation and you will understand the difference.   User guide for version 8.5 is a real masterpiece of technical nonsense, perfect example of how not to write technical documentation.   

Some TWS-related Redbooks are OK and provide much better insight into TWS capabilities, functioning and administration. Unfortunately most of them are outdated: none covers version 8.5.  Still they are better starting point for beginners then documentation. See Documentation/Redbooks

Versions 8.3-8.5 use IBM Embeddable Websphere Application Server (in case of TWS 8.5 this is embeddedEXPRESS which is a pretty complex and rather fragile product. It is different enough from standard Websphere Base Server to inflict huge headache in case the installation fails (and it can if, for example,  you do not patch AIX 5.3 server -- Java crash prevents installation from finishing), but you can run TWS using standard Websphere v.6 as well and that is a much better solution. While installation is a rare event and IBM provide good support for it, unless successful from the first try, it can became kind of  patience training in disguise, like in case of Java crash on AIX 5.3:

For all practical purposes installation requires close communication with IBM support (or external consultant) and the problems aggravated by the fact that  in my experience TWS support is not that helpful for resolving pretty common problems. You can spend days, possibly weeks, studying manuals and searching the web just to get the simplest initial setup work.  For most large multinational organization that can benefit from TWS this is not a problem, but I would warn small and medium size firms who for some reason believe in IBM marketing.

Normally TWS is an agent-based solution: it executes batch file on remote servers that have so called FTA agents. Monitoring job completion status was first  implemented via TEC, but now also be  done via Candle (ITM 6.x) without Tivoli framework.  That can save large organizations some money as TWS + Candle maintenance is almost twice cheaper than TWS+TMF+TEC+ITM.  The drawback are more limited correlation capabilities but few organization use TEC correlation capabilities to any significant extent.

There is a low quality, confusing Java-based GUI called Job Scheduling Console which  (after some training to overcome idiosyncrasies) permits for the administrator to create jobs and specifies rules by which jobs are scheduled (e.g., every payday), specify job sequences (some jobs may have to follow certain other jobs) or other constrains (certain jobs cannot run at the same time or only so many jobs can run at one time).  It was created an after though and that shows (original TWS used command line scheduling which still remain a preferable mode). The job constrains specification language is ad hoc but pretty capable. 

It appears with 8.5 the JSC has been phased out in favor of a web console called  "Tivoli Dynamic Workload Console" or TDWC. Configuring is covered in Administration and usage in User guide.  Coverage is  pretty poor, but that's all we have. Version 8.4 has separate Dynamic Workload Console Installation and Troubleshooting Guide. In case you are new to TWS and need to work with dependencies calling IBM tech support might be the best deal.  

TWS provides some degree of fault tolerance by having the ability to fall over to the second, reserve instance. Also FTA agents on nodes are capable of running already scheduled jobs regardless of the availability of the "mothership". 

TWS is composed of three major parts:

  1. IBM Tivoli Workload Scheduler engine. This is local client installed on every workstations which belong to the scheduling network (UNIX, Windows). When the engine is installed on a workstation, it can be configured to play a specific role in the scheduling network. For example, the engine can be configured to be a master domain manager, a domain manager, or a fault-tolerant agent. In an ordinary Tivoli Workload Scheduler network, there is a single master domain manager at the top of the network.
  2. IBM Tivoli Workload Scheduler connector. The connector "connects" the Job Scheduling Console to Tivoli Workload Scheduler, routing commands from JSC to the Tivoli Workload Scheduler engine. It is usually installed on the master domain manager (MDM).
  3. Job Scheduling Console (JSC). JSC is a primitive, low quality Java-based graphical user interface. It is typically installed on Windows workstations. Installation usually causes no problems.  It provides, through the Tivoli Workload Scheduler connector, a very limited subset of functions of the command-line programs conman and composer.


A Tivoli Workload Scheduler network is made up of  two main components:

The workstation types can assume the following roles:

The Most Important TWS Scheduling Terms

The following four terms are frequently used in TWS documentation:

Additional TWS Terminology

Like most IBM products TWS uses a lot of somewhat strange additional terminology

Workstation Classes

A workstation class is a group of workstations. For example you can have Classes based on type of OS installed: Solaris, AIX, HP-UX, Linux and Windows. Any number of workstations can be placed in a class.

Job streams and jobs can be assigned to run on a workstation class, creating possibility to use different jobs for different types of operating systems and like.

A domain is a named group of Tivoli Workload Scheduler workstations, consisting of one or more workstations and a domain manager acting as the management hub. All domains have a parent domain, except for the master domain.
A calendar is a list of scheduling dates defined in the scheduler database. Assigning a calendar run cycle to a job stream causes that job stream to be run on the days specified in the calendar. Since a calendar is defined to the scheduler database, it can be assigned to multiple job streams.
Prompts are used as dependencies for jobs and job streams. A prompt must be answered affirmatively for the dependent job or job stream to launch. For example, you can issue a prompt to make sure that a printer is online before a job that prints a report runs.
Parameters are used to substitute values in jobs and job streams. Since parameters are stored in the Tivoli Workload Scheduler database, all jobs and job streams that use the particular parameter are updated automatically when the value changes. For scheduling, a parameter can be used as a substitute for all or part of:
Files are dependencies whose existence a job or job stream must verify before they can start.


Lists are filters that allow objects in the database and in the plan to be filtered. There are standard default lists available in the Job Scheduling Console, or you can create lists that are specific to your needs.


The scheduler database stores scheduling object definitions. Examples of common scheduling object definitions are:

Starting the Job Scheduling Console

To start the Job Scheduling Console.

  1. Depending on your platform, start the Job Scheduling Console in one of the following ways:
    On this platform ... In the ..\bin\java subdirectory of the installation path ...
    Microsoft Windows NT(R), 2000, XP Enter NTconsole, or double-click the Job Scheduling Console icon on the Windows Desktop, or from the Start menu, if created at installation time.
    AIX(R) Enter . / or use the shortcut icons, if created at installation time.
    SUN Solaris Enter . / or use the shortcut icons, if created at installation time.
    HP-UX Enter . / or use the shortcut icons, if created at installation time.
    Linux Enter . / or use the shortcut icons, if created at installation time.

Useful framework commands

These commands can be used to check your Framework environment.

This command ... Performs this function ...
wlookup -ar ProductInfo Lists the products installed on the Tivoli server.
wlookup -ar PatchInfo Lists the patches installed on the Tivoli server.
wlookup -ar OPC Engine
wlookup -ar Maestro Engine
Lists the instances of this class type (same for the other classes). Examples:
barb    1318267480.2.19#OPC::Engine#
barb    1318267480.2.19#Maestro::Engine#
The number before the first period (.) is the region number and the second number is the managed node ID (1 is the Tivoli server). The whole numeric string is the object ID. In a multi-Tivoli environment, you can determine where a particular instance is installed by looking at this number because all Tivoli regions have a unique ID.
wuninst -list * Lists all the products that can be uninstalled.
wuninst {ProductName} -list * Lists the managed nodes where a product is installed.
wuninst -a * Lists all products and patches
  1. Before using the commands marked with an asterisk (*), you must first enter a bash.
  2. For these commands to work, you must run /etc/tivoli/ to source the Framework environment.

Top Visited
Past week
Past month


Old News ;-)

My Tech Notes and Stuff TWS 8.3 Install

Cleanup Commands: do not do in production:

ResetPlan -scratch


Get things started after reset (only on a new setup):


Set limit:


lc ;10

Do a test command job from conman:

sbd "ls";logon=batch

Do a test script job from conman:

sbf "/path/to/";logon=batch

Do this when resetting plan for the day and do not want to extend (if there is a problem)

JnextPlan -for 0000 # To not extend the plan (i.e. just reset for today)

Show schedule


Show jobs


IBM - Installing required libraries on Linux to run TWS

The following error is received when you run conman on Linux:

/twsul631/maestro/bin/conman: error while loading shared libraries: cannot open shared object file: No such file or directory


To run Tivoli Workload Scheduler on Linux, you need to ensure that certain Linux libraries are on your system. These libraries are not distributed with Tivoli Workload Scheduler (TWS) but must be obtained from your Linux provider. Depending upon your Linux vendor, the version of Linux you are using, and the architecture of your system, these libraries can be obtained in a variety of ways.

NOTE: is no longer used by Tivoli Workload Scheduler applying FP2, is used instead. This means that must be installed from official RPM for RHEL 3 or compatibility (official) RPM for RHEL 4 and SLES 9 if not already present.

A description of the methods to locate and install these libraries follows:

o Red Hat Enterprise Linux, versions 3 and 4, and SuSe Linux Enterprise Server, version 9

1. Search the media on which your copy of Linux was provided to you for the relevant library listed below. The libraries to locate are:

or their most recent compatible version.

IBM - Replacing the Symphony file on an FTA

IBM - Automating TWS Fix Pack Installs

Relationship between TWS Symphony and Sinfonia files

Agentless scheduling with Tivoli Workload Scheduler

Starting from TWS 8.4 ssh based agent is available and can be used for agentless scheduling

IBM Fixes by version for Tivoli® Workload Scheduler - United States

TWS v8.5 : No Fix Packs are yet available for this version of TWS as of 30 September, 2009. This document will be updated when the first Fix Pack is released. (Date to be determined.)

TWS v8.4 : (The latest Fix Pack as of 30 September, 2009 is 8.4.0-TIV-TWS-FP0004)

TWS v8.3: (The latest Fix Pack as of 30 September, 2009 is 8.3.0-TIV-TWS-FP0007)

NOTE: It is highly recommended to apply the same level or higher of the Job Scheduling Console (JSC) version 8.3 or v8.4 Fix Pack as your Master's engine Fix Pack level. In some cases, the Fix Pack provided for the TWS engine will not have a corresponding Fix Pack for the JSC. Ensure that you have the highest level of the JSC Fix Pack that is available.

JSC v8.4 : (The latest Fix Pack as of 30 September, 2009 is 8.4.0-TIV-TWSJSC-FP0003)

JSC v8.3 : (The latest Fix Pack as of 30 September, 2009 is 8.3.0-TIV-TWSJSC-FP0006)

NOTE: This is compatible with TWS v8.3 engine with Fix Pack 07 installed.)

NOTE: It is highly recommended to apply the same level or higher of the Tivoli Dynamic Workload Console (TDWC) version 8.4 or 8.5 Fix Pack as your Master's engine Fix Pack level.

TDWC v8.4 (The latest Fix Pack as of 30 September, 2009 is 8.4.0-TIV-TDWC-FP0003)

TDWC v8.5 (The latest Fix Pack as of 27 March, 2009 is 8.5.0-TIV-TDWC-FP0001)

IBM - Tivoli Workload Scheduler Newsletter

IBM Tivoli Support Technical Exchange (STE) web seminars
Extend your technical skills and knowledge of your IBM Tivoli products by participating in free Tivoli Support Technical Exchange web seminars (STE). This highly technical web seminar series is brought to you by IBM Software Services for Tivoli. STE web seminars cover a wide variety of technical topics from advanced product usage to deployment, integration, trouble shooting and tips and tricks. Only the best subject matter experts from Tivoli Support, Services, Training and Development are asked to develop and host these sessions so you will have ample opportunity to ask questions or discuss technical issues with the most knowledgeable experts IBM has to offer. Many new seminars are offered every month so be sure to look for topics of interest on a regular basis. Most sessions are 1 to 2 hours in length.
For web conference and call in details click on STE

A library of over 2 years of recorded Support Technical Exchange web seminars is also available on the same page.

Forthcoming / Recent STEs
STE's are normally finalised (and full details are then available) 2 - 3 weeks before the session. Click on Support Technical Exchange for the latest STE details.

Below is a list of recentSTE's, click on Support Technical Exchange to hear a replay of the session

TWS Enablement team is extending the successful "Ask the Expert" Initiative with weekly sessions open to TWSz Customers planning to move/adopt new releases. If you want to know more, send an email to [email protected] and book your session!

TWS Technical Support Information Update

Orb Data - IBM Tivoli Workload Scheduler 8.3 Administration

In the IBM Tivoli Workload Scheduler Suite 8.3 Administration course students will study ... Determine which TWS workstations need Framework installed ...

IBM Redbooks Integrating IBM Tivoli Workload Scheduler with Tivoli Products

Contains some info on how to ingrate TWS 8.5 with TEC.

This IBM Redbook explains the benefits and technical merits of integrating IBM Tivoli Workload Scheduler Distributed and IBM Tivoli Workload Scheduler for z/OS with other IBM products. Scheduling is a mission critical process for any company. However, when you talk about scheduling, you are really talking about an ecosystem. In this ecosystem, each solution is a building block that adds value to the overall solution. With IBM Tivoli Workload Scheduler, you can collect and add data to and from each component. In addition, expanding the scheduling ecosystem to include monitoring, management, help desk, storage, and business systems management provides greater value.

This book discusses all these integration points and provides detailed scenarios on how to integrate IBM Tivoli Workload Scheduler with these types of applications.

Because workload management is widely considered the nucleus of the data center, there are numerous opportunities for you to integrate IBM Tivoli Workload Scheduler with other products. This book addresses just some of these many opportunities. In terms of integration with IBM Tivoli Workload Scheduler, do not limit yourself to the products that this book discusses. Integration points discussed in this book should give you an idea of the potential value that IBM Tivoli Workload Scheduler integration can provide for your company.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles


Related publications

The Tivoli Software Glossary includes definitions for many of the technical terms related to Tivoli software. TheTivoli Software Glossary is available at the following Tivoli software library Web site:




Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: July 28, 2019