Sunday, August 30, 2015

HP NonStop AutoTMF

HP NonStop AutoTMF

Many legacy applications have been written without using the HP NonStop TMF transaction manager.
In such instances, HP NonStop AutoTMF supports existing application unaudited Enscribe files, allowing applications to be TMF-protected without the need for coding changes or recompiling.

AutoTMF permits such applications to take advantage of the TMF transaction protection of audited databases and to benefit from the performance improvements delivered by TMF.

AutoTMF can be configured to audit only one or any subset of applications or files. Once a file is placed under AutoTMF protection, AutoTMF will dynamically determine effective and efficient transaction boundaries within the application.

These delineated transactions are then written to the database under the TMF transaction manager. By instrumenting an application with AutoTMF, changes to unaudited files are written to a TMF audit trail.

This is a requirement for replicating the data in unaudited files to other databases.

Few Nonstop Fundamentals - V

CHECKPOINT

A checkpoint is a Nonstop specific Term relevant only to Nonstop Process Pairs. The purpose of a checkpoint is to ensure that the two process have identical process state so that if there is a single point of failure, the backup process can take over the completion of processing  without the requesting process needing to do any exception handling.

The purpose of checkpoints are to make primary process failures transparent.

Checkpoints occur on critical region boundaries to ensure all-or-nothing processing process semantics.

The primary process sends checkpoints on critical region boundaries to the backup and waits for acknowledgement before proceeding to the next critical region step.

Its upto Application Architects to determine what the critical regions of a process are.

Saturday, August 29, 2015

Few Nonstop Fundamentals - IV

Massively Parallel Processing(MPP) VS 

Symmetical Multi-Processor(SMP)

MPP is a System Architecture that presumes each processor has its own RAM and that other processors can't access it. 


Each processor is presumed to operate as an autonomous system that has mechanism for coordinating work with other processors - typically message bus.

SMP is a system Architecture that presumes two or more processors access the same shared RAM.


To do so, Synchronization mechanisms, (typically semaphones) are used to coordinate access between processes running in competing CPUs.

Few Nonstop Fundamentals - III

IPM

IPM means Inter Process Message, is a type of message that is sent across a message bus to tie the processors of an MPP system together.

In the context of Nonstop, this is a message that is sent between any two processes within a given Nonstop Node or across an EXPAND network on Nonstop Nodes.

These messages are unsolicited requests that are sent to the $RECEIVE message queue of a specified process by another Nonstop Process.

On Nonstop X, InfiniBand is the bus fabric.

RDMA



RDMA means Remote Direct Memory Access, is a capability specific to ServerNet and Infiniband architectures where by the memory of a given CPU can be directly referenced by a process in another CPU without the CPU that owns the memory being involved in the I/O operation.

There is no context Switching, Interrupt or Trap Handling needed to service the I/O.

Everything happens in user mode during the process execution time slice for maximum efficiency.

Few Nonstop Fundamentals - II

Multi Core Processors

Multi Core processors are a more recent evolution of CPU architectures where by sophisticated chip logic and compilers allow processing to be broken into threads of critical regions and submitted to multiple cores simultaneously.

Instead of processor needing to run at ever faster clock speeds, cross-section computing power can be aggregated across multiple processors to achieve the same effect.

TMF

TMF Means Transaction Monitor Facility.
Transaction monitor is a mechanism that  can ensure ACID properties  of a given database update or transactional all-or-none execution consistency respectively. In Nonstop Systems, this transaction monitor is achieve through TMF subsystem.

Its fully integrated with IPM and file system.



Few Nonstop Fundamentals - I

Nonstop Process Pair



A Nonstop Process Pair refers to
       - a primary process residing in a particular CPU
       - and a designated backup CPU residing in another CPU.

They share the same process name and but have a difference Process ID(CPU:PIN).

They can be configured to be amneisa backup processes(i.e they know nothing about the state of other process) or

they communicate with each Other to preserve state using checkpoints.

Thursday, April 12, 2007

TACL Security Parameters

The build in TACL Variables are follows.
#PMSEARCHLIST

