Running EntireX Broker
The basic started task which must be available on OS/390 is EntireX Broker.
EntireX Broker
DIT specifies a unique “DBID” for the EntireX Broker started task. Along with some other critical Broker sizing parameters.
EntireX Broker
DBID#
DIT customers will normally supply us with a Broker ATTRibute file to be added to the Broker started task. The Broker ATTR file uniquely
identifies valid Broker transactions via CLASSes, SERVERs and SERVICEs.
EntireX Broker
DBID#
CUST ATTR
The EntireX Broker started task will only provide the basic communications vehicle. The customer application is responsible for
starting Broker application servers. These Broker application servers are normally started in a Complete region. The application servers are simply
Natural programs which have issued a CALL to Broker specifying DBID#, CLASS, SERVICE and SERVER. These application servers will
normally stay in Broker RECV mode.
EntireX Broker
DBID#
CUST ATTR
Complete
APPLICATIONSERVERS
Broker applications normally communicate with the “outside world”. So the next requirement is Net-work. Net-work “talks” VTAM and TCP/IP.
ALL of the DIT Net-work regions are coded with ACCEPTUI=YES. This means that any one with valid TCP/IP stack and Net-work can
communicate with the OS/390 Net-work. There is no need to define IP addresses on Net-work. Each Net-work region will have a unique TCP/IP
port number.
EntireX Broker
DBID#
CUST ATTR
Complete
APPLICATIONSERVERS
Net-workport#
The next requirement is a TCP/IP stack. The Interlink TCP/IP stack is what we use at DIT.
EntireX Broker
DBID#
CUST ATTR
Complete
APPLICATIONSERVERS
Net-workport#
TCP/IP
Any access to the DIT TCP/IP stack must come thru either the Raptor or PIX Firewall. A Firewall authorization form must be filled out for access.
EntireX Broker
DBID#
CUST ATTR
Complete
APPLICATIONSERVERS
Net-workport#
TCP/IPFirewall
The next piece to the puzzle is a TCP/IP stack on the client side. Most platforms now come with a TCP/IP stack.
EntireX Broker
DBID#
CUST ATTR
Complete
APPLICATIONSERVERS
Net-workport#
TCP/IPFirewallClient
TCP/IPStack
The next piece to the puzzle is Net-work on the client side. The client Net-work parameters contain the TCP/IP address of the front-end of the Firewall and the
TCP/IP port# which it wants to communicate with. The client Net-work is normally auto-started when the client system is booted/started. Most client Net-works also will try to auto-reconnect after some pre-defined time period if the
TCP/IP connection has been broken for some reason.
EntireX Broker
DBID#
CUST ATTR
Complete
APPLICATIONSERVERS
Net-workport#
TCP/IPFirewallClient
TCP/IPStack
ClientNet-work
The last piece to the puzzle is the client application. The code itself can be pretty much any language. With the client Net-work, Software AG supplies a CALLable routine (usually) ADALNK which will facilitate “ADABAS Direct Calls” across
the Net-work(s).
EntireX Broker
DBID#
CUST ATTR
Complete
APPLICATIONSERVERS
Net-workport#
TCP/IPFirewallClient
TCP/IPStack
ClientNet-work
ApplicationCode
But wait, not all of the pieces are connected!! Correct. Keep in mind that the application servers are still in RECV mode. They are constantly waiting for
“input”. Something on the client will initiate a Broker CALL. Again, this Broker CALL must contain a DBID#, CLASS, SERVER and SERVICE in order to
uniquely identify the application servers it wants to “talk” to.
EntireX Broker
DBID#
CUST ATTR
Complete
APPLICATIONSERVERS
Net-workport#
TCP/IPFirewallClient
TCP/IPStack
ClientNet-work
ClientApplication
Code
Normally, the application server programs will want to read or update information from ADABAS. So I have added the an ADABAS region as the last piece to the
puzzle.
EntireX Broker
DBID#
CUST ATTR
Complete
APPLICATIONSERVERS
Net-workport#
TCP/IPFirewallClient
TCP/IPStack
ClientNet-work
ClientApplication
Code
ADABAS
EntireX V511 also provides the option for Broker applications to “talk” directly to native TCP/IP without having to go thru the Net-work middleware. But how do they do this?? The first piece is specifying a port# on the EntireX Broker started
task.
EntireX Broker
DBID#
CUST ATTR
Complete
APPLICATIONSERVERS
TCP/IPFirewallClient
TCP/IPStack
ClientApplication
Code
ADABAS
PORT#
The next piece to the puzzle is the client Broker stub. This broker stub is provided by Software AG on the EntireX CD. The broker stub is specific to each Windows
NT or UNIX environment.
EntireX Broker
DBID#
CUST ATTR
Complete
APPLICATIONSERVERS
TCP/IPFirewallClient
TCP/IPStack
ClientApplication
Code
ADABAS
PORT#
BROKERSTUB
The next piece is to add the Firewall IP address and port# to the network Domain Name Service and /etc/services file. And the puzzle is complete again...
EntireX Broker
DBID#
CUST ATTR
Complete
APPLICATIONSERVERS
TCP/IPFirewallClient
TCP/IPStack
ClientApplication
Code
ADABAS
PORT#
BROKERSTUB
DNS UPATES
So let me review a little bit. The basic application logic flow is...
ApplicationServer inBrokerRECV Mode
Something on the client side initiates a SEND to Broker followed *immediately* by a RECV.
ApplicationServer inBrokerRECV Mode
ClientCALLBroker
(now in RECVmode)
The application server READs or UPDATEs ADABAS or performs some other logic.
ApplicationServer inBrokerRECV Mode
ClientCALLBroker(in RECV
mode now)
ApplicationLogic READ/
UPDATEADABAS
The application server will issue a Broker SEND followed immediately by a Broker RECV.
ApplicationServer inBrokerRECV Mode
ClientCALLBroker(in RECV
mode now)
ApplicationLogic READ/
UPDATEADABAS
Application Server issues
a Broker SENDfollowed
by aBroker RECV
THAT’S ALL FOLKS...