This interface replaces the communications interface of the existing 1990-1996 promis/colsis interface. It's objective is to replace the logic that moved ship/pick/fgds records between a PROMIS system and Colsis. No change was done to how the interface handles the application of those records to either promis or colsis. That is beyond the mandate for this project.

In general:

When a FGDS transaction is created either in the PTC interface or in COZY (MANUAL.FOR) that record needs to go to Colsis and the action recorded. Since the action is user driven and does not need a real time connection to Colsis then a store and forward paradigm is used assist the movement of data since Colsis or the network could be down and a record might need to wait somewhere for Colsis to recover. In the past flat files were used, but this new interfaces uses the power of Oracle to maintain a data store. Thus FGDS records go first to a flat file then into the database and finally are read and forwarded to Colsis by the Smalltalk NT program. An interrupt driven model is used to defer CPU, thus a process wakes up to process records as they arrive from the user.

A Smalltalk system was originally written to move data between Colsis and SQL tables for DCI, no extensive changes were required to support the Promis interface since we use the same logic model for managing transaction as DCI uses today. Promis does not need to be active for this system to run since the Smalltalk server only indirectly talks to the Promis machine to tell it data has arrived.

When Colsis generates a ship or pick transaction this needs to flow to the Promis database. The Smalltalk program polls Colsis using a Promis database identifier. If data is found then it is read from Colsis and put into a set of Oracle Tables and a TCP/IP socket connection is made to the target Promis machine to tell that side of the interface that data is available. This action enables us to use an interrupt driven process model , versus a polling model which would consume excess VAX cpu cycles on the promis machine. When the VAX side of the interface is awoken then the data is read from the SQL database and applied to the Promis database. The altered request and an ack or failure message is written back to SQL and the record is marked processed. Please note that regardless of how promis processes the records, Colsis gets an ACK for the data once it is written to the Oracle database.

Changes to the Original Interface 97/07/02.

The old system Queue_Manager (QM) used a billzzion files and processes to do the store and forward. 7,400 lines of fortran code, along with the prom_send and prom_recv mitek interface programs which were another 5,000 lines of C code. The mitek interface was a custom 1980 3270 terminal emulator using both hardware and software. The 1990 version of the mitek software won't talk to the 1980 hardware, and the 1990 version of hardware/software won't talk to the orginal Promis LSI written interface code. In late 1980 IBM replaced such madness with the ELLAPPI 3270 programmer interface which is found in rumba or reflections and of course uses a PC for the hardware versus a special hardware box. In early 1996 the DCI interface that used the same solution was switched to the Smalltalk system that uses Rumba.

The objective of the old QM logic was to do store and forward of transactions between six odd ISAM files, the Mitek programs and multiple mailboxes and semiphores that interfaced to the CTP and PTC set of programs. Multiple QM processes read and wrote transactions between these files flipping semiphores and read/writing from/to mailboxs and invoking $wakes to yell at people to wake up and process data. I believe that records could be lost if exceptions occurred in the Mitek interface, or if mailboxes overflowed. At best this logic was difficult to follow.

The original prom_send/prom_recv programs used the Mitek box to interface to Colsis. As part of the DCI interface rewrite project a Smalltalk program was written that talks to Colsis and manages upload/download of data to ensures delivery of data between Colsis and Sybase or Oracle using Rumba's EHLLAPI interface which is a generic interface invented by IBM in the late 1980's. In Aug/96 support for Oracle was added to this server technology for DCI and QFS.

Since the Oracle Database provides logging and store/forward of transaction along with commit/rollback processing, the CTP program only needs to read/write records into Oracle, and as a bonus we can forget about the Mitek interace since the Smalltalk system used by DCI looks after the TN3270 mainframe terminal emulation. This migration of functionality from QM to the Smalltalk program greatly reduces the Promis/Colsis fortran code base, thus the ability to delete 12,000 lines of existing ugly code.

