Re: Newbie playing with pathway.

[Bill Honaker]

Your example program simply writes data to STDOUT, which in your configuration is not configured.
It most likely tried to write that to the OUT File PATHLOG, and failed due to sharing.
In any case, it would have terminated on the 'return 0' statement and not continue running.
Another point, that sample program is not written as a pathway server. Your server configuration appears to have been for a COBOL program.
To run as a server, the C program needs to interact with $RECEIVE and pay attention to opens from processes.
Step 5 of your 'run' script is the only one that ran the program normally, you should probably have seen the 'Hello world' output there.

In addition your compilation script was overly complicated, since it took a 'runnable' executable (execo) and then rebound it.
You should also consider using a 'Native' compiler, which one depends on which system you're running on.

It's completely unclear what you are trying to accomplish, this doesn't appear to be related to any conceivable job on a NonStop?


On Fri, 10 Jun 2016 01:45:02 -0700 (PDT), sola lee <solalee...@gmail.com> wrote:

>Helo to all the SIFUs of HPNS and Tandem,
>
>I am a new kid on the block playing with Tandem and C program.
>
>Basically trying to create a simple Hello World program in C (HELOC)
>Then setup a simple pathway to run that hello world (HELOX)
>that is all :)
>
>I don't know how to get it to run :)
>
>
>
>My C program
>=======================================
>#include <stdio.h>
>int main(int argc, char* argv[]){
> printf("\n\nHello World\n\n");
> return 0;
>}
>=======================================
>
>
>
>
>My compilation script (I copied and paste from somewhere)
>=======================================
>C /IN HELOC/HELOO; RUNNABLE
>
>#SET #INLINEPREFIX +
>BIND/INLINE/
>+ SELECT CHECK PARAMETER OFF
>+ SET SYSTYPE GUARDIAN
>+ SELECT LIST * OFF
>
>+ ADD * from HELOO
>
>+ SELECT SEARCH $SYSTEM.SYSTEM.CWIDE
>+ SELECT RUNNABLE OBJECT ON
>+ SET HEAP 10 PAGES
>+ SET SAVEABEND ON
>+ BUILD HELOX!, SATISFY ON
>+ EXIT
>=======================================
>
>
>
>
>My pathway script I call it START (Again I copied and paste from somewhere)
>
>=======================================
>VOLUME $UJIAN.TEST
>CLEAR ALL
>PURGE OTTPKLOG
>PURGE PATHCTL
>PURGE PATHLOG
>CREATE PATHLOG
>PATHMON /NAME $XXX, NOWAIT, OUT PATHLOG, HIGHPIN ON, PRI 162, CPU 0/1
>PATHCOM /IN $UJIAN.TEST.CONFIG, CPU 0, OUT OTTPKLOG / $XXX
>
>PATHCOM $XXX; START SERVER *
>=======================================
>
>
>
>
>
>And the CONFIG file for the PATHCOM
>(And yes you guessed it correct I copied and paste from somewhere)
>I have some vague idea why I put those values up but every very minimal
>
>=======================================
>SET PATHMON BACKUPCPU 1
>SET PATHWAY MAXTCPS 10
>SET PATHWAY MAXEXTERNALTCPS 1
>SET PATHWAY MAXTERMS 10
>SET PATHWAY MAXSERVERCLASSES 10
>SET PATHWAY MAXSERVERPROCESSES 50
>SET PATHWAY MAXSTARTUPS 50
>SET PATHWAY MAXASSIGNS 500
>SET PATHWAY MAXLINKMONS 10
>SET PATHWAY MAXPARAMS 500
>SET PATHWAY MAXDEFINES 200
>SET PATHWAY SECURITY "G"
>SET PATHWAY OWNER 22,100
>START PATHWAY COLD !
>
>[Server Setting]
>
>RESET SERVER
>SET SERVER PROGRAM $UJIAN.TEST.HELOX
>SET SERVER HOMETERM $TCO1
>SET SERVER DEBUG OFF
>SET SERVER CREATEDELAY 1 SECS
>SET SERVER DELETEDELAY 2 MINS
>SET SERVER MAXLINKS 40
>SET SERVER LINKDEPTH 1
>SET SERVER MAXSERVERS 3
>SET SERVER NUMSTATIC 3
>SET SERVER PROCESS $XXX1
>SET SERVER PROCESS $XXX2
>SET SERVER PROCESS $XXX3
>SET SERVER PRI 150
>SET SERVER HIGHPIN ON
>SET SERVER TMF OFF
>SET SERVER (ASSIGN MESSAGE-LOG-PREFIX, $UJIAN.TEST.MLOG)
>SET SERVER (ASSIGN SCE-LOG-FILE, $UJIAN.TEST.PKILOG)
>SET SERVER (ASSIGN PERF-DATA-FILE, $UJIAN.TEST.PRFDAT)
>ADD SERVER XXXOBJ
>
>=======================================
>
>
>
>
>My close script to kill of the pathway
>(And yes again I copied and paste from somewhere)
>=======================================
>STOP $XXX1
>STOP $XXX2
>STOP $XXX3
>PATHCOM $XXX; STOP SERVER *
>PATHCOM $XXX; SHUTDOWN!, WAIT
>=======================================
>
>
>This is what I did to start the whole thing.
>
>1. Logon to Tandem (with putty) and enter id and password
>2. Go to $UJIAN.TEST
>3. OBEY COMPILE - get the runnable HELOX
>4. OBEY START - to setup the server and point it to HELOX (I think)
>5. RUN HELOX
>6. OBEY STOP
>
>
>
>
>
>MY OUTPUT
>========================================
>$UJIAN TEST 3> OBEY START
>VOLUME $UJIAN.TEST
>CLEAR ALL
>PURGE OTTPKLOG
>$UJIAN.TEST.OTTPKLOG File error 11
>PURGE PATHCTL
>$UJIAN.TEST.PATHCTL File error 11
>PURGE PATHLOG
>$UJIAN.TEST.PATHLOG File error 11
>CREATE PATHLOG
>PATHMON /NAME $XXX, NOWAIT, OUT PATHLOG, HIGHPIN ON, PRI 162, CPU 0/1
>PATHCOM /IN $UJIAN.TEST.CONFIG, CPU 0, OUT OTTPKLOG / $XXX
>
>PATHCOM $XXX; START SERVER *
>$Z977: SERVER XXXOBJ, STARTED
>$UJIAN TEST 4> RUN HELOX
>
>
>Hello World
>
>$UJIAN TEST 5> OBEY STOP
>STOP $XXX1
>Non-existent process $XXX1
>STOP $XXX2
>Non-existent process $XXX2
>STOP $XXX3
>Non-existent process $XXX3
>PATHCOM $XXX; STOP SERVER *
>PATHCOM $XXX; SHUTDOWN!, WAIT
>$UJIAN TEST 6>
>
>========================================
>
>
>
>I guess everything is working fine.... BUT why can't I see the $XXX1,$XXX2,$XXX3 file went the pathway server was running?
>
>Notice the Non-existent process error.
>
>Didn't my RUN HELOX activate at least ONE OF THEM?
>
>All your help will be greatly appreciated
>
>Thanks in advance.
>
>Sola Lee

