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.

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.

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

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.

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.