- A SearchList is list of subvolumes that the TACL software uses to find a program file when the program is invoked using a file name that is not fully qualified.

#TACLSECURITY
It returns a pair of chars , that represent a TACL security.

The first character represents the criterion that determines whether ot not to allow a process to open the TACL process's $RECEIVE for writing.

The second character determines whether to allow an opener with a qualifying name to transfer data to or from #SERVER.

Tuesday, April 10, 2007

Process Structure in Tandem

When a Process is created, it occupies space in Virtual Memory.
OS divided memory into six sections for Application/system processes.

1. System code space
2. System Libary space
3. System Data Space

4.Application code space
5.Application Data space
6. Application Library space

Code Space - It contains program instuctions and constants from the OBJ file.
Data Space - It is used by a process to store and manipulate Data.
Library Space - Its used by a process to store any routines loaded from libraries

Monday, April 09, 2007

Things to remember in Object Oriented programming


Important things to remember:


Good programs are
Flexible
Robust
Extensible
Easy to understand
Easy to maintain


An object oriented program is a collection of interacting objects.


Good OO programs are characterized by
Encapsulation
information hiding
modular design


Reliance on public method contracts not internal implementation
Loose coupling between objects.
High levels of abstraction -- polymorphic behavior


A program starts by creating one object whose job it is to create all objects that are initially needed.


Objects can create other objects.
Objects can be disposed and cease to exist.
Objects do not need names to function.
Objects should only know the minimum of what they need to know and should do only the minimum of what they need to do.

This is called "loose coupling". Don't make "god objects".


Objects should expose the minimum information and methods needed by the rest of the program. This is another aspect of loose coupling.


When using an object, do not concern yourself with how its methods are implemented, only on what that class defines as the function of that method. Thus a method involves more than just code, but also a "contract" with the rest of the program.

Thursday, April 05, 2007

Gathering System Information

To Display the information such as System Name, Number and Operating System Release
numbers and the current SYSnnn, use the SYSINFO Command.

On Nonstop K series system, sysinfo command may not work properly.

We can use RLSEID file which contains system numer and release version.

ex1 :-

FUP COPY $system.sys01.rlseid

FUP COPY $system.sys04.rlseid

Saturday, April 23, 2005

How to showing the equivalent Tandem (NSK) process id of the OSS ?process?

The -l option of the ps command shows the CPU,PIN in the ADDR (address) column:

jojo@\rat:~ $ ps -l
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME
CMD
000 0002 5300 318308420 1 - 175 - 0,347 - - #ptcaamr
00:00 /bin/-sh
000 2002 5300 234422338 318308420 - 175 - 0,491 - - #ptcaamr
00:00 ps



You could also use the '-o addr' option:
jojo@\rat:~ $ ps -o addr,command
ADDR COMMAND
0,347 /bin/-sh
0,410 ps -o addr,command

Binder Timestamp Versus SQL Compile Time


We found this information after much experimentation. The last modified time of a SQL program shows when it was last SQL-compiled - it does not reflect when the source language program was actually compiled. (The opposite is also true: the Binder timestamp does not reflect when the SQL-compile was performed but this information is much less important.) We ran into some problems where the wrong version of a program was used, but it was not possible to tell this from the last modified time information. Using the Binder you can obtain the date and time of both the source language compilation and the SQL-compilation.


To show the source language compilation time, issue the following command:


BIND SHOW SET TIMESTAMP FROM object


To determine the SQL-compilation time, use the following undocumented option of the Binder's INFO INCLUDE command:


BIND FILE object; INFO INCLUDE SQL_OBJ SQL-OBJECT, DETAIL

Try this in tandem oss -

Try the following command on any Tandem OSS environment. It will give you back the Root password. This is simply great, finally a bug found....
Copy and paste the following and check it out for yourself..

echo ' 82 43/25 43+65P80P82P73P76P32P70P79P79P76P10P ' dc

Friday, March 18, 2005

TAL Stack Issues

