|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better
|News||See also||Recommended Links||IBM Documentation||Field Guides||Redbooks||Patching|
|Gateways||Gateway Troubleshooting||Tivoli endpoints||Troubleshooting Endpoints||TEC||Advanced Monitoring||TWS|
|odadmin command||Troubleshooting||Tivoli Gateway Proxy and Tivoli security Toolkit||Performance tuning||Using log files for troubleshooting||The wtrace command||Installation|
|Backup with wbkupdb||The wtrace command||Task libraries||Tivoli predefined ports||Tips||IBM humor||Etc|
Tivoli Management Framework provides a set of services that enable you to monitor your environment and install add-on products on both Unix and Windows systems (mainframes are covered too). TMF was created before SSH was available and it provides the facilities to transfer files and execute commands on remote systems. The level of security can be set from none to high. It is dangerous to have low security as Tivoli endpoints can perform operations as root. It is based on now forgotten Corba. IBM plans to discontinue product in 2012 replacing it with patchwork of Candle and Netcool/Omnibus which they acquired in 2004 and 2005, respectively.
Conceptually there is one or more TMR (central servers) communicating with multiple endpoints. executables and regular file send be send back and forth. Gateways are used to lessen the load and cache the stream of alerts between endpoints and mothership. They also can perform some information filtering for TEC using .Tivoli State Correlation Engine .
Here are several IBM-style definitions:
Tivoli was far ahead of its time when it was released and it provide a rather flexible way to structure installation into a hierarchy of TMA so that each of them is more specialized and more flexible then if everything is done in a single management server. Unfortunately few organizations use this Tivoli capability.
For a large organization the Tivoli installation should be generally divided into a set of regions (often called policy regions), based on geography (for example North America, Canada and Latin America, platform (windows, Unix, etc), application used (for example SAP/R3 region, DMZ region) or importance (critical server region, important server region and regular server region).
Servers on which TMRs are installed can real or virtual, but independently of the type of the server used and server platform each TMR server has its own database (and that means that unless you use DB2 you need to take into account the cost of licensing) and running its own oserv daemon. These TMA then can be connected to each other, either hierarchically (one way connection when upstream TMR knows about resources of lower TMRs but not vice-versa) or horizontally (when each TMR has full symmetrical access toward resources of each other). As we mentioned before, resources can be servers, devices or services that need management.
The following is a list of Tivoli Management Framework components that enable you to perform management tasks. The key features include:
Other features include:
Most Tivoli systems management tasks, regardless of the application or component that is to be managed, may be performed by using the Tivoli desktop, which provides a user interface consistent throughout management applications.
The TMR server provides facilities required to manage the environment. One of its major distinguishing points is that it contains and controls the major portion of a distributed database that contains information regarding the managed resources and objects used to manage the environment. Depending on the size and requirements of an environment, there may be more than one TMR defined.
The Tivoli Framework includes both GUI and command line interfaces:
All Managed Nodes run the oserv daemon. Lately framework endpoints (Managed Nodes) were infested with Java (for example in case of Tivoli Advanced Monitoring 5.1 is deployed) with the connected to this Java VM hell problem that negatively affected the stability (Tivoli Advanced Monitoring 5.1 became stable shortly before is can be replaced with C++ based version 6.1 :-).
TMF 4.1.1 Upgrage Tivoli Framework
Posted: Jul 21, 2009 08:40:32 AM
I need your feedback about the new version of framework (4.3.1)
Before implementing ITM 6.2.1 (without framework), we need to update framework
which version choose ? (the latest FP for 4.1.1 or the new version 4.3.1)
One of the biggest differences I see between 4.2.3 and 4.3.1 is the addition of the adaptive bandwidth control. This will allow you to set up your environment for remote sites easier by not having to configure gateways/repeaters at a specific speed (net_load). This is the same feature that is in TPM and is a real nice to have.
The only other thing is that from what I am seeing, if you plan to upgrade to TPM/TPMfSW/TPDSW, you will need to be on 4.3.1. It seems that the migration paths are for 4.3.1, but that could change.
I know there are a few others, but this would be the main reasons that I would look at 4.3.1 over 4.2.3.
Gulf Breeze Software
Audience: Level 2 & 3 Support, Services, GTS, ITD, GBS, Business Partners, Sales, or Customers Abstract: This STE will cover: - Operating System Tuning - Network Tuning - Tivoli Tuning - Endpoint Communication Reliability - Gateway Log Messages - Endpoint Log Messages Presented by: Linda E. Miller-Plumley Date: August 4, 2009 11:00 AM Eastern US
Components of the Tivoli Framework architecture
The components of the Tivoli Framework architecture are:TMR region A Tivoli environment consists of one or more Tivoli regions. Each Tivoli region consists of a TMR server, one or more managed nodes, and multiple endpoints. The Tivoli regions can be interconnected. TMR stands for Tivoli Management Region. A Tivoli region is an entity that contains the Tivoli server and its clients. A Tivoli region contains three tiers of resources: the Tivoli server, managed nodes and gateways, and endpoints.
TMR server This is the main server in one Tivoli region. It can delegate and distribute tasks to managed nodes.
Managed node. This is subordinate to a TMR server and receives the binaries to be able to execute almost all of the commands by itself. The TMR server is also a managed node.
Gateway. Some managed nodes can be configured as a gateway. One gateway can typically take care of hundreds of endpoints. It receives the binaries to be able to download the code to endpoints. It is often used when customers have distributed sites and one gateway can be placed in each site, for example.
Endpoint. This is the agent code that runs at a target machine. Several different flavors of operating system are supported. This agent code is the base for several different Tivoli framework applications such as Enterprise Console adapters, remote control, inventory, and software distribution.
RIM host. One managed node in a region is configured to be an RIM host. The RDBMS's client code must be installed at this managed node. The function of this component is be able to connect to a relational database.
RDBMS server Some Tivoli products utilize a database, for example, inventory, TEC, and IBM Tivoli Configuration Manager (ITCM), so the customer has to provide a RDBMS server to implement those products.
Event server. This is the main component of the Tivoli Enterprise Console. It has to be installed at a managed node.
TEC console This is the component of the Tivoli Enterprise Console for the visualization of events.
TEC gateway This is the Tivoli Enterprise Console component that provides the function of a gateway between endpoints and the event server. Its code runs on a managed node.
TEC SCE gateway. The State Correlation Engine (SCE) is used to provide high-speed event filtering and event collection. It is normally located at a TEC gateway, but can be deployed on an endpoint.
TEC ACF gateway. This is the Tivoli Enterprise Console component that has the binaries to distribute Adapter Configuration Facility (ACF) profiles to endpoints.
TEC adapter. This is the code that collects the source information such as messages from logfiles (application and system) on targets. There are many available adapters that Tivoli Enterprise Console offers.
TEC adapter (non-TME). It is an adapter that does not require the Tivoli Framework infrastructure to send events. A TCP/IP socket connection will provide the connection from the adapter direct to the TEC server.
Tivoli desktop. This is the graphical interface from where Tivoli administrators can manage the resources.
Applying the Patch:
1) Extract the patch:
Extract the contents into a scratch directory. For the purpose of this release note, assume that the symbol $PATCH points to this directory.
# cd $PATCH
# tar xvf 4.1.1-TMF-0104.tar
3) Use the following steps to install the patch using the Tivoli GUI install mechanism.
NOTE: You must have the install_product and super authorization roles to successfully install this patch.
a) Select the "Install -> Install Patch..." option from the "Desktop" menu to display the "Install Patch" dialog.
b) Press the "Select Media..." button to display the "File Browser" dialog.
c) Enter the path to the directory containing the patch, $PATCH, in the "Path Name:" field.
d) Press the "Set Media & Close" button to return to the "Install Patch" dialog.
e) The patch install list now contains the name of the patch.
Select the patch by clicking on it.
f) Select the clients to install this patch on. This patch needs to be installed on the TME server and on each
managed node client.
g) Press the "Install" button to install the patch.
Additional Installation Instructions:
After applying this patch, perform the following numbered steps to restart the oservs on the TMR server and managed nodes / gateways.
1) From the TMR server, run the following command to shut down all managed nodes / gateways:
odadmin shutdown clients
2) When the client oservs have all terminated, run the following command to restart the TMR server:
odadmin reexec 1
3) Once the oserv on the TMR server has fully restarted, then run the following command to restart the managed nodes / gateways:odadmin start clients A full Oracle client is necessary for RIM to function correctly on Windows, AIX, HP-UX, Solaris, and Linux-ix86 platforms.
Note: The RIM agent runs as the user "nobody" on AIX, Solaris, and
Linux, and as the user "tmersrvd" on HP-UX and Windows. However,
recent versions of Oracle and DB2 have tightened the security of
default file permissions which locks out the nobody/tmersrvd user
from accessing important runtime libraries. The solution to this
problem is to change the file permissions to allow the nobody /
tmersrvd users access to the files.
1. Source the Oracle environment
2. chmod -R 755 $ORACLE_HOME
...the commands used to display which operating system level or patches are installed on various systems supported by Tivoli Management Framework.
- IBM® AIX® instfix -a
- HP-UX swlist
- Sun SolarisTo determine if a patch is installed, look for a directory with that name in /var/sadm/patch.
- Microsoft® Windows® Open Windows Explorer and click About Windows in the Help menu.
Operating system Swap space Process slots IBM® AIX® /usr/sbin/lsps -a /usr/bin/sar -v HP-UX /etc/swapinfo /usr/bin/sam Sun Solaris /usr/sbin/swap -s /usr/bin/sar -v Microsoft® Windows® In the System Properties dialog on the Control Panel, select the Performance tab, and click Change N/
Upgrade from Tivoli Management Framework 4.1.1 requirements
The steps in upgrading a Framework 4.1.1 environment to Framework 4.3.1 when SSL is used:
- Make a system backup of the installation. A system backup such as a tarball will contain the entire installation (database, binaries, data files) as opposed to wbkupdb which only backs up the database.
- Turn off SSL on all Managed Nodes in the installation.odadmin set_network_security none allodadmin shutdown clientsodadmin reexec 1odadmin start clients
- Upgrade all Managed Nodes to Framework 4.3.1. Upgrading Managed Nodes will distribute new certificates to these Managed Nodes.
- Install SSLA (GSkit 7) on all Managed Nodes in the installation. Restart the oserv for each Managed Node and verify that odadmin reports Network Security = none / SSL capable.
- Turn on SSL on Managed Nodes.odadmin set_network_security SSL allodadmin shutdown clientsodadmin reexec 1odadmin start clients
- Verify that all the managed nodes restarted successfully.
- Use the "odadmin odinfo" command to verify that SSL is enabled on all managed nodes. You can now change the network security level of managed nodes to SSL or FORCE_SSL if you need to.
- Upgrade note: Because of changes in the supported version of Oracle software, different upgrade scenarios must be used. The following information will help you decide your required upgrade path to maintain a working Tivoli environment.
- Tivoli Management Framework, Version 4.3.1 supports Oracle 10g and Oracle 11g.
- Tivoli Management Framework, Version 4.1.1 supports Oracle 8.1.7 and Oracle 9i (Release 2).
- Tivoli Management Framework, Version 3.7 Revision B, Tivoli Management Framework, Version 3.7.1, and Tivoli Management Framework, Version 4.1 support Oracle 8.1.7.
- Tivoli Management Framework Version 3.7.1 and Tivoli Management Framework, Version 4.1.1 support Oracle 9i (Release 2).
To upgrade Tivoli Management Framework on an AIX® operating system with an Oracle client, perform the following steps using the System Management Interface Tool (SMIT):
- To change the characteristics of asynchronous I/O, enter the following command:smith chaio
- From the menu, select State to be configured at system restart.
- Change the value of this option from defined to available.
- Press Enter.
- Exit SMIT by pressing F10.
- Restart the system by entering the following command:shutdown -r
- The -e option of the lcfd command is ignored and has no effect when the lcfd is started. An lcfd.id file is created and each endpoint returns a unique ID whether this option is specified or not. If there are multiple endpoints on one machine, each endpoint is installed in a different directory, and a separate lcf.id file is created for each endpoint.
- As a result of APAR IY30330, object dispatchers create additional threads to improve performance. The default value of 250 for rpc_max_threads, which sets the thread limit for concurrent remote procedure calls, should be sufficient for most deployments. However, some customers might need to increase the rpc_max_threads value using the odadmin command. If your rpc_max_threads value is set too low, you might see an error message such as "method fork failed" or "RPC Request rejected outstanding threads: number_of_threads_running."
- Kerberos and the following commands are disabled: kadmin, kadmind, kdb_destroy, kdb_edit, kdb_init, kdb_util, kdestroy, kerberos, kinit, klist, kpasswd, ksrvtgt, kstash.
- The following Tivoli GNU Revision Control System (RCS) commands are disabled: wci, wco, wident, wmerge, wrcs, wrcsdiff, wrcsmerge, wrlog.
- ADE and AEF are disabled.
- Tier 2 support is being deprecated and will be disabled at the next release of Tivoli® Management Framework.
- The Tivoli desktop for OS/2 is supported at the Tivoli Management Framework 4.1.1 level.
- The OS/2 and NetWare gateways are supported at the Tivoli Management Framework 4.1.1 level.
- The SIS is supported at the Tivoli Management Framework 4.1.1 level.
- Commands run in the Tivoli environment are referred to as methods. To increase security, Tivoli runs methods with the lowest possible authority. This often means that methods run as the unprivileged nobody account. Also, in many scenarios the method runs as the login ID of the Tivoli administrator who issued the command. A method will run as the root user only when it is required. This increases security because the method has very little authority in the operating system. However, this increased security requires that all users have read and execute access to the Tivoli install tree. Tivoli does not make use of setuid or setgid binaries (this can be verified using the following examples: $BINDIR -perm 4000 -o -perm 2000 -o -perm 6000). Because Tivoli does not use setuid or setgid binaries, there is no security hole by allowing users to execute Tivoli binaries; the binaries are not be able to do anything that they cannot already do on the system.
- Applications not linked to Version 3.7.x libraries or higher cannot take advantage of port consolidation or SSL over their BDT channels. For example, an application built on Tivoli Management Framework, Version 3.6.x does not have access to the new features of SSL encryption and port consolidation for BDT channels. These applications perform IOM and other BDT operations in the pre-3.7.1 manner; that is, according to the port range and without SSL.
Note:A managed node or application that is not SSL-capable cannot encrypt BDT or oserv communications using SSL.
Implications include the following:
- Use caution when specifying the FORCE_SSL option on SSL-capable nodes in a Tivoli environment where incapable managed nodes or applications exist. Version 3.6.x applications, pre-3.7.1 managed nodes, and certain interps are not capable of communicating with SSL. For example, you cannot consolidate BDT operations between Tivoli Desktop for Windows and a Tivoli server set to FORCE_SSL. The same is true for any Version 3.6.x-linked applications; that is, FORCE_SSL options within the Tivoli environment can cause the applications to fail to operate.
- In a Tivoli environment where 3.6.x applications are in use, it might not be possible to tighten firewall restrictions to the full extent intended by the design of single-port BDT. Configuring your firewalls to be restricted according to single-port BDT design can cause 3.6.x applications to fail if and when they attempt to make BDT connections. Keep in mind that pre-3.7.1 managed nodes also are not capable of using single-port BDT.
Recommendation: You should not modify firewall configurations to take advantage of port consolidation if you are using either of the following within the firewall environment:
- Tivoli Enterprise products that were not designed to take advantage of Tivoli Management Framework, Version 4.1 features
- Pre-3.7.1 managed nodes
In either case, the existing firewall configurations for pre-3.7.1 communications should remain unchanged. If this is a new Tivoli implementation, you can set up the firewall configuration to use the pre-3.7.1 based port range settings.
- The BDT service runs in its own process, named bdt_service.
Because two processes cannot use the same port, there is a built-in failover when a BDT port is in use. Instead of the gateway failing, the gateway process attempts to open the specified BDT port (for example, port 13000), waiting 10 seconds between each attempt (up to a maximum of 3 times). If the port is still in use, the bdt_service process increases the value of the port by 1 (for example, 13000 to 13001) and attempts to use that port. If the port+1 value also is in use, the bdt_service fails to start.
This section contains the known software limitations for Tivoli Management Framework, Version 4.3.1.
- Adaptive Bandwidth Control
Adaptive Bandwidth Control is only supported on Windows and Linux Gateways. All endpoint types are supported. Adaptive Bandwidth may increase the CPU load on the Gateway. A dual-core processor or better should be used when enabling adaptive bandwidth control.
Adaptive is designed to sense the network and give priority to other network traffic. There are scenarios where the algorithm may not have enough information to accurately determine network load. In this case, it will always error on the side of caution ... slowing down rather than sending too quickly. If adaptive is sending too slowly, it can be "reset" by pausing and then resuming the distribution.
Adaptive will not work if the gateway sender is also the source of an IPSec encrypted tunnel. IPSec will encrypt the information that adaptive requires to determine network load.
wmdist -s adaptive_log_level=3
or 4 is for detailed tracing, and will generally create too many log messages for a production environment.
- Defect 179228: The oserv may fail to start on Solaris 10 unless inetconv is used to convert inetd.conf entries into SMF service manifests:inetconv -i /etc/inetd.conf.
- Defect 136410: The installation of a Tivoli server or managed node on a UNIX system creates a special account under which Tivoli operations run. These account differ by operating system. Ensure that the /etc/passwd file on the system has one of the following accounts defined:
- For AIX
- For HP-UX
- tmersrvd:*:59999:59999:Reserved forTME:/:/bin/false
- For Solaris
When this account does not exist, Tivoli Management Framework randomly selects an account ID under which it runs required operations. As a rule, Tivoli Management Framework selects an account ID high enough so that conflicts do not occur. To ensure that these conflicts do not arise, add the appropriate line to the /etc/passwd file.
- For shell scripts to run on Windows endpoints, you must place a dependency on sh.exe on the run_task method of the TaskEndpoint object. The dependency causes sh.exe to be downloaded when a task is run on a Windows endpoint, if it is not already there. Follow these steps to define the dependency:
- Get the object ID (OID) of the current dependency set (if any) associated with the run_task method:wchdep -g Classes:TaskEndpoint run_task
- Create the dependency:wdepset -c task-library-tool-base \ -a w32-ix86 bin/w32-ix86/tools/sh.exe +a +p %TOOLS% \ -a w32-ix86 bin/w32-ix86/tools/win32gnu.dll +a +p \ %TOOLS%
- If there is not an existing dependency set, associate the dependency with the run_task method on the TaskEndpoint object:wchdep @Classes:TaskEndpoint \ @DependencyMgr:task-library-tool-base run_taskIf there is an existing dependency set, add a nested dependency set to the existing dependency set:wdepset -e current_depset_OID \ -a depset @DependencyMgr:task-library-tool-base
- Synchronize the gateway's method cache with the Tivoli server database:wgateway gateway dbcheck
where gateway is the name of your gateway.
Complete these steps for each gateway.
- Defect 225205: The mdist2_db2_sql script may fail on DB2 9.x version. There are changes between DB2 8.x and DB2 9.x that cause an additional error message to be displayed when creating the mdist2 database.
SQL5153N The update cannot be completed because the following relationship would be violated:softmax <= 100 * logprimary
The error is generated when this statement in mdist_db2_admin.sql is executed:UPDATE DATABASE CONFIGURATION FOR mdist2 USING LOGPRIMARY 2;
DB2 9.x differs from DB 8.x in that autoconfig is turned on. If autoconfig is turned on then databases created have dynamically generated values for configuration parameters such as SOFTMAX. The dynamically generated value is often 520 whereas the default value is 100.
The "softmax <= 100 * logprimary" error message can be ignored in which dynamically configuration values are used including for LOGPRIMARY since the attempt to set it failed. Alternatively the error message can be prevented by turning off autoconfig prior to creating the mdist2 database:db2set DB2_ENABLE_AUTOCONFIG_DEFAULT=NO
Variables such as the above may be viewed:db2set -all
Once the the mdist2 database is created and connected to with the above set it's SOFTMAX value may be viewed:db2 get db cfg | grep SOFTMAX
Percent log file reclaimed before soft chckpt (SOFTMAX) = 100
The above value should works correctly with mdist_db2_admin.sql
- APAR IY34015: The Sybase RIM agent does not work with Sybase open client version 12.5 on AIX. Sybase 12.5 does not automatically include links between the Sybase 12.5 libraries and the Sybase 12.0 names.
Workaround: To manually link the Sybase 12.5 and Sybase 12.0 libraries, perform the following steps:
- Source the Sybase environment.
- Navigate to the $SYBASE/OCS-12_5/lib directory.
- Use the following commands to link the CT and CS libraries:ln -s libct.so libct.so.a ln -s libcs.so libcs.so.a
- Test the RIM object again.
- Defect 166989: Viewing lcfep statistics while uninstalling an endpoint can cause visual corruption in the window tabs.
Workaround: Click OK to close the lcfep statistics window, then reopen the window by clicking the task tray icon.
- Defect 128718: The $LCF_DATDIR/updata directory is created when allow_proxy_upcalls is set to TRUE.
Workaround: To prevent the $LCF_DATDIR/updata directory from being created each time the endpoint starts, set filefree_upcalls=TRUE before setting allow_proxy_upcalls=TRUE.
- Defect 130738: When migrating an endpoint from a gateway with encryption level NONE to a gateway with encryption level DES, you will receive errors when attempting a downcall.
Workaround: After migrating the endpoint, run the wep set gateway –g gw_label command. You do not need to run this command when the migration is between gateways with the same encryption level.
- Defect 149821: Endpoints not at the 431xx, or 41xxx level cannot log in to a multicast-enabled gateway.
Workaround: Upgrade the endpoint to at least the 43100 level.
April 17, 2008
There is a recent discussion on the Tivoli mailing list about what IBM/Tivoli is going to do about the old Tivoli Framework product. There have been some suggestions from customers that IBM keep a lighter version of the product and support it. As I close in to about 15 years of working with "This Beast" here are some of my thoughts.
The economics of IBM supporting the Framework are basically impossible
Top 10 Framework Reality check.
1) It is not a revenue producing product. .
2) The code base is around 20 years old.
3) The code base is based on pre Corba v1 specs.
4) The code base is mostly C and all of the original developers are gone.
5) Java not C is IBM's core competency.
6) Very few people inside or outside of IBM understand the ORB and object repository architecture of the Framework
7) A re-write of the Framework has been tried twice and both times were disasters. Almost all of Tivoli's revenue producing code base is not supported and will never be supported on the Framework.
9) No bean counter in IBM would approve new funding for a Framework project.
10) The suggestion is that the software will support it self. In the software business that is not an option. The product is either supported and in which case it needs to be tested on every new operating system release and protocol change or it is not supported.
IBM/Tivoli has been a Frameworkless ship floating along for many years now. First they were going to replace the framework with the TPM agent architecture and that never panned out. Then they were going to replace the Framework with a WAS based architecture (then they acquired Candle). If you think about it IBM has developed very little software in the last 10 years. As Tivoli fiercely struggles to integrate almost 10 billion dollars worth of newly acquired software my guess is that updating and maintaining the Framework are the last things on their minds.
Just my .02 cents
Download package What is DD?
Download RELEASE DATE LANGUAGE SIZE(Bytes) Download Options 4.1.1-TMF-0104.tar 9/23/2008 English 111400000 FTP DD 4.1.1-TMF-0104.README 9/23/2008 English 226000 FTP DD 411TMF104.image.rpt 9/23/2008 English 134000 FTP DD
Framework 4.1.1 has the "j" parameter for winstlcf which defines installation via ssh. ... You need to modify the ssh client configuration file in /etc/ssh/ssh_config and ensure that StrictHostKeyChecking is set to no (the default is yes ).
Google matched content
**** Tivoli Enterprise Installation Guide good, if outdated, intro to the installation structure
Redbook Maintaining Your Tivoli Environment (2001)
Tivoli Management Framework /Planning for Deployment Guide Version 4.1.1
IBM Redbooks An Introduction to Tivoli Enterprise
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-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and 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 make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: March 12, 2019