[Keith Dick]

There used to be a manual titled "Introduction to Pathway", or something similar to that. It seems no longer to exist, at least I could not find it after a little searching in the online manuals library. You seem to be missing the high level picture of what Pathway is intended to do. Explaining that completely is far more than can be put into an email. I will try to explain a few of the concepts you need to understand to start to see what the parts of a Pathway application are. I must skip mentioning many things, so this will not give you the full picture, but it might get you started.

The original idea for Pathway was to provide an architecture for how an application should be designed so it would be well-matched to the NonStop system. That architecture's main points are that an application should be divided into parts that interact directly with the terminal that the application user is at, and other parts that interact directly with the database in which the application's data is stored.

The terminal handling parts of the application, called requesters, accomplish the application's functions by sending request messages to one or more of the parts that interact with the database, which are called servers. Each message that a server accepts defines some small, well-defined operation on one or more files/tables of the database. These small operations usually perform application-level operations such as creating an order, adding or deleting a line-item in an order, finding the list of orders made by a given customer number, reading the contents of an order, given the order number, and so on.

Pathway provides many capabilities for managing the collection of requesters and servers that, together, make up an application (or several applications).

Originally, requesters had to be written in the Screen COBOL language. Screen COBOL compiles to a byte code that is interpreted by the TCP part of Pathway. Pathway provided operations that Screen COBOL programs use for defining the forms that control layout of data on a terminal's screen, sending variable data to a terminal, reading user input data from a terminal, starting and stopping TMF transactions, sending request messages to a server, and receiving reply messages from a server.