Why Smalltalk? Smalltalk is an object oriented multiprocess byte code Virtual Machine based language using JIT technology to convert byte codes to assembler as requred for optimal performance. Many of the ideas for Java came from Smalltalk, read all the pros about Java but just subsitute the word Smalltalk and you'll have a good idea of what Smalltalk can do. However Smaltalk is now 26 years old and very mature and capable of running 24 hours per day 7 days per week in a mission critical setting much faster than Java since optimization has been a 20 year project. Since the Smalltalk environment is dynamic and uses dynamic binding versus Java's static binding you can view/alter the domain as the system is running. In some cases this power was used to alter the production environment on the fly to fix a problem introduced by a Colsis program change. Since you live within a simple virtual machine you can closely tailor and understand how things work to construct a fault tolerant system. The Original DCI system comprised 37,000 words of code and did not work, it was replaced by a 4,000 word Smalltalk Program which has required little ongoing support.

Logic changes on VMS

PTC Interface:

Some of this only makes sense if you understood the original Promis/Colsis interface. However since anyone with that knowledge has left LSI.

The user now writes records to the Promis Send Queue data file versus into a mailbox. The FGDS records generated by a Promis user are still given to PTC_SEND_FGDS.FOR, but this program now makes a call to TRANS_NO.FOR The TRANS_NO program is an existing program that locks the current counter file, increments the counter, unlocks and returns a unique trans_no number. The transaction with the new trans_no is then written to the send queue ISAM file. This trans_no ensures records going into the send queue file are unique, this trans_no is passed to Colsis, later we use both the trans_no and location to find the record for ack/nack processing. Then PTC_SEND_FGDS.FOR calls PTC_CTP_WAKE.FOR to issue a $WAKE command to wake up the CTP/PTC interface process that is responsible for moving data into SQL as part of our store and forward logic. Somewhat the same logic was used In the past, but the user last handled the record when it wrote to the mailbox. Another task wokeup and did the trans_no processing and wrote it to the pending file.

In theory each PTC user could have an oracle session and write records directly into SQL, but our implementation allows us to only have one oracle session (less computer resources needed) and enables us to function if the oracle database is down, since records will queue in the ISAM file.

The CTP Program:

Historically CTP moved data both to and from Colsis, perhaps the name is somewhat incorrect. The CTP.FOR logic exists in two pieces. The CTP.FOR hiberates until woken then moves data into SQL. This was done by altering CTP.FOR to call TO_SQL.FOR. This new program TO_SQL.FOR reads the Send Queue data file looking for records. If found, the transaction is inserted into the Oracle database via a call to FGDSORACLE.C, if the database call is successful the record is deleted from the ISAM file. We loop until all records are processed or an error occurs. After this activity we hibernate. We of course awake when PTC_SEND_FGDS.FOR does the $wake. Note that the QM_SHUT_NEW program can wake us as a result of a mailbox call that trigger our clean shutdown processing.

Smalltalk

The Smalltalk Communication interface is responsible for FGDS transaction delivery to the Colsis interface using the promis location that is tied to the FGDS record. It wakes up every X seconds and looks for FGDS records bound for Colsis. Since it runs on a separate NT box CPU is not a concern. A key point is the Oracle ptc_fgds database table contains records for ALL promis locations, keyed by promis location. In anycase it finds any pending FGDS records and sends them to Colsis.

CTP Program (part two, downlink)

The CTPPOLL.FOR program listens on a TCP/IP socket (2044) using TCPPOLLLISTENER.C. The Smalltalk Communications interface will request a connection to the VAX machine using port 2044 when a set of SHIP or PICK records is received from COLSIS. When a connection is made the TCPPOLLLISTENER.C program calls CTP_EXECUTION_TRANSACTION.FOR. This program fetchs data from Oracle via a Oracle stored procedure call which is responsible for returning the first row that needs to be processed by Promis from a set of one or more rows for the targeted promis location. If no rows are found we return back to listening for an TCP/IP connection. However if a row is found we used the old existing CTP_EXECUTE_TRANSACTION logic to process the SHIP or PICK transaction. The targeted promis location information comes from the Promis header files and is embedded in the exec, so as before each Promis system has it's own unique CTP.EXE and CTPPOLL.EXE program. The Smalltalk Communications interface on the other hand handles multiple Promis locations via information found in it's Parm File. This parm file must contain information about each Promis system you want to poll along with target TCP/IP names for those systems.

Smalltalk ACK/NAK

