||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|
To install, configure, and start the Scheduler agent on a remote Windows, Linux, or UNIX host:
- Log in to the remote host.
- For Windows, log in as an administrator.
- For UNIX and Linux, log in as the user that you want the Scheduler agent to run as. This user requires no special privileges.
- Run the Oracle Universal Installer (OUI) from the installation media for Oracle Database Gateway.
- For Windows, run
- For UNIX and Linux, use the following command:/directory_path/runInstaller
directory_pathis the path to the Oracle Database Gateway installation media.
- On the OUI Welcome page, click Next.
- On the product selection page, select Oracle Scheduler Agent, and then click Next.
- On the Specify Home Details page, enter a name and path for a new Oracle home for the agent, and then click Next.
- On the Oracle Scheduler Agent page:
- In the Scheduler Agent Host Name field, enter the host name of the computer on which the Scheduler agent is to run, or accept the default host name.
- In the Scheduler Agent Port Number field, enter the TCP port number on which the Scheduler agent is to listen for connections, and then click Next.
Choose an integer between 1 and 65535. On UNIX and Linux, the number must be greater than 1023. Ensure that the port number is not already in use.
- On the Summary page, click Install.
- (UNIX and Linux only) When the Oracle Universal Installer prompts you to run the script
root.sh, enter the following command as the
The script is located in the directory that you chose for agent installation.
Once the server configuration is complete, we need to install the Oracle Scheduler Agent on the machine we wish to run remote jobs against. The agent software is on the Transparent Gateways disk available with the database software downloads from Oracle Technology Network. After running the installer, proceed with the following installation.
On the "Welcome" screen, click the "Next" button.
Select the "Oracle Scheduler Agent" option and click the "Next" button.
Enter the appropriate name and path for the Oracle home, then click the "Next" button.
Enter the hostname and port for the agent installation, then click the "Next" button. This is the hostname for the machine running the agent, not the database server. The port should be an unused port greater than 1023.
Click the "Install" button on the "Summary" screen.
Wait while the installation takes place.
Once the installation is complete, click the "Exit" button and "OK" the subsequent message dialog.
Once the agent installation is complete, register it against any databases wishing to run external jobs on this machine using the
schagentutility, passing in the hostname of the database and the HTTP port of XML DB. The
schagentutility is present in the "$ORACLE_HOME/bin" directory of the agent installation.TheC:\>cd C:\app\oracle\product\11.1.0\tg_1\bin C:\app\oracle\product\11.1.0\tg_1\bin>schagent -registerdatabase bart.localdomain 8080 Agent Registration Password ? ************* * Oracle Scheduler Agent Registration Agent Registration Successful! C:\app\oracle\product\11.1.0\tg_1\bin>
schagentutility is also used to stop and start the agent on UNIX style platforms.On Windows platforms, simply stop and start the <home-name>_OracleSchedulerExecutionAgent service.$ schagent -stop $ schagent -start
The agent configuration information is stored in the "$ORACLE_HOME/schagent.conf" file.
CredentialsCredentials are database objects that hold a username/password pair for authenticating local and remote external jobs. They are created using the
CREATE_CREDENTIALprocedure in the
DBMS_SCHEDULERpackage. The procedure also allows you to specify the Windows domain for remote external jobs executed against a Windows server. Credentials owned by SYSInformation about credentials is displayed using theCONN test/test BEGIN -- Basic credential. DBMS_SCHEDULER.create_credential( credential_name => 'TIM_HALL_CREDENTIAL', username => 'tim_hall', password => 'password'); -- Credential including Windows domain. DBMS_SCHEDULER.create_credential( credential_name => 'TIM_HALL_WIN_CREDENTIAL', username => 'tim_hall', password => 'password', windows_domain => 'localdomain'); END; /
[DBA|ALL|USER]_SCHEDULER_CREDENTIALSviews.Credentials are dropped using theCOLUMN credential_name FORMAT A25 COLUMN username FORMAT A20 COLUMN windows_domain FORMAT A20 SELECT credential_name, username, windows_domain FROM user_scheduler_credentials ORDER BY credential_name; CREDENTIAL_NAME USERNAME WINDOWS_DOMAIN ------------------------- -------------------- -------------------- TIM_HALL_CREDENTIAL tim_hall TIM_HALL_WIN_CREDENTIAL tim_hall LOCALDOMAIN 2 rows selected. SQL>
DROP_CREDENTIALprocedure.For backwards compatibility, it is not mandatory to specify credentials for local external jobs. If no credentials are set the default users are:EXEC DBMS_SCHEDULER.drop_credential('TIM_HALL_CREDENTIAL'); EXEC DBMS_SCHEDULER.drop_credential('TIM_HALL_WIN_CREDENTIAL');
Oracle recommend using credentials for all local and remote external jobs as the default values may be deprecated in future.
- Jobs in the SYS schema run as the user who installed the Oracle software.
- The default user for non-SYS jobs on UNIX platforms is specified by the
run-groupattributes in the "$ORACLE_HOME/rdbms/admin/externaljob.ora" file.
- The default user for non-SYS jobs in Windows platforms is the user running the "OracleJobSchedulerSID" Windows service.
The operating system user specified by the credential must have the necessary privileges to perform the required action. On Windows platforms this must include the "Log on as batch job" security policy, applied using the "Local Security Policies" dialog.
Creating Remote External JobsRemote external jobs are similar to local external jobs. Both require a
PROGRAM_TYPEfor program definitions, set to 'EXECUTABLE'. Commands and batch files that require parameters must set the parameters using the
SET_JOB_ARGUMENT_VALUEprocedure. The following job performs a directory listing of the "/tmp" directory. Notice how the directory name is specified as a parameter. In addition to setting the
CREDENTIAL_NAMEattribute, the job also includes the
DESTINATIONattribute, signifying this is a remote external job. This attribute is set to the "hostname:port" of the scheduler agent. If the
DESTINATIONattribute is not set, or set to "localhost", the job runs as a local external job.
Windows commands and scripts must be run using the "cmd.exe" executable with the first parameter of "/c". To perform an action similar to the previous example, we would need to use three parameters.BEGIN -- UNIX DBMS_SCHEDULER.create_job( job_name => 'unix_command_job', job_type => 'EXECUTABLE', number_of_arguments => 1, job_action => '/bin/ls', auto_drop => FALSE, enabled => FALSE); DBMS_SCHEDULER.set_job_argument_value('unix_command_job',1,'/tmp'); DBMS_SCHEDULER.set_attribute('unix_command_job', 'credential_name', 'TIM_HALL_CREDENTIAL'); DBMS_SCHEDULER.set_attribute('unix_command_job', 'destination', 'marge.localdomain:65001'); DBMS_SCHEDULER.enable('unix_command_job'); END; /The documentation suggests this should be all that is necessary to run a remote external job, but this does not seem to be the case. Unlike local external jobs, it appears remote external jobs run as detached jobs, so Oracle does not know when they are complete. It is up to job itself to tell Oracle when it is complete by calling theBEGIN -- Windows DBMS_SCHEDULER.create_job( job_name => 'win_command_job', job_type => 'EXECUTABLE', number_of_arguments => 3, job_action => 'C:\windows\system32\cmd.exe', auto_drop => FALSE, enabled => FALSE); DBMS_SCHEDULER.set_job_argument_value('win_command_job',1,'/c'); DBMS_SCHEDULER.set_job_argument_value('win_command_job',2,'dir'); DBMS_SCHEDULER.set_job_argument_value('win_command_job',3,'C:\'); DBMS_SCHEDULER.set_attribute('win_command_job', 'credential_name', 'TIM_HALL_WIN_CREDENTIAL'); DBMS_SCHEDULER.set_attribute('win_command_job', 'destination', 'marge.localdomain:65001'); DBMS_SCHEDULER.enable('win_command_job'); END; /
END_DETACHED_JOB_RUNprocedure.This raises a couple of questions:BEGIN DBMS_SCHEDULER.end_detached_job_run('UNIX_COMMAND_JOB'); DBMS_SCHEDULER.end_detached_job_run('WINDOWS_COMMAND_JOB'); END; /
- One of the proposed benefits of remote external jobs is you don't need an Oracle installation on the server executing the job, just an agent installation. If the script needs to call the
END_DETACHED_JOB_RUNprocedure, this will require an Oracle client installation.
- The requirement to manually end the detached job run means the functionality for returning stdout and stderr doesn't work for remote external jobs as described in the documentation.
Returning stdout and stderrThe
DBMS_SCHEDULERpackage includes a
GET_FILEprocedure for returning the stdout and stderr created by calls to external jobs. Local external jobs write stdout and stderr information to files in the "$ORACLE_HOME/scheduler/log" directory on the database server. Remote external jobs write this information to the "$AGENT_HOME/data/log" directory on the remote server.
When a local external job completes, information about the run is written to the
ADDITIONAL_INFOcolumn of the
[DBA|ALL|USER]_SCHEDULER_JOB_RUN_DETAILSview, including a name value pair of the
EXTERNAL_LOG_ID. Concatenating "_stdout" or "_stderr" to this external log ID gives you the name of the file to pass into the
GET_FILEprocedure as the
SOURCE_FILEparameter. To see this in action create a local external job similar to that of the previous examples.Next, query theBEGIN DBMS_SCHEDULER.create_job( job_name => 'local_unix_command_job', job_type => 'EXECUTABLE', number_of_arguments => 1, job_action => '/bin/ls', auto_drop => FALSE, enabled => FALSE); DBMS_SCHEDULER.set_job_argument_value('local_unix_command_job',1,'/tmp'); DBMS_SCHEDULER.set_attribute('local_unix_command_job', 'credential_name', 'TIM_HALL_CREDENTIAL'); DBMS_SCHEDULER.enable('local_unix_command_job'); END; /
USER_SCHEDULER_JOB_RUN_DETAILSview to retrieve the
EXTERNAL_LOG_IDand use this value to return the stdout using the
The documentation claims this functionality will also work with remote external jobs in the same way, but there is a problem here as these jobs appear to run as detached jobs, so it is up to the script to notify Oracle when it is complete using theSET SERVEROUTPUT ON DECLARE l_clob CLOB; l_additional_info VARCHAR2(50); l_external_log_id VARCHAR2(50); BEGIN SELECT additional_info, external_log_id INTO l_additional_info, l_external_log_id FROM (SELECT log_id, additional_info, REGEXP_SUBSTR(additional_info,'job[_0-9]*') AS external_log_id FROM user_scheduler_job_run_details WHERE job_name = 'LOCAL_UNIX_COMMAND_JOB' ORDER BY log_id DESC) WHERE ROWNUM = 1; DBMS_OUTPUT.put_line('ADDITIONAL_INFO: ' || l_additional_info); DBMS_OUTPUT.put_line('EXTERNAL_LOG_ID: ' || l_external_log_id); DBMS_LOB.createtemporary(l_clob, FALSE); DBMS_SCHEDULER.get_file( source_file => l_external_log_id ||'_stdout', credential_name => 'TIM_HALL_CREDENTIAL', file_contents => l_clob, source_host => NULL); DBMS_OUTPUT.put_line('stdout:'); DBMS_OUTPUT.put_line(l_clob); END; / ADDITIONAL_INFO: EXTERNAL_LOG_ID="job_88372_27729" EXTERNAL_LOG_ID: job_88372_27729 stdout: gconfd-root hsperfdata_oracle keyring-9TWYY7 keyring-WnjRiP mapping-oracle mapping-root orbit-root sealert.log ssh-KWaTN22006 virtual-root.tr3Sbw vmware-config0 PL/SQL procedure successfully completed. SQL>
END_DETACHED_JOB_RUNprocedure. This procedure optionally accepts an
ADDITIONAL_INFOparameter, so it is up to the script to provide the necessary
EXTERNAL_LOG_IDto support the
GET_FILEprocedure functionality. To see this we will repeat the previous example as an external job by setting the
If we check the remote server, the stdout file is present.BEGIN DBMS_SCHEDULER.create_job( job_name => 'remote_unix_command_job', job_type => 'EXECUTABLE', number_of_arguments => 1, job_action => '/bin/ls', auto_drop => FALSE, enabled => FALSE); DBMS_SCHEDULER.set_job_argument_value('remote_unix_command_job',1,'/tmp'); DBMS_SCHEDULER.set_attribute('remote_unix_command_job', 'credential_name', 'TIM_HALL_CREDENTIAL'); DBMS_SCHEDULER.set_attribute('remote_unix_command_job', 'destination', 'marge.localdomain:65001'); DBMS_SCHEDULER.enable('remote_unix_command_job'); END; /
We can identify the# pwd /u01/app/oracle/product/11.1.0/gt_1/data/log # ls job_88373_8_stdout job_ids #
EXTERNAL_LOG_IDis "job_88373_8" by looking at the stdout file name, or by checking the contents of the "job_ids" file.
Next, signal the end of the job run by passing the external job ID information to the# cat job_ids job_88373_8 "DB11G.WORLD" "oel5-11g.localdomain" "TEST" "REMOTE_UNIX_COMMAND_JOB" - "tim_hall" "/bin/ls" #
Retrieve the contents of the stdout file in the same way as before, but this time pass the agent location information in theBEGIN DBMS_SCHEDULER.end_detached_job_run( job_name => 'remote_unix_command_job', error_number => 0, additional_info => 'EXTERNAL_JOB_ID="job_88373_8"'); END; /
SOURCE_HOSTparameter of the
SET SERVEROUTPUT ON DECLARE l_clob CLOB; l_additional_info VARCHAR2(50); l_external_log_id VARCHAR2(50); BEGIN SELECT additional_info, external_log_id INTO l_additional_info, l_external_log_id FROM (SELECT log_id, additional_info, REGEXP_SUBSTR(additional_info,'job[_0-9]*') AS external_log_id FROM user_scheduler_job_run_details WHERE job_name = 'REMOTE_UNIX_COMMAND_JOB' ORDER BY log_id DESC) WHERE ROWNUM = 1; DBMS_OUTPUT.put_line('ADDITIONAL_INFO: ' || l_additional_info); DBMS_OUTPUT.put_line('EXTERNAL_LOG_ID: ' || l_external_log_id); DBMS_LOB.createtemporary(l_clob, FALSE); DBMS_SCHEDULER.get_file( source_file => l_external_log_id ||'_stdout', credential_name => 'TIM_HALL_CREDENTIAL', file_contents => l_clob, source_host => 'marge.localdomain:65001'); DBMS_OUTPUT.put_line('stdout:'); DBMS_OUTPUT.put_line(l_clob); END; / ADDITIONAL_INFO: EXTERNAL_JOB_ID="job_88373_8 EXTERNAL_LOG_ID: job_88373_8 stdout: command gen_cfg2html.txt hsperfdata_oracle hsperfdata_root hsperfdata_tim_hall orbit-oracle orbit-root PL/SQL procedure successfully completed. SQL>
Disabling Remote External Job FunctionalityTo prevent a database from executing remote external jobs, simply drop the
SQL> DROP USER REMOTE_SCHEDULER_AGENT CASCADE;
Detached JobsDetached jobs allow you to run jobs in a separate processes, independent of the scheduler. If it is an external job, it is also independent of the database state, meaning the job continues to run after the database is shutdown. Once a detached job is initiated, the scheduler marks the job as running then ceases to track its progress. It is up to the detached job to signal its completion using the
END_DETACHED_JOB_RUNprocedure. The following example creates an external job to restart the database, proving the job runs independently of the database state.
First create a script owned by the oracle user called "restart_db_script" with the following contents.Notice how the last action of the SQL script is the call to the#!/bin/bash export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=$ORACLE_BASE/product/11.1.0/db_1 export ORACLE_SID=DB11G export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib $ORACLE_HOME/bin/sqlplus / as sysdba <<EOF SHUTDOWN IMMEDIATE; STARTUP; EXEC DBMS_SCHEDULER.end_detached_job_run('restart_db_job', 0, null); EOF exit 0
END_DETACHED_JOB_RUNprocedure to signal that the job is complete.
Make sure the script is executable.
Next, connect to SQL*Plus as the SYS user and create a program object to run the script. Make sure the$ chmod u+x restart_db
DETACHEDattribute is set to TRUE.
Next, create a job that runs immediately using the program.CONN / AS SYSDBA BEGIN DBMS_SCHEDULER.create_program( program_name => 'restart_db_program', program_type => 'executable', program_action => '/u01/app/oracle/dba/restart_db_script', enabled => TRUE); DBMS_SCHEDULER.set_attribute('restart_db_program', 'detached', TRUE); END; /You can watch the background processes shutting down and restarting using the "ps -ef | grep ora" command. Once the database is back you can query theBEGIN DBMS_SCHEDULER.create_job( job_name => 'restart_db_job', program_name => 'restart_db_program', enabled => TRUE); END; / DISCONNECT
DBA_SCHEDULER_JOB_RUN_DETAILSview to check the status of the job.CONN / AS SYSDBA SELECT status, run_duration FROM dba_scheduler_job_run_details WHERE job_name = 'RESTART_DB_JOB'; STATUS RUN_DURATION ---------- -------------------- SUCCEEDED +000 00:01:12 1 row selected. SQL>
Lightweight JobsRegular jobs, like programs and schedules, are schema objects and as such take time to create and drop. Under normal circumstances this overhead is hardly noticeable, but it can become apparent when you need to create large numbers of short-lived jobs. For example, you may wish to use jobs to decouple processes, or to parallelize them. In these circumstances you may see improved performance using lightweight jobs.
Lightweight jobs have a
JOB_STYLEattribute of 'LIGHTWEIGHT', the default being 'REGULAR', and must be based on a program object with an object type of 'PLSQL_BLOCK' or 'STORED_PROCEDURE'. Lightweight jobs are not schema objects and therefore require less meta data, so they have quicker create and drop times. Since they are not schema objects, you cannot grant privileges on them, so lightweight jobs inherit their privileges from their referenced program objects.
The following example compares the creation time for regular and lightweight jobs. First, create a program suitable for a lightweight job. In this case, the PL/SQL block does no work.
The following script displays the time taken to create 100 lightweight jobs and 100 regular jobs.BEGIN DBMS_SCHEDULER.create_program( program_name => 'lightweight_program', program_type => 'PLSQL_BLOCK', program_action => 'BEGIN NULL; END;', enabled => TRUE); END; /The output clearly shows there is less overhead associated with the creation of lightweight jobs.SET SERVEROUTPUT ON DECLARE l_start NUMBER; BEGIN l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. 100 LOOP DBMS_SCHEDULER.create_job ( job_name => 'lightweight_job_' || i, program_name => 'lightweight_program', job_style => 'LIGHTWEIGHT', enabled => TRUE); END LOOP; DBMS_OUTPUT.put_line('LIGHTWEIGHT (hsecs): ' || (DBMS_UTILITY.get_time - l_start)); l_start := DBMS_UTILITY.get_time; FOR i IN 1 .. 100 LOOP DBMS_SCHEDULER.create_job ( job_name => 'regular_job_' || i, program_name => 'lightweight_program', job_style => 'REGULAR', enabled => TRUE); END LOOP; DBMS_OUTPUT.put_line('REGULAR (hsecs): ' || (DBMS_UTILITY.get_time - l_start)); END; / LIGHTWEIGHT (hsecs): 174 REGULAR (hsecs): 412 PL/SQL procedure successfully completed. SQL>
Scheduler Support for Data GuardThe Oracle 11g scheduler now supports Data Guard environments, allowing jobs to be run dependent on their role in the environment.
In physical standby configurations, all scheduler changes are applied to the physical standby. In logical standby configurations jobs can be created to run specifically on the primary or logical standby database. This is done by setting the
DATABASE_ROLEjob attribute to 'PRIMARY' or 'LOGICAL STANDBY'. During a switchover or failover, the new role of the database is recognized and the appropriate jobs will be run based on the new role.
BEGIN DBMS_SCHEDULER.create_job ( job_name => 'primary_job', program_name => 'primary_job_prog', schedule_name => 'primary_job_schedule', enable => TRUE); DBMS_SCHEDULER.set_attribute('primary_job','database_role','PRIMARY'); END; /
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 quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard 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 DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting 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
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How 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-2020 by Softpanorama Society. www.softpanorama.org 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|
Last modified: March 12, 2019