Today, requesters can be written in COBOL, C, TAL, or PTAL, using the Pathsend library of procedures to send and receive messages from servers. Pathway provides no functions for interacting with terminals to be used by requesters written in these other languages. Typically, requester programs written in those other languages are not interacting with a user sitting at a terminal connected to the NonStop system, but are responding to messages that are arriving from other computer systems via a network. So such requesters need only the the Pathway functions for supporting communication with servers. (You can write a requesters in these other languages that interact with a user at a terminal, but Pathway provides nothing to help you implement the terminal interaction.)

Pathway server programs do not call any Pathway functions, but must operate in a general manner specified by Pathway, so Pathway can manage starting and stopping the server programs and routing requests from requesters to the servers and return the reply messages from the servers back to the requesters. That general manner is that a Pathway server program must begin with whatever initialization code it needed to open the files of the database this server operates on, then it must enter a message processing loop that reads the next message from its $RECEIVE file, examines the message to see what it is requesting the server to do, perform the functions the message requests, construct and send a reply message based on the results obtained by carrying out the requested functions, then loop back to read the next message. One additional requirement is that the server must keep track of the number of processes that have it open (by noticing the OPEN and CLOSE messages that Guardi
an uses to notify the server when other processes open and close it), and when it notices that the number of processes that hold an active open of the server goes from 1 to 0, the server must clean up and exit.

A Pathway application typically runs many copies of the server program in parallel, starting and stopping instances of the server based partly on the rate at which requesters are sending messages to members of that class of servers. (Starting and stopping server processes is not exactly governed by the rate of requests, but the activity is one factor.) So server programs generally must employ a well-designed record locking approach that makes sure that the server processes can access files in parallel without risking deadlock.

That is far from all you need to understand in order to write an application that is suited to use with Pathway, but I hope it gives you the beginnings of what you need to know.

In the example you showed, your "server" program was not organized the way a Pathway server must work. If you wanted to turn your example into something that could be considered a well-formed Pathway application, you would need to make your server program implement the loop that reads and responds to messages that arrive on its $RECEIVE file, and write another program that uses Pathway facilities to send requests to that server, receive the replies, and do something with the replies. You could write the requester in Screen COBOL, using the SEND verb for sending the messages to the server, or you could write the requester in one of the other languages, and use the Pathsend library to send the messages to the server.

As a more concrete example, you might write a requester program that sends a request that asks, in effect, "What should I print?", then prints the message that comes back. The server program would read request messages from its $RECEIVE, send a reply that contains "Hello World", and go back to read the next request message from $RECEIVE. The server would have to distinguish between request messages, open messages, and close messages so it would keep track of the number of openers and stop itself at the correct time. (The COBOL runtime library keeps track of the opens and returns an end of file condition to a READ of $RECEIVE at the appropriate time, but none of the other languages provides that help.) This is a pretty useless example Pathway application, but, then, so is any other Hello World program.

There are still some details of that simple requester and server program I have left out. I hope you can figure out the remaining details from reading the various Pathway manuals, or by talking with someone who already understands Pathway programming.

Good luck!

[Bill Honaker]