Records from Colsis flowing to Promis need to be ACK. This logic also applies for records moving from Promis to Colsis. The ACK/NAK is NOT an end to end trip, rather it's done at the Oracle database interface point. Before Promis sees the SHIP or PICK transaction the Smalltalk Communications interface has already ACKED the transaction back to Colsis. The ACK in this case tells Colsis we have written the record into the Oracle database, it does NOT mean Promis has processed it, but it is only in the database waiting for Promis to process it. However Colsis is now happy and will not send us the record again. The only action we can take is to ACK the record, there is NO NACK logic. As part of the CTP_EXECUTE_TRANSACTION processing the record is checked for duplication and then the record is applied to Promis where it either is accepted or an error condition occurs. End result is that the record is returned to Oracle where it is logged to track activity and lot split results. Currently lot/splits feedback does NOT flow back to Colsis. Any error codes are processed and the original transaction is marked as complete or in error. Remember Colsis still will consider the record ACKED! No further communication is done to Colsis for this record.

For the Promis to Colsis FGDS record flow the records move out of the ISAM file into Oracle and are deleted from the ISAM file once the SQL database has confirmed the record was written correctly to the SQL table. Once in the Oracle database the records are marked pending, then acked only when Colsis sends us an ACK for the transaction. This logic is the same as the DCI interface.

Lock Errors:

Promis can give us a lock error (125) on a ship or pick transaction if the promis database is locked, if this happens the record is rewritten to the oracle database. After 5 minutes another attempt is made to process the record. The oracle stored procedure looks for records in 125 error status older than 5 minutes and requeues them using the queue flags. This continues until the record is acked or rejected on another type of error.

FGDSORCL.c

This 'C' program contains the oci or pl/sql interface between Oracle and C. It supports two functions, one to call a stored procedure to return a SHIP or PICK record for the supplied Promis location. The other procedure takes a function and data pointer and uploads either an FGDS or ACK/NAK PICK/SHIP transaction into the Oracle database. Of course to work we must logon to the database, this is only done once for the life of the process.

LogonIDs

In order to connect to Oracle the FGDSORCLc program embedded in CTP.FOR and CTPPOLL.FOR must supply a valid Oracle user id and password. This information is hard-coded in the the FGDSORCLc program, two Oracle connections are used, one for download, one for upload. These connection are always live. At system startup the FGDSORCLc program attempts to connect to Oracle. Once a connection is made it is stored in memory. Each time we call an FGDSORCLc subroutine the current connection is tested for validity. If the connection is dead due to a communication failure or Oracle failure an attempt to re-logon is made. In case of connection failure the CTP.FOR or CTPPOLL.FOR program will drive both the TO_SQL and CTP_EXECUTE_TRANSACTION programs to re-attempt connection which will of course fail. This failure will be logged to the log files and we'll continue relogon attempts each time we awake until the connection is restored. Other possible failures in the TCP/IP network or with Oracle itself may cause a fatal error. If this happens the CTP.FOR or CTPPOLL.FOR program terminates and the VMS operators are emailed that they need to restart the interface. No active notification is done about SQL errors since errors will result in a continuous retry of the action.

We use multiple logon ids to enable better tracking of what the system is doing. The CTP.FOR program uses a PROMISFROMVAX user id since it only uploads FGDS data to oracle. The CTPPOLL.FOR program uses both a PROMISTOVAX and PROMISFROMVAX userid since it reads ship/pick and writes the ack/nack ship/pick to SQL. Using some of the Oracle enterprise toolkit programs you can see what sessions are connected to the oracle database to determine if the interface is active.

The Smalltalk communications program uses a PROMISTOCOLSIS and PROMISFROMCOLSIS user id to read/write transactions into/from the Oracle Database. So normally 5 oracle sessions are required to support the interface: PROMISTOVAX, PROMISFROMVAX, PROMISFROMVAX, PROMISTOCOLSIS, PROMISFROMCOLSIS.