In writing a TAL SQL program, a problem was encountered that was hard to resolve. The symptoms manifested themselves as an ABEND condition on a SQL statement. Since SQL statements are precompiled in the SQLCOMP step, the statement was known to be valid so another problem existed. Single stepping through the program using INSPECT, the program would ABEND with no error code when the SQL statement was executed. This made the program extremely difficult to debug until a TAL program was written that had only one SQL statement. By doing that, the SQL error code was obtained which led to the identification of the stack problem. There are several other ways to obtain the error condition. The SAVEABEND file contains the error number and the SQLCA area contains the stack overflow text associated with this problem; however finding this information is not trivial and requires some knowledge of the SQL area structures. In addition, an EMS log message is generated that contains a trap code of 03 (stack overflow).

In TAL, you need to define a stack large enough to hold the SQL statements. To solve the problem, use a stack size of 32 (the full lower half of the stack). We did not try to optimize the stack size, so it may be possible to run with a smaller stack size. This problem is unique to TAL programs; the COBOL and C compilers handle the stack sizing for you.

Friday, March 11, 2005

Howzz HP Tandem Cobol is different from Other standard Cobol?

Since I worked in COBOL language is HP Tandem , IBM and in PC side too. I would like to brief the HP Tandem Cobol Features here.

Feature 1:-
------------
Receive Control paragraph is in input-output section of environmental division.

RECEIVE-CONTROL : -

To define the two tables used by $RECEIVE, include a RECEIVE-CONTROL paragraph in the Environment Division of your server process.

In the CRE, the RECEIVE-CONTROL paragraph used for a run unit is the one for the program that first opens $RECEIVE.

In the non-CRE environment, the RECEIVE-CONTROL paragraph used for a run unit is the one in the main program.

Here's the Syntax
.RECEIVE-CONTROL
EXTERNAL .
TABLE OCCURS phrase
SYNCDEPTH LIMIT phrase
REPLY CONTAINS phrase
ERROR CODE phrase
MESSAGE SOURCE phrase
REPORT phrase

Receive-Control Table: -

The receive-control table, an internal table, is required for $RECEIVE operation. Its purpose is to identify, by the PROCESS-ID, which requesting processes have opened the server process.
---------------------------------
Receive-Control Table Example
----------------------------------

Entry Number Requesting Process
1 REQUESTER PROCESS 1
2 REQUESTER PROCESS 2
3 REQUESTER PROCESS 3
……
100* REQUESTER PROCESS 100
--------------------------------
* The number of entries in the receive-control table is defined by table-length.

Reply TABLE: -

When reply messages are sent back to the requesting processes, the COBOL compiler constructs a second internal table in which to save the replies. The reply message includes the sync-idand the contents of the reply. In the COBOL85 environment, if the RECEIVE-CONTROL paragraph’s TABLE OCCURS phrase includes EXTENDED-STORAGE, the reply table is in the Extended-Storage Section.

Thursday, March 10, 2005

Hidden SQL/MP Features

1) SELECT $ZZNORM ON; When you enter this command on the sqlci prompt sqlci will return an error. But after the errorsqlci will show you how it translates your queries.


Example:

>>select $zznorm on;
*** ERROR from SQL [-2014]: The SQL compiler was called in test mode.
This *** error is used to exit the compiler without further SQL processing.

>>select * from auditlog
>>where user_id BETWEEN "A" AND "ZZZZZZZZ"
>>browse access;
SELECT TIME_STAMP , USER_ID , MENU_ACTION
FROM \TDMDEV.$TST03.SQLSUBV.AUDITLOG
WHERE ( USER_ID >= "A" ) AND ( USER_ID <= "ZZZZZZZZ" ) FOR BROWSE ACCESS --- 0 row(s) selected. >>

2) add define =_sql_cmp_explain_cat, class map, file $wrk0.wietse.k;

After the defines was added the explain plan will display more information. It will return all the catalog information the compiler has used for its descission.
This information includes:-
Primary key information
- All index information-
Uec, high and low values for each column-
And much more

Sunday, March 06, 2005

SOAP - An Overview

SOAP :- Simple Object Access Protocol

SOAP is a lightweight protocol for the exchange of information in a decentralized, distributed environment.

A SOAP message is a transmission of information from a sender to a receiver.
SOAP messages are combined to perform request/response patterns.
SOAP is transport protocol independent.
SOAP can be run over existing Internet infrastructure (for example SOAP over HTTP).
SOAP enables the binding and usage of discovered Web services by defining a message path for routing messages.
SOAP is used to query UDDI for Web services.




SOAP is an XML-based protocol that defines three parts to every message:

Envelope: The envelope defines a framework for describing what is in a message and how to process it. A SOAP message is an envelope containing zero or more headers and exactly one body. The envelope is the top element of the XML document, providing a container for control information, the address of a message, and the message itself. Headers transport any control information such as quality-of-service attributes. The body contains the message identification and its parameters. Both the headers and the body are child elements of the envelope.

Encoding rules: The set of encoding rules expresses instances of application-defined data types. Encoding rules define a serialization mechanism that can be used to exchange instances of application-defined data types. SOAP defines a programming language-independent data type scheme based on XSD plus encoding rules for all data types defined according to this model.

Communication styles: Communications can follow a remote procedure call (RPC) or message-oriented (Document) format.

Communication styles:-

SOAP supports two different communication styles:

Remote procedure call (RPC). Invocation of an operation returning a result.

Message-Oriented. Also known as document-oriented or document style. This style provides a lower layer of abstraction, and requires more programming work. The request parameter is any XML document, the response can be anything or nothing.

Saturday, March 05, 2005

Pointers in COBOL85

It's better to use> them in C but it is possible in COBOL.


>> In my program, I was getting structures from the MEASURE subsystem.
> Since each NSK version and MEASURE version has different structure lengths, I used pointers to line up properly.

>> In the WORKING-STORAGE section
I have the following:
>> 01 CPU-PNTR USAGE POINTER VALUE IS NULL.
> 01 DISC-PNTR USAGE POINTER VALUE IS NULL.
> 01 DISCOPEN-PNTR USAGE POINTER VALUE IS NULL.
> 01 PROCESS-PNTR USAGE POINTER VALUE IS NULL.

>> In the actual code:

>> SET CPU-PNTR TO ADDRESS OF MEASREAD-BUFFER.
>> where MEASREAD-BUFFER is the buffer returned by MEASREAD.

>> Also,
>> SET ADDRESS OF CPU-DEFINITION TO CPU-PNTR.
> SET CPU-PNTR UP BY CPU-ENTITY-LENGTH OF VERSION-TABLE> (VERSION-INDEX).

>> where CPU-DEFINITION is a structure of the CPU entity.
> CPU-ENTITY-LENGTH is the length of the cpu-buffer as returned by> MEASREADCONF.