Keith has provided an excellent start for the origanal poster, the only thing I would add is that a requester can also be written in Java, which is very useful in creating web-facing apps, whether it is in a typical Browser application or a Web Services
app. Servers can be written in any of the languages that a requester can be written in, allowing an organization to make design decisions based on their available staff.

[Keith Dick]

I forgot all about Java. Thanks for pointing out that it is another language that can be used for server programs or for requester programs.

You have to use some packages from the jToolkit product, if I recall the name correctly, to get the Java interface to the Pathsend functions, to read requests from $RECEIVE, start and end transactions, and access Enscribe files. You use the SQL/MX or SQL/MP JDBC driver to access the database.

jToolkit and some of the JDBC drivers have a DLL that goes along with them, so you have to both add the appropriate JAR files to CLASSPATH and set up the pointer to the DLL files in whatever that environment variable is that says where to look for DLLs. Both those things are described well enough in the manual for jToolkit and the JDBC drivers.

[comforte...@gmail.com]

As usual, good comments here :-)

However I think one should mention that in today's distributed world, the requester will, in most instances, *not* run on NonStop.

IMHO, the true genius of Pathway was to predict (at the time) the split into client and server and that genius holds true today with Pathway being a transaction monitor where the client can run anywhere.

Unfortunately, the options to run Pathway clients off NonStop are somewhat limited in the "comes-with-the-platform" space but they do exist (NonStop SOAP, iTP Web server, ...). I am also sure that most commercial vendors would issue a trial version for newbies to use Pathway in a true client-server fashion.

IMHO, no-one should have to code low-level Pathway code these days; instead frameworks should be used which hide the details.

Final note: the book NonStop for Dummies had a section on Pathway which put it in context. To the original poster: contact comforte to get a printed copy, unfortunately the PDFs are no longer available for distribution.

[carlo....@gmail.com]

Hello
I have a problem that I am hoping you can help me with.
In Base24, there is an STF pathway requester/server.
The server does the usual stuff (add,delete,read/update).
I've heard of this being done before.
I want to create a batch job that will add, delete, read/update ...
Since the server already exists, I can just use pathsend in the batch job to update this file.
Does anyone have such a beast? A batch job that sends requests to a server.
This would save me a lot of writing since the server does everything that I need done, but using the Screen makes no sense.
Help would be appreciated.

[Keith Dick]

I wonder what the problem with writing the batch program yourself is. Is it that you do not know the exact format of the messages the Base24 servers expect? Or is it that you do not know how to use Pathsend?

If it is the former, I can't help you.

If it is the latter, there really is not much to learn, as long as you don't want to do anything unusual. There is just one procedure you need to use: SERVERCLASS_SEND_. You pass it the serverclass name, the Pathmon name, and the request message to send to the server, and when it returns, the reply message is in the buffer that originally held the request message. Wrap that with code to construct the request messages from whatever source you are going to get the data from, report any errors or results you want to report, and start and end TMF transactions (does Base24 even use TMF transaction? I think not), and that is the program. The Pathsend manual does describe how to call SERVERCLASS_SEND_ pretty well.

If you have specific questions about using SERVERCLASS_SEND_, I and the others here can help you with that.

If you are looking for a batch program that already does exactly the stuff you want to do with Base24, so you don't have to write a program yourself, I can't help with that, but maybe you will be lucky and someone else does have that.

[Gustavo Martinez]

What you basically need to find out is the message the STF requester is sending to the server. Then you can reproduce the same message from a batch job.
One of the problems (if you want to do it in a secure Base24 environemt - I'm imaging production) is user and password (taken from the SEC server). You will probably have to hard-coded a generic user and password (but I' guessing at this point).

I was able to reada record from the SERVER-CAF using NonStop SOAP many years ago. We need to debug the requester to understand clearly how the fields were filled by it. Then we submit the same message from a SOAP client (and the Server-CAF was able to read the record and reply the answer).

You will need to work with a Base24 programmer (or do it yourself if you know about it) to understand that format.

As Keith pointed out correctly Base24 Classic doesn´t use TMF.

Gustavo.