For SQL failures the Smalltalk Communication program will complain via E-MAIL about the SQL failure. Historical DCI interface testing has shown that the Sybase interface is very stable, (Oracle requires more historical evidence. Since the Oracle database will exist on the same machine we expect a very low SQL error problem since we can rule out network related issues. User problems like dropping the Colsis/Promis stored procedures by accident will of course cause problems. The resulting Oracle message will be logged on the Promis side and email generated by the Smalltalk system.

Tables:

A number of Oracle tables are used, along with a number of stored procedures, these are detailed below. The interface is very similar to the DCI/Colsis interface.

Promis/Colsis tables in Oracle are:

ptc_fgds	Table contains FGDS data bound for Colsis keyed by Promis location. The data is broken out by Colsis data field names. Additional columns are used to track successful Colsis delivery. Transaction not acked by Colsis are sent again after 2 hours. To further tie trans_no to location ALL SQL WHERE clauses use BOTH trans_no and location as a combined key. It is important to remember the production Oracle database will contain data for ALL promis location. When looking for a particular transaction one must use the location data to find the right transaction since different promis systems might have use the same trans_no
ctp_ship	Table contains SHIP data bound for Promis keyed by Promis location. Transactions are acked immediately by the Smalltalk system. . The data is broken out by Colsis data field names. Additional columns are used to track successful Promis delivery. A transaction can be in 4 states: waiting processing, processed ok, txn in error, and txn in error due to record lock. A Report can be run as required to look for transactions in error. The ctp_query stored procedure is used by Promis to get the data out of this table.
ctp_pick	See ctp_ship, this table contains PICK data, and logic is the same.
ptc_log	This table contains timestamped records of the pick/ship and fgds records returned from Promis. During pick/ship processing Promis actually alters the records to supply a error code, text and reason. It may also change lot number etc when processing information to perform lot splits, which makes debugging difficult, however this file provides an audit trail to allow you to track the end result of the Promis processing, since full acked ship/pick records from Promis are logged into this file. Records that come from Promis as FGDS transactions are first recorded here then processed and broken down into columns for the ptc_fgds table. During that processing errors can occur since the promis code can in fact create invalid FGDS records. So Records that have a status of 'P' are pending transfer to ptc_fgds. Records that have a status of 'X' are successfully transfered to ptc_fgds. Records that have a status of 'A' are archived copies of records that were returned by Promis. Records that have a status of 'E' ARE IN ERROR AND SHOULD BE CHECK since the transfer of these records from the log to fgds failed. Check table flag meaning table later in this manual for clarification The Smalltalk program also logs screen images it gets or sends to Colsis in a 100MB log file. This allows you to verify what exactly was sent or received from Colsis if a question about the data is raised since that file contains hard-copies of the IMS screen images bound to/from Colsis. SQL commands when issued are also logged. The receive SQL request show data, but the query SQL request for FGDS does not. NOTE: The CTPPOLL.FOR program also creates a CTPPOLL.LOG file on the VAX which contains usefull information about how the ship/pick transactions were processed. The CTP.FOR program creates a CTP.LOG file on the VAX which details how it manages the FGDS transactions.
lsi_dci_dcicolsis_mapping	A read only table used by the Smalltalk program to map txns to colsis relationships. Once configured no changes are required.
lsi_dci_colsisdci_mapping	A read only table used by the Smalltalk program to map colsis to txns relationships. Once configured no changes are required.

Stored Procedures

query_send_fgds	Calls ptc_fgds_insert_setup to move data from the log file into the fgds table. Remember Promis can create invalid FGDS records, thus a two step process is used to move data. The smalltalk program uses this procedure to look for PA0 records or SNULL1 records that are 2 hours old. PA0 means pending, not sent. SNULL1 means send once, pending ack/nack. If any records are found this program returns a result set that is used to build the Colsis FGDS transactions bound for Colsis. Once read by the smalltalk program the records are changed to SNULL1, and of course the smalltalk program sends the FGDS txn to Colsis. Colsis should send an ACK/NACK which is processed by the recv_ack_fgak or recv_ack_fgnk procedures. This procedure is called every 4 seconds or so. Colsis can reject the transaction at read time due to data field errors, or bad transno values. This will generate an exception email message from the smalltalk program to flag a serious failure!
recv_ack_fgak	Used by the smalltalk program to receive FGDS ack transactions. A match is done to the trans_no and promis location and the record goes into XA0 state All XA0 records are fully processed, eXecuted and Acked by Colsis
recv_ack_fgnk	Used by the smalltalk program to receive FGDS NAK transactions. A match is done to the trans_no and location and the record goes into EA0 state, and the error reported by Colsis is recorded. All EA0 records should be considered BAD and investigated, this means Colsis rejected the record. Note Colsis can reject records on the initial handover. If this happens the smalltalk program will E-Mail someone since Colsis is rejecting the record on a data edit check which should not happen at this point in the lifespan of the transaction.
recv_ack_ship	Used to receive SHIP records, if the record is not a duplicate is dropped into the ctp_ship table and acked. If a duplicate we just re-ack it. The record goes in in CA0 (Colsis Acked, waiting Promis ack/nak) status for processing by ctp_query. Colsis generates unique transactions number for us.
recv_ack_pick	Same function as the recv_ack_ship stored procedure, just handles PICK transactions
ptc_fgds_insert	Used to receive FGDS records from promis, called via CTP.FOR. These records are inserted into the ptc_log table. Minimal processing takes place to reduce error handling logic in the Promis fortran code.
ptc_fgds_insert_setup	Used by query_send_fgds. This program looks for log records in 'P' status. If found it changes them to 'E' status and calls ptc_fds_insert2 to insert the record into ptc_fgds. If an error occurs control returns, the query_send_fgds will return an error to the Smalltalk program which will report the problem. If no error happens then the record's status is changed to 'X' from 'E'.
ptc_fgds_insert2	Attempts to move records into the ptc_fgds table., if duplicate an error record is generated. If not duplicated the string is broken into parts and inserted into ptc_fgds for further processing as a PA0 record by query_send_fgds. This process could fail due to bad data, in this case the record remains in 'E' status in the ptc_log table. Daily operations should pick up the fact and investigate.
ctp_query	Used by Promis to query for SHIP/PICK transactions. This program first looks for locked records older than five minutes then it looks for records in CA0 status. These records are then sorted by date/time. The first row (oldest) found is returned to the CTPPOLL.FOR, which then processes the record using the old Promis logic, and return the results using ptc_aknk_insert
ptc_daily_query_delete	Run manually to look for records in error, records that have waited too long on the queue. Also deletes records older than 30 days that are correctly processed.
ptc_aknk_insert	Used by Promis to insert ack/naks from SHIP/PICK transactions. First we log the data into ptc_log. Then we change the status of the original ship/pick from CA0 to AN0 (Processed by Promis, but NAKed) or AA0 (Processed by Promis and Acked) depending on the error status. AN0 records could be problem records since promis processed them but rejected them with some type of error feedback.

Things to think about.

The CTP_EXECUTE_TRANSACTION.FOR program first calls ctp_query which might grab 20 records but will only return the oldest one. Unlike some systems were we process a result set of records we only deal with one record at a time. The fortran program then processes the transaction against Promis and then returns an ACK/NAK back to the database via ptc_aknk_insert. Then we repeat the loop to process any more waiting records. If none are found we return to the CTPPOLLLISTENER.C program which invokes a TCP/IP listen request on port 2044 which causes us to go into hibernation. If you want to manually trigger a wakeup you can use telnet and connect to the target machines port 2044.

The CTP.FOR program is normally in hiberation, but is woken when PTC.FOR or MANUAL.FOR (COZY) creates an FGDS record. When it awakes it processes all pending records in the FGDS ISAM pending record data file.

On the VAX you can use the CHECK command in the CP_EXEC: directory to view the current status of the System.

Operations:

Read any messages you get from the Smalltalk communications program.. Any Oracle errors should be followed up on. You may get errors if the data from Promis is bad.

Check the ptc_log table for status codes of 'E' these are problem transactions.

Check the ctp_ship and ctp_pick tables for EA0 records (status code of 'E') these are problem transactions.

Check the ptc_fgds tables for SNULL1 records that are old. Records in resend status that are very old are in error.

Check the VAX CTP.LOG file and the CTPPOLL.LOG file for error messages. The original PTC/CTP code will of course generate error files etc if abnormal events happen. Refer to the orginal Promis/Colsis pre-1996 documentation for meanings.

Tables Flag Meanings:

PTC_LOG

Status	Issue
P	FGDS Pending processing by the Smalltalk system,
A	Results of ship/pick record processing from Promis. Keeps track of the changes to the original pick/ship that Promis made since the CTPPOLL.FOR program may alter the original pick/ship record to handle lot splits. You can use data from this table, the ctp_ship/pick and VMSDATE field and the CTPPOLL.LOG file to cross-reference and figure out what the interface really did when it applied a ship/pick.
X	FGDS Processed by the Smalltalk system and converted into a row in the FGDS table without a fatal data coversion error.
E	Either: FGDS Processed by the Smalltalk system but found in error due to data conversion issues or Error condition, see error message and oracle stored procedure logic

PTC_FGDS

lsi_dci_status	lsi_dci_acknack	Issue
P	A	Pending processing by the Smalltalk system to be sent to Colsis
S	_	Record sent to Colsis, waiting for Colsis Ack/Nack
X	A	Processed ok by Colsis
E	A	Colsis rejected the fgds transaction, this is an error condition.

CTP_SHIP and CTP_PICK

lsi_dci_status	lsi_dci_acknack	Issue
C	A	Pending processing by Promis
A	A	Processed ok by Promis
A	N	Promis rejected the ship/pick transaction, this is an error condition. Note error 125 records should be reprocessed by the interface since these represent a locked condition, not a fatal error.

Risk Matrix:

Thoughts About problems within the interface, different failure senarios and recovery actions.

Location/action	Risk	Recovery
PTC_SEND_FGDS, in PTC stuff. Open ISAM file, write record to file.   Very basic fortran I/O happens here. Problems are logged but you could loose data if a serious I/O error occurs since the txn is in flight and not stored anywhere else. Also TRANS_NO call locks increments transid and unlocks.	L	File missing, no disk space? Expected errors are unknown. Errors are logged to the log file. There is a com script that recreates the ISAM queue file, but you must ensure the file is empty before destroying it, since it contains the only copy of an FGDS transaction. Destruction of the transid file will cause problems since this number is incremented and Colsis remembers the old values. If a value given to colsis is in the past Colsis will reject the transaction.
CTP.FOR and CTPPOLL.FOR PTC_READ then EXECUTE_TRANSACTION PTC_READ, open PTC file, read record, passes it to WRITE_TO_SQL (ptc_fgds_insert). If failure, log and close file. If OK, delete record and look for another, if not found then close file. Once SQL says OK, then delete the record. If failure on Oracle (see wait and retry).	L->M	Connection failure, Oracle failure. On error log it. We don't delete the record until we've gotten the Stored Procedure to return a 0 return code which means Oracle drop the record into the database. Errors are logged to the log file. Oracle interaction is minimal. Errors here are fatal. Oracle errors may cause CTP or CTPPOLL to fail. The CTP com script mails people about the failure and currently looks for an operator to restart the promis interface.
QUERY_SEND_FGDS This stored proc sends data to Colsis. If no ack after 1 hour it resends	L->M	Resend logic from DCI. Send if P/A/0 or /S/NULL/1 and 2 hours old The Smalltalk program attempts to send any records not sent for forever. However from time to time one should check for records in S/NULL status to see if any logic errors are present.
RECV_ACK_FGAK Store Colsis response.	L	Unlike DCI Colsis does not resend transaction at the end of the day it does a resend every hour. On duplicate receive we ack the transaction and ignore the request. Oracle errors are emailed to support person.
RECV_ACK_FGNK Store Colsis nak	L	Oracle errors are emailed to support person.
RECV_ACK_SHIP Store Colsis data.	L	Oracle errors are emailed to support person.
RECV_ACK_PICK Store Colsis data.	L	Oracle errors are emailed to support person.
Execute Transaction(CTPPOLL) Calls READ_FROM_SQL (ctp_query) Will return data if found, one record per call. Calls WRITE_TO_SQL(ptc_aknk_insert) Callback to do ack, nak of record. Might have ack/nak of 044 which is already sent? Might have nak of 125 which is Promis record locked. If so after 5 minutes we will clear the error and resend the record via logic in the ctp_query storec procedure	L->M	Connection failure, Oracle, failure, On error, log and wait a few minutes. It is possible that we might get the record again later since we will have not ack/nak it. However does code in Promis flag that? And return with a 044. Always log the record, if error then complain and log.
FGDS_INSERT2 Insert the record.	L	If duplicate, then log the error and continue as if no error.
ptc_daily_query_delete

Remotely Managing Server

From time to time you must clean up lost Rumba sessions. To do this you must reboot the server, or shutdown the app and kill all rumba sessions. Following is how this is done remotely: Remember unless you can see the screen you can't identify what transactions are queued in memory so be careful. Colsis will resend any txn after an hour, from Promis they will be resent after 2 hours. However killing things

as outlined below may result in nasty error message from the Interface. So be prepared to receive message saying abnormal events occured..

Security must be setup correctly for person to control server, they must use an NT client machine and have NT administration rights on the ????? (Name to be decided later) server

All these utilities come from the MS resource kit for NT and are supported MicroSoft features.

Please refer to the MS resource kit for proper documentation.

Also a new SMNP feature is coming to allow you access to the desktop remotely, talk to the NT support group about this feature later in 96.

1) SRVMGR.EXE (A windows program)