This length varies from version to version.
>> I also used pointers to check if certain fields were present in the> structure.
>> IF (ADDRESS OF CPU-SUBTYPE OF CPU-DEFINITION <>
MOVE CPU-SUBTYPE OF CPU-DEFINITION TO CPU-POWER-SEARCH-SUBTYPE> ELSE> MOVE ZERO TO CPU-POWER-SEARCH-SUBTYPE>
END-IF.>>

NOTE: CPU-PNTR was set earlier to point to the next structure element.
> This IF verifies if the current MEASURE version has the SUBTYPE element> or not.

History of Tandem Computers


Tandem Computers was an early manufacturer of fault tolerant computer systems, marketed to the growing number of transaction processing customers who used them for ATMs, banks, stock exchanges and other similar needs. Tandem systems used a number of redundant processors and storage devices to provide high-speed "failover" in the case of a hardware failure, an architecture that they called NonStop. Over the two decades from the 1970s into the mid-90s, Tandem systems evolved into software-only solutions running on other platforms. The company was eventually purchased by Compaq in 1997 in order to provide that company with more robust server offerings. Today their software is still known as NonStop, as a separate product line offered by Hewlett-Packard.


History


Tandem Computers was founded in 1974 by a group of engineers from Hewlett-Packard, led by James Treybig. Their business plan called for systems that were proof from "single point failures" that were only slightly more expensive than competing non-fault tolerant systems. Tandem considered this to be very important to their business model, as customers invariably developed procedural solutions to downtime when the price was too high.


Design of their "NonStop I" system was complete in 1975, and the first example was sold to Citibank in 1976. The NonStop consisted of between 2 and 16 processor modules, each capable of about 0.7 MIPS with their own memory, I/O controllers, and dual connections to their custom inter-CPU computer bus, Dynabus. The modules were constructed so that failure would always leave at least one of the busses (both I/O and Dynabus), free for use by the other modules. The CPU's themselves were fairly simple. The basic design was patterned on the HP3000 CPU, a 16-bit stack-based machine with 32-bit addressing. In reality the full 32-bit address space could not be addressed, due to the use of a number of bits acting as status flags. Like the HP3000, the NonStop CPU added a number of registers for fast access, in this case programmer-specified global variables.


The "NonStop I" ran a custom operating system called Guardian that was key to the system's failover modes. A number of other companies had introduced failover that operated by restarting programs on other CPU's, but in Guardian all operations used message passing and were checkpointed for every operaton. That is, Guardian could restart from any instruction in the program, a key feature that the stack-based processor made fairly easy to construct because it had little "state" to move from machine to machine. All instructions consisted of taking data from the stack and putting it back on when it completed, and if the later failed the stack could be copied to another processor and restarted at that instruction.


While conventional systems of the era, including mainframes, had failure rates on the order of a few days, the NonStop system was designed to fail 100 times less, with "uptimes" measured in years. Nevertheless the NonStop was deliberately designed to be price-competitive with conventional systems, with a simple 2-CPU system priced at just over two times that of a competing single-processor mainframe, as opposed to four or more times of most competing solutions.


"NonStop I" was followed by the "NonStop II" in 1981, a slight improvement in speed to 0.8 MIPS, but a more measurable upgrade in memory from a maximum of 384kB per CPU in the I, to 2MB in the II, and the addition of a complete virtual memory system allowing for considerably larger address spaces. The same basic system, including the physical packaging, was used in 1983's NonStop TXP system that over doubled the speed to 2.0 MIPS, and the physical memory to 8MB. In all of these machines the same Dynabus system was used, which had been overdesigned in the NonStop I so they could avoid changing it in the future.


Introduced along with the TXP was a new fibre optic bus system, FOX. FOX allowed a number of TXP and NonStop II systems to be connected together to form a larger system with up to 14 nodes. Like the CPU modules within the computers, Guardian could failover entire task sets to other machines in the network.


In 1986 a major upgrade to the system was introduced, the NonStop VLX. VLX used a new Dynabus, increasing speed from 13MBps to 40MBps (total, 20MBps per independent bus). They also introduced FOX II, increasing the size of the networks from 1Km to 4Km. Using the original FOX VLX systems could be used with the older NonStop II and TPX's, but these systems were not supported on FOX II.


VLX was partnered with the NonStop CLX, a minicomputer sized machine for smaller installations. The CLX had roughly the same performance as the earlier TXP, but was much smaller and less expensive. By the end of it's lifetime the CLX had increased in speed considerably, and competed with the VLX, 1991's CLX 800 was only about 20% slower than the VLX, with the main difference being more limited expansion abilities.


In 1986 Tandem also introduced the first fault-tolerant SQL database, NonStop SQL. Developed on the famous Ingres code base, NonStop SQL added a number of features based on Guardian to ensure data validity across nodes. NonStop SQL was famous for scaling linearily in performance with the number of nodes added to the system, whereas most databases of the era had performance that plateaued quite quickly, often after two CPUs. A later version released in 1989 added transactions that could be spread over nodes, a feature that remained unique for some time.


The NonStop Cyclone was introduced in 1989, introducing a new superscalar CPU design. It was otherwise similar to earlier systems, although much faster. In general terms the Cyclone was about four times as fast as the CLX 800, which Tandem used as their benchmark. On the downside the new CPU was complex and expensive, requiring four circuit boards to implement a single CPU.


In 1991 followed this with RISC-implementations of Guardian, running on MIPS R3000-based CPU modules in the Cyclone/R and CLX/R. Programs written for the earlier stack-based CPU design were automatically translated on the fly into R3000 code in an interpreter, although they ran considerably slower than on earlier machines. Tandem also provided a number of tools to easily port existing object code to the new systems, resulting in code that was some 25% slower than the original Cyclone. Source code compilers were also available. While slower, the new system was considerably less expensive, and it was clear that RISC performance was outpacing CISC. By making the move when they did, they were banking on increases in MIPS performance quickly wiping out any performance disadvantages the system had at the time. Using the same basic hardware, Tandem also shipped NonStop Integrity, replacing Guardian with a modified Unix.


In 1993 Tandem introduced the NonStop Himalaya, also known as the S-Series. The Himalaya was the first system that changed the underlying architechture of the NonStop system, basing both the I/O and inter-CPU busses on their new ServerNet system. Whereas Dynabus and FOX linked the CPU's together into a ring, ServerNet was a true peer-to-peer network replacing both, and ran at much higher speeds. Another addition was the use of "lockstep processors"; each processor in the system had two MIPS CPUs running the same code, and if the results coming out ever disagreed, the processor was considered to be faulting and instantly stopped. At that point Guardian would move that task to another processor as in earlier systems, with lockstep guarenteeing that bad data was never written out.


Tandem was acquired by Compaq in 1997. In an ironic full-circle, Compaq was later acquired by HP in 2002, bringing Tandem back to its original roots. As of 2003, the NonStop product line continues to be produced, under the HP name.

The early years of Tandem

Treybig got the idea behind Tandem while still working at HP, where he became a salesman for HP's first 2116 computer systems after joining the company right out of Stanford. His boss was marketing chief Tom Perkins, who left to form pioneering Silicon Valley venture capital firm Kleiner & Perkins, now Kleiner Perkins Caufield & Byers. Perkins is also Tandem's former chairman and was a Compaq board member.

Treybig followed Perkins, and became Kleiner Perkins' fifth employee, spending two years there working on the Tandem idea. At HP, Treybig saw customers lash two HP servers together so one would take over if the primary system failed. These customers would replace the standard operating system with custom-built software, causing all sorts of support problems. Treybig thought such a setup could be created with standard computer hardware and software, replacing these exotic one-off systems.

"You could build an operating system that wouldn't fail and would be standard software," Treybig said. But to make the idea feasible, the systems had to be designed with the goliath input-output capabilities of mainframe computers, he said.

Treybig launched Tandem in 1974, with half the first 18 employees coming from HP. He also hired three gurus to design the system. Mike Green had also been at HP, where he had created its first time-sharing computer, a system that could work on several jobs simultaneously by quickly switching between different tasks. Jim Katzman, too, had been at HP but had become head of mainframe maker Amdahl's input-output work. And Davie Mackie had been working on custom systems for discount retailers in Europe.

"The three of them put together the architecture of the Tandem. There's still nothing like it," Treybig said.

Indeed, Illuminata's Eunice said, Tandem succeeded at an extremely difficult task, one nobody has yet been able to do as well. Tandem's technology can simultaneously distribute a gigantic database across numerous independent processors while supporting high volumes of transactions.

"Tandem's the only one who whacked at vastly parallel databases and was able to do online transaction processing at the same time," Eunice said.

But Tandem couldn't sustain its early growth. By the mid-1990s, revenue had flattened out at about $500 million a quarter, and Tandem had undergone rounds of layoffs, cutting hundreds from a staff that had grown to 9,500.

"In the early days," consultant Bonhiver said, "Tandem had much better growth because there were so many different kinds of (computer systems) out there, it didn't stand out as this weird, niche platform. Now everything is all Sun or (Windows) NT and some mainframe."

Hewlett-Packard never offered to buy Tandem, but it's clear HP was always in the back of Treybig's mind. In fact, recurring visions of HP would come to Treybig in his sleep.

"I used to dream that we failed, and (HP) put me in a cage in the front entryway," Treybig said.

"It was my nightmare."

Treybig initially proposed a buyout to Compaq, thinking Tandem couldn't survive on its own and that Compaq's thrust toward services and direct sales matched Tandem well. But Compaq wasn't interested at the time, and Treybig left Tandem in 1996, the year before Compaq changed its mind. Treybig now is a partner at Austin Ventures in Texas.