Allows you to control sharing of volumes, directories, properties, and services

To stop the Promis/Colsis server run this application and stop the Promis/Colsis service.

Then invoke rcmd \\????? to get a remote command line (Step 2).

After killing all rumba sessions then restart the Promis/Colsis service which will restart needed Rumba sessions.

2) RCMD.EXE (A dos command)

Allows you access to a command line prompt on the remote machine

Invoke rcmd \\???? to get a command line prompt on ????

Invoke tlist /t to see list of running processes.

If VWPROMIS.EXE is running see SRVMGR.EXE to shutdown the Promis/Colsis service

If RUMBADSP.EXE(s) are running use kill RUMBADSP to kill all the Rumba sessions

If WDTELNET.EXE(s) are running use kill WDTELNET to kill all the Rumba telnet sessions\

if DRWTSN32.EXE(s) are running use kill DRWTSN32 to kill all the Dr Watson dumper tasks.

After killing all RUMBADSP and WDTELNET sessions you can restart the Promis/Colsis service

Remember to exit the remote session

Other option

SHUTGUI.EXE (A windows program0

Allows you to shutdown and restart the NT server, not normally used.

(A stop server, and killing of all rumba and telnet and drwtsn32 applications should clean up the environment. )

Pick kill applications without saving data

Reboot after shutdown

Delay ? (any number is fine)

This should kill and reboot the Server

Windows NT Performance Monitor

Use ????.pmc file to feed performance monitor application. This parm file can be setup via the performance analyser and then just do a double-click to launch an saved parm file.

This parm file allows to you view the smalltalk image (the server) and rumba CPU usage. These charts allow you to understand how the server is working.

Idle Application:

Or

Red line (highest) is overall CPU.

Green line (middle) is Smalltalk VW process (the application) spikes to process Rumba screeen.

Blue line (lower) is Rumba LPPLOGON activity every 4 seconds

pink line (not visible ) is Rumba LPCPROMIS activity (data to promis) Not really any activity here.

Key viewpoint is sawtooth pattern for the highest line. This means the application is polling

IMS/Colsis sucessfully. The VW CPU hovers at 30% if Oracle polling is at .5 seconds. If we change the polling to 2 seconds we get the second chart. However please review the loss of Oracle polling to

understand how that is different from above. A slower polling means less green CPU as the above charts show.

Loss of Rumba session:

The flat line is a result of the loss of the rumba session. The spikes in the middle show when the application recovered the Rumba session. The blue line spikes upwards as it -reconnects to the mainframe. Loss of Oracle will also defer processing, but in this case the 10% or so of activity means the Oracle connection is active.

(No Oracle) But polling still active

Lines drop to zero is indication that Oracle is down? Polling might stop once application notices the Oracle failure. In this case we shutdown the DB, so it might need to timeout the current SQL commands first but

as you can see the CPU curves are different. You may also see this if the Oracle query task is taking TOO long to respond. The tooth patterns are very clean, as compared to the 2 second Oracle polling cycle you saw before.

Busy Application:

Red Cpu link peaks more often, blured blue line which is IMS query (LPPLOGON) overlayed with purple line which is IMS store task (LPPROMIS). You can actually tell transaction activity. Each blue spike is a screen interact, each purple spike is the response going back to IMS.

Memory Usage:

Again with the performance tool to you can monitor Memory. The normal working set size should hover around 16MB. Numbers much higher are cause for concern, this points to a slow down in the interfaces or

an excessive transaction rate that the interface can't keep up with. Remember the driving trottle on the interface is the IMS response time. Typically we suffer a .8 second delay for each IMS screen action. This adds up. You can only process about 300 txns per hour,via this interface when using TCP/IP.

Thus queueing of data is NOT an issue we cannot overrun memory given the feeds from Colsis. In testing over 10,000 record were queued for DCI, in practice queues have reaced 1,600 in dire situations with no problems faced by the apllicaiton.

Smalltalk Communications System changes from Dci Installation

The Smalltalk system is a clone of the DCI interface and contains the following functional changes.

Ctp_ship PromisDataMgr PromisShip Ctp_pick PromisDataModel Ptc_log Ptc_fgds Promisfgds Promislog PromisPick	Classes to handle the Promis tables and windows to allow editing of the tables.
LppLogon	Class to handle LppLogon IMS transactions. Transaction name is different LppLogon versus LpcLogon. Also we alter how the transaction is presented since header information is used to indicate which Promis system to query. The sites and hosts are stored in a Class variable(s) which is modified via commands in the Parm file.
LpPromis	Class to handle LpPromis IMS transaction. Transaction name is different than for subclass of LpConfig. Error message that are returned from Colsis are different.
LpcLogon	Changed parseData: to return $$ keyword. This keyword contains the Promis location information. The DCI ignores the $$ keyword since it contains no data.
ColsisToDciTask	Initialize class Promis uses TRANSNO as keyfield versus DRTRANSNO Changed raiseError to check for specific Promis stored procedure names versus DCI names. Changed processScreen: to allow for nil data Changed processResults to use LpPromis object
LpConfigTask	changed profileName, shortName to use different EHLLAPI names to avoid conflict with DCI. Changed checkLpConfig to use LpPromis object versus LpcConfig. Changed getScreen to use LpPromis object
DciToColsisTask	Changed processResults:by: to use LpPromis object
LpcLogonTask	changed profileName, shortName to use different EHLLAPI names to avoid conflict with DCI. Changed LpcLogon to use LppLogon object Changed getScreen to use LppLogon object Changed doLpcLogon to use LppLogon object MAJOR FUNCTION CHANGE in processAction. We pause if the toColsisQueue is > 0. This allows upbound Colsis txns or acks to complete first which reduces the amount of resending that Colsis does. To change this Colsis should wait an hour? Before resending. Right now it sends any unacked/nacked txns which is different that DCI. The DCI interface sends once then waits til midnight for resends.
Sybase… Sybase46Interface Sybase42Ninterface SybaseConnection SybaseTableColumn ExternalDatabaseSession SybaseContext SybaseConnection SybaseSession	A bunch of changes to support Sybase release 10, and the setdbtimeout dblib logic. Sybase 10 was used to generate sequence number for unique key information. Rel 10 features are not directly used by the Smalltalk Program. Originally the Promis system was going to use Sybase but this was changed to oracle.
Oracle…. DciToOracleTask oracleToDciTask SybaseTask	Added tasks to handle Oracle differences rework SybaseTask to abstract SQL execution so we could add Oracle support

Adding a new transaction?

Coordinate with Colsis support for the creation of a new transaction for LPPROMIS and LPPCONFIG.

Create new table for each new transaction.

Add mapping information to the lsi_dci_colsisdci_mapping and lsi_dci_dcicolsis_mapping tables

Alter PARM.TXT to add the new transaction to the queue route mapping tables.

Restart the Smalltalk Server application to reload the mapping tables.

Create a new stored procedure to accept the LPPROMIS data, a recv_ack_???? Procedure. This procedure is responsible for receiving and ack/naking the data from Colsis. Function is to drop the data bound from Colsis to Promis into a table for storage.

Check query_send_fgds to ensure it only processes fgds txns

Check ptc_fgds_insert_setup to only process fgds txns

Create a new stored procedure query_send_xxxx to handle any new txns from Promis. Function is Promis to Colsis

Create new ptc_xxxx_insert_setup to handle movement of correct records out of the ptc_log file. Into correct transaction table.Function is Promis to Colsis

Alter ptc_aknk_insert to deal with ack/nack of new txns versus ship/pick, function is Promis to Colsis for ack/nack feedback. Ptc_aknk_insert will need to split out to correct table.

Alter ctp_query to query from more than ship and pick. Function is Colsis to Promis

Add new ptc_xxx_insert to handle new transaction, Function is Promis to Colsis

Alter CTP.FOR and PTC.FOR to build new txns and call the correct stored procedure.

Alter ptc_daily_query_delete to verify new tables, and delete any old archived data.