DciServer, replication of data between Colsis and IMS. 97/07/02 Version
Smalltalk system by John M McIntosh, Corporate Smalltalk Consulting 1-800-477-2659.
Sybase software by Marianne Paulson, Lsi Logic.
(Sept 16th 1996, added new architecture support)
(July 4-th- 97, revised for promis addition)
Dci Replication Task management overview:
First you should note the code base for Dci (afs/pds, nproj) is the same as for Promis.
Process overview:
Five to seven Smalltalk processes manage the movement of data between Colsis and Dci, NPROJ. Although you can run all dci, nproj, and promis logic on a single server you will find they are split betweeen two physical boxes for fail-safe reasons.
1 - LogTask to manage logging status data to a file, and to email error data to the support person
1 - LpcLogonTask to manage the LpcLogon transaction which fetches data from Colsis, via LpcLogon
1 - LpConfigTask to manage the LpConfig transaction which moves data to Colsis, vis LpConfig
1 - DciToColsisTask to manage the AFS/PDS/DCI query_send stored procedures which fetch data from DCI.
1 - DciToColsisTask to manage the NPROJ query_send stored procedures which fetch data from NPROJ.
1 - ColsisToDciTask to manage the AFS/PDS/DCI recv_ack stored procedures which moves data into DCI.
1 - ColsisToDciTask to manage the NPROJ recv_ack stored procedure which moves data into NPROJ.
On the Promis machine we start different processes and you should have:
1 - LogTask to manage logging status data to a file, and to email error data to the support person
1 - LppLogonTask to manage the LppLogon transaction which fetches data from ColsisPromis, via LppLogon
1 - LpcPromisTask to manage the LpcPromis transaction which moves data to ColsisPromis
1 - DciToOracleTask to manage the QFS query_send stored procedures which fetch data from QFS.
1 - OracleToDciTask to manage the QFS recv_ack stored procedure which moves data into QFS.
The ColsisToDciTask , LpConfigTask, , ColsisToOracleTask, LpPromis, and LogTask are dependent on the other tasks to feed data to the queues they read. The DciToColsisTask or OracleToColsisTask runs each SQL query with a .1 second delay., then waits about 12 seconds. The LpcLogonTask or LppLogonTask is invoked every 4 seconds, this is controlled by the DciGlobal queryForDelay parm which is changable via PARM.TXT. The LogTask is only involved in the logging of data as queued by the other tasks, you cannot start or stop the log task. The log task processes error messages by using SMTP (TCP/IP Simple Mail Transfer Protocol) to E-Mail a message to support person(s) which are identified in the email parm in PARM.txt. LppLogonTask also uses TCPIP to ping the target Promis machine to tell it data is available when dicated.
If you invoke the terminate all tasks command all tasks are terminated and a new LogTask is automatically created.
You can start tasks one at a time by choosing the process you want to start, then hit the start button, but the best way to bring up the system is to invoke the restart system menu item. This action terminates all the tasks, restarts the log task, then restarts all other tasks the system knows about. Typically three to five minutes are needed to get all tasks running. If errors happen during the startup processing they will be logged to the support person. Expected problems during startup are problems with mainframe communications, or Sybase or Oracle access. Due to abrupt task termination you might get error message when you issue a stop task, or reset system. Sybase connection failures will freeze the system for at least 90 seconds before turning control to the client. Lost of ability to control the system from the control window is very very rare.
Screens & Starting the Application
Each LpConfig / LpcLogon or LpPromis/LppLogontask pair manages a Rumba IMS screen via a EHLLAPI interface. (IBM's Extended High Level Link Access Protocol Interface.) The Rumba session looks, feels, and operates just like a regular session In fact it is a regular session, you can watch the screens go by if you expand the Rumba screens. The EHLLAPI API layer allows the DCI program to talk to the Rumba screen and mimic a person reading the screen and typing on the keyboard.
| Rumba DSP file | EHLLAPI | Smalltalk Class | |
| IMS.DSP | 'A' | LpcLogonTask | afs,nproj,qfs |
| IMS2.DSP | 'B' | LpConfigTask | afs,nproj,qfs |
| PROMISL.DSP | 'C' | LppLogonTask | promis |
| PROMISC.DSP | 'D' | LpPromisTask | promis |
When the Rumba sessions are started the screens are minimized, they do not need to be visible for DCI to run.
Usually when the server is re-booted the application will restart automatically, or if not started you can either start it via the NT services icon in the control panel (dciserver) is the service. Or locate the Dci Server Windows NT program group:
Double Click on the Dci Server Application icon. This will start the application. (Note you should start this thing as a service to avoid problems if you were to logoff the NT session. So go to the NT service control panel and start the service from there. (The Promis interface will look/behave the same, only the service name might be different).
When the application is running the following window is displayed for information purposes. All processes in the top list window should read 'Active'. You can of course close this window since it is not need by server to run, but closing the window makes it difficult to monitor server's state of mind. So don't close it eh?
fromColsis Active The LpcLogon processing runs all the time. (Gets data from Colsis)
fromDci Active The query_send processing for AFS/PDS. (Gets data from AFS)
fromNproj Active The query_send processing for Nproj. (Gets data from NPROJ)
fromPromis Active The query_send processing for Promis (Gets data from Promis)
log Active The log task runs all the time.
toColsis Active The LpPromis processing runs all the time (Sends data to Colsis)
toDci Active The recv_ack processing for AFS/PDS (Sends data to AFS)
toNproj Active The recv_ack processing for NPROJ (Sends data to NPROJ)
toPromis Active The recv_ack processing for promis (Sends data to AFS)
In theory you might have multiple to/from promis tasks to support multiple Promis machines. During start stop processing the tasks will read Startup/Shutdown. During normal processing all processes should be Active.
Note that the Sybase Recv task takes a LONG time to come active since it verifies all the column types of all the stored procedures we are using so it will stay in Startup/Shutdown status for a long time (minutes, but NOT hours)
The toDci or the toNproj queue number typically is 0, a large number here say greater than 100 should be thought about. The toColsis queue number can be less than 100, a large number here say greater than 500 should be reported to support.
(DON"T DO THIS, it's here from a development viewpoint, never do this on the production system)
The Pause check box allows you to halt processing in LpcLogon and LpConfig screen processing. This step button is then used to step the screens. This is useful if you want to halt the system to examine the log. To resume processing you must uncheck the Pause box and hit the step button at least 6 times.
The Copy log button copies the existing log file to "copy.log" in the ../VISUAL/IMAGE directory. This allows you to examine a snapshot of the log without worrying about concurrent locks on the production log file. If you do this beware of how much disk space you have available to create copies of the log file. Usually you don't need to use this in practice we've found you can FTP the log file from the server, or use windows file services to copy the file without impacting the server.
Process:
Terminate ALL processes Will stop all processes, terminate all Rumba sessions and halt Server. Queued txns are kept.
Any Processes Running? Check to see if any processes are running. (Diagnostics).
Restart System Does a Terminate ALL processes, then restarts the system
Exit System Abrupt termination, DON'T USE THIS, only use after Terminate ALL Processes.
Maximizing the Rumba windows will also show the data without slowing down processing.
Smalltalk Internals & Startup Processing:
If you are a Smalltalk programmer, welcome. Here be gory details of the internals, no exciting code beyond handleDo constructs where used, it's very vanilla. Historical evidence has shown that day to day operations doesn't need to refer to this section, but you must be here to make changes? In general the thought was to create the system independent of the data, you don't need to make code changes to add new transactions. From 1996 though to 1997 only 2 changes were made to the base code to the error retry logic to better handle unusual cases.
There is one instance of DciGlobal in the system, accessible via DciGlobal (class) >>Global. This instance of DciGlobal contains pointers to the other processes and queues. It acts as a traffic cop to manage the processes. When the image is started the DciGlobal instance, which is a dependency of ObjectMemory, gets an event in DciGlobal>>update:with:from:. The event is #returnFromSnapshot, and the sender is ObjectMemory. When this happens we invoke DciGlobal>>restart, which is the command also invoked by the Restart System menu item.
The restart method then invokes DciGlobal>>terminate to terminate all processes. Terminate will terminate each running DciProcess vis DciGlobal>>stopProcess and then restart only the LogTask, via DciGlobal>>startLogProcess. Restart then reads "parm.txt", the parm file, to set tuning, site specific, and configuration data, then it starts the processes that have been identified in the parm.txt file. Error recovery is non-existence bad parm files will cause a notifier window.
The Sybase tasks attempt to connect to the Sybase region. If a failure occurs this activity will repeat.
The Oracle tasks attempt to connect to the Oracle regions. If a failure occurs this activity will repeat.
The IMS tasks attempt to start separate Rumba sessions and connect to Colsis. If a failure occurs this activity will repeat.
When starting the Smalltalk processes we use an error handleDo construct in DciGlobal>>startProcess: to manage connect, session, and fatal errors. Typically session or connect errors are raised due to the stability of the IMS and Oracle or Sybase sessions. However programming bugs might raise a general error which will then disconnect the session, and attempt a restart. Other errors may be logged if changes to the production DCI tables or stored procedures are made and lead to logic errors, or loss of security grants.
The processes will run forever until they are terminated via an operator request from the Control Window. (Note the NT Server control panel can also quit the application as a service however you must then stop any Rumba systems since this type of termination is not clean).
LpcLogonTask (IMS LpcLogon processing)
For each iteration of the loop in LpcLogonTask>>processAction we invoke a reset, clear screen, then the IMS LpcLogon transaction and retrieve the screen from IMS. The screen should contain a message at offset 1859, either "END-OF-MAIL", or "UPDATE-TRANS". If we see data at 1859+13 bytes we assume we have a valid screen and build a LpcLogon object, if we don't we see data we wait upwards of 25 seconds for Colsis to respond.
The newly built LpcLogon object is tested to see if the response message from Colsis is OK, or if we got the RECORD NOT FOUND ON DATABASE message. If we don't see the correct message(s) we abort the session, drop the connection and restart LpcLogonTask. But if we have a valid LpcLogon object we decide which queue to use for this screen based on the function name. Other DciToSybaseTasks or DciToOracleTasks then read those queues
To handle multiple Colsis transactions we do a reset, clear, and PA1 to get the next screen, verify it's OK and create and queue a LpcLogon object. This loop continues until Colsis returns the end of mail message.
Memory: LpcLogon object rarely queue, the ColsisToDci task seems to process them faster than we can fetch them from Colsis. Queued objects are an indication of a Sybase slowdown or problems with the ColsisToDciTask. Given 64MB of memory and 200MB+ of swap space you won't run out of memory, Weeks of queued data would be required to cause a memory shortage problem.
Promis: Promis uses LppLogon and LppLogonTask, very little is changed between the logic since the IMS transactions are the same as the DCI transactions. However the only major logic change is a TCP/IP connection request made after we receive a set of data from Colis, it's receive data, wait, then ping Promis target via TCP/IP to wake it up for it to process the data
we dumped into Oracle.
This object takes a Colsis screen image, and creates a Dictionary of Colsis Field names and data items. A Colsis screen contains Field names at column 2 for 16 bytes, and data at column 19 for 60 bytes. These items are stripped from the screen by LpcLogon>>parseData:and placed in a dictionary which is the real object returned.
LppLogon Object
This subclass of LpcLogon modifies the logic to insert a target Promis database name each time it is invoked, Thus each request causes a different poll for a different database to be made. Of course if only ONE database is involved then the logic is redudent.
This task waits on a shared queue for a LpcLogon object. Multiple processes may be running to feed different Sybase backends. Each ColsisToDciTask will wait on a different queue which service different backends.
During system startup this object reads data from the lsi_dci_colsisdci_mapping table which contains mapping data for Colsis field name to stored procedure parm offsets for each Colsis function we process. For Sybase once we collect all the stored-procedure names we invoke "exec sp_sproc_columns,stored-proc,dbo" against each procedure to get information about data types which we store in another mapping table via the StringConversion class. If an error occurs during this processing we may raise a #missingStoredProcedure error.
When an LpcLogon object arrives is asked for it's Colsis transaction/function name. If this data is not found we raise a Bad Transaction error. For each Colsis field name we use a mapping object to map the field name to a data type and the stored-procedure parm number, if we can not find a proper mapping object we fail and log an error.
A Sybase execute statement is created using the column names supplied by the mapping object. If the mapping object fails to find a field name match we fail with a #missingData error. Mapping ensures data elements are quoted if required to avoid Sybase conversion errors and it also resolves single quotes in the data to double quotes. Finally we execute the stored procedure and usually expect a row to be returned.
The mapping object only handles certain Sybase storage types which are explained in the Sybase manuals. see StringConversion>>classIs:
type = 1 ifTrue: [^#asString].
type = 4 ifTrue: [^#asNumber].
type = 5 ifTrue: [^#asNumber].
type = 12 ifTrue: [^#asString].
^#asString
So Sybase types 4, 5 are marked as number objects, 1 and 12 as string objects, other types default to strings. Currently all the stored procedures only use strings or numbers. If other types are needed then you might need to alter this method plus
StringConversion>>proc:offset:with: which uses the data to build the SQL statement.
Rows are not returned by recv_ack_ak**** recv_ack_rj**** and recv_ack_rpprebok stored procedures. All other stored procedures must return the Colsis function name, Colsis number, and Dci number. If this does not happen then a No Answer Error message is raised. If we do not get an answer set then Colsis will not get an ACK and Colsis will resend the data at midnight.
Note an EMPTY answer set (select return 0 rows) is considered valid from Dci Servers viewpoint, but it's not from a logic viewpoint. Ensure each stored procedure returns a row if required.
The result set is processed by ColsisToDciTask>>processResults which queues the data on the targeted Colsis inbound queue.
Promis and/or Oracle: Promis uses the LppLogon/LpPromis classes which only adds support to handle the $$ tag differently. Promis does use the Oracle classes OracleToDciTask and DciToOracleTask to deal with Oracle specific SQL issues. It also uses a simplified StringOracleConversion class which returns quoted strings or quoted numbers after correcting for embedded quotes. Oracle does implicit conversion between strings and numbers so we do need to worry about conversion issues, so we treat all data as Strings.
Oracle Recv_ack_**** processing is different, we append output parms onto the end of the parm list and use those parms to return data required to build the Ack or Nack LpPromis or LpcConfig transaction. The Recv_ack/nack stored procedures must assign valid values before returning.
DciToColsisTask (Sybase Query Task)
At system startup much like the ColsisToDci task we read from the table lsi_dci_dcicolsis_mapping to create a mapping object to assist in mapping columns of data to the proper Colsis field names. Colsis field names are also placement dependent on the LpConfig transaction, for example PROD_GR# on an UPDAT602 transaction MUST be the fourth field name/data pair for the transaction to work correctly.
The LpConfig IMS session must be running for DciToColsis to work, if IMS is down we pause to avoid flooding the queue with resends. For each iteration of the loop in DciToColsis>>processAction we invoke the set of stored-procedures with a .1second delay then wait 12 seconds. Sequencing of transactions should be done in the stored procedure logic, do not depend on the order of DciServer query processing to sequence transactions.
If a stored-procedure returns a row, this fact is noted by logging the name of the stored procedure. The result set is processed in DciToColsisTask>>processResuts:forProcedure:by: Based on the Mapping object we extract data from the row and create an Array of labels and data items which we place on the Colsis LpConfig queue. This process loops for each row in the result set until we have processed all the rows. Testing shows that we can process and queue a few hundred rows in a few seconds.
Memory: Since we read all the pending rows into memory this could be an issue. Typically we only read a few dozen rows at a time. Testing took that to a few hundred. Possible 1000 row reads might occur in production, however memory is the only limit and the size of each row is small. Given 200MB of swap space there should not be a problem.
Promis and/or Oracle: Promis uses the LppLogon/LpPromis classes which only adds support to handle the $$ tag . However getting data from Oracle is different. The query_send_xxxx procedures return both a magic number and a SQL statement. We then use the magic number as a bind variable and invoke the supplied SQL to do the actual Query to get the data from Oracle. (Oracle does not return result sets from stored procedure executions unlike Sybase, therefore we do this magic number and SQL statement dance to achieve the same results).
This task waits on the Colsis inbound queue for array objects of labels and data. Queues have names and are identified in the PARM.TXT file.
When an object arrives we create an LpConfig object. Then we reset, and clear the screen and present the LpConfig screen image. Once Colsis responds we invoke LpConfig>>checkLpConfig to confirm that Colsis has data in 1859+13 bytes and that the message is the expected SCREEN-RECEIVED message, we look at the "E". Also as of 7/2/97 we look for RECORD NOT FOUND ON DATABASE which is a special error case and can occur frequently under abnormal conditions.
Colsis can respond with another error message indicating that we have presented data incorrectly. This is viewed as a Unexpected Error and we log an Error. If a valid Colsis message is NOT found we will invoke a Transaction Error and terminate the session and restart
When an LpConfig object is created it is supplied with a set of Labels and Data Items. Starting with the first pair we place the label at byte offset 10, and the data at 26. For the next pair we place the label at the 16+60 bytes from the first, and the data at 16+60+16. Unlike LpcLogon we do not store data on column boundaries, rather it's a continuous stream 16+60 bytes. This screen image then is trimmed from 1920 bytes to it's real length based on data provided and sent to Colsis.
Promis and/or Oracle: Promis uses the LpPromisTask and LpPromis classes. These classes deal with the $$ tag differently. Promis wants to see the promis name in the $$ tag.
Throughput
On average a transaction takes 12 seconds to be fully processed via the LpcLogon ->Sybase->LpConfig route. The bottle neck is the Rumba processing. It requires a reset, clear, LpcLogon, (Sybase processing), reset, clear, LpConfig cycle. 1.5 to 1.9 seconds are needed for each Rumba interaction, since there are 6 interactions, that means 9-12 seconds is spent in 3278 screen I/O.
It is un-clear if the transaction rate will be an issue. The Colsis team has said that transactions are only created by human intervention thus transactions rates are minimized by how fast people can enter or change data A few months of monitoring the production environment should clarify this issue.
Only one transaction needs real-time turnaround. This transaction due to heavy Sybase processing takes 3 minutes to complete once it is started.
Promis, has higher transaction rates. It is unclear how this will behave.
Actually there are multiple queues, one for logging data, two more to handle tocolsis data and fromcolsis data. Each end user application, NPROJ, DCI/AFS/PDS, PROMIS will have their own inbound queue. These queues are modeled by DciQueue which actually creates a SharedQueue object and manages it. This is done to allow the visual front end access to the queue counter since DciQueue is based on Model and SharedQueue is not. These queues are not emptied at startup. If you were to stop and save an image with queued data then when you restart the image the "old" data would be read off the queues since that information would have been written out to disk with the image. Of course since they are in memory loss of power or application termination without a save will "lose" those transactions. However they are not "lost" since the Sybase stored procedure will resend them after 1 hour, and Colsis will resend his the next day. Promis will resend on the hour. So data is never "lost", just delayed.
If you need to save an image it is important to stop all processes, and ensure the queue counts are zero, before you save an image. NEVER save an image unless you really understand why you are saving the image. Never save an image..
DciGlobal class>>initalize will allow you to drop the existing queues, and instance of DciGlobal. Do not do this lightly. Also review the methods in private category of DciGlobal for utility functions to initialize or review instances of Dci objects in memory. It is doubtful that you will ever need to re-initialize DciGlobal. Hey this is a programmer thing, don't do it if you are not a Smalltalk Programmer and understand the implications. I used it to zap my image back to a known state so I could check for invalid instances of my objects.
PARM.TXT
Note this is test data, review the production file for real values...
This data is used during restart processing, spelling and character case are important! The first word followed by a space is the Smalltalk class name to use. The second word followed by the = character is the class method we are going to invoke. The last word followed by a return is the data we pass. So for example ImsTask IMSName=USCOLTST will invoke ImsTask IMSName: USCOLTST. This gets resolved to ImsTask perform: #IMSName: with: USCOLTST in the image. Spelling errors will cause runtime errors during the restart command or Image startup, so make changes carefully. Note since this is a generic processing routine you are not restricted to DCI class names you can cheerfully alter any other Smalltalk classes or give commands to any other instances. Note watch TCP/IP tranfers, we once transfered data via FTP and the ftp program inserted LF which causes no-end of trouble. Move this file as binary data!
EXCEPTION: To change the log file you will need to restart the system TWICE.
EXCEPTION: The DciGlobal is treated differently it really refers to DciGlobal Global, the instance of DciGlobal, not the class.
| DciGlobal queryForDelay=4 | Pause in seconds between and LpcLogon processing. |
| DciGlobal logFileSize=1048576 | Size in bytes for wrapping on log file. |
| DciGlobal screenPause=250 | Milliseconds to wait before seeing if 3278 screen is ready. If keyboard is still locked then loop again. Rarely invoked so changes here won't improve thruput. |
| DciGlobal screenMaxWait=60000 | Milliseconds to wait with locked keyboard before timing out and raising an error. |
| DciGlobal crashPause=60 | Pause in seconds when an Exception is raised. An exception can either be a fatal programming error, or a session/connection failure. |
| DciGlobal terminatePause=5 | Pause in seconds between task termination during restart. Don't change... |
| DciGlobal email='johnmci' | Email address for recipient of error messages |
| LogTask fileName='active.log' | Path name to log file. Can be anything like "F:\drophere\now\active.log" |
| ImsTask VMScreen='USERID' | When we have the VM screen, this is what we look for to confirm we have the VM screen. If not found it's an error. |
| ImsTask Msg10Screen='ENTER ONE OF THE' | When we have the Msg10 (VTAM) screen, this is what we look for. |
| ImsTask IMSScreen='COLSIS A' | When we have the IMS screen, this is what we look for. |
| ImsTask ColsisScreen='COLSIS MASTER' | When we have the Colsis welcome screen this is what we look for. |
| LppLogon sitesRestart=0 | For PROMIS. Used to reset promis sites |
| LppLogon sites='TPROMIS' | Name of first PROMIS site to poll for (PROMIS ONLY) |
| LppLogon sites='KPROMIS' | Name of seconds promis site (PROMIS ONLY) |
| LppLogon hostsRestart=0 | For PROMIS. Used to reset host tcp/ip information for sites |
| LppLogon hosts="TPROMIS URANUS" | Keyed tcp/ip name (URANUS) where TPROMIS exists |
| LppLogon hosts="KPROMIS SATURN" | Keyed tcp/ip name (SATURN) where KPROMIS exists |
| DciGlobal colsisQueuesAddName='toColsis' | Add a queue named 'toColsis to the list of queues we know about, generally we have a toColsis queues and a toSubsystem queue for each subsystem we support. The log queue is special and not mention here. |
|
DciGlobal buildProcess='toColsis LpConfigTask . . USCOLTST LpcLogon LpConfig' DciGlobal buildProcess='fromColsis LpcLogonTask . . USCOLTST LpcLogon LpConfig' DciGlobal buildProcess='toDci ColsisToDciTask ciim calender cims6b LpcLogon LpConfig' DciGlobal buildProcess='toNproj ColsisToDciTask ciim calender cims6b LpcLogon LpConfig' DciGlobal buildProcess='fromDci DciToColsisTask ciim calender cims6b LpcLogon LpConfig' DciGlobal buildProcess='fromNproj DciToColsisTask nproj nproj nprojpro LpcLogon LpConfig' |
This section builds the processes. For IMS txns toColsis queue name LpConfigTask Class to use to perform process . required just use the . . required just use the . USCOLTST identifies the IMS region LpcLogon identifies the ims get txn class LpConfig identifies the ims put txn class for Database txns: toDci queue name ColsisToDciTask Class to use to perform process cimm database user id calander database password cims6b identifies the database connect string LpcLogon identifies the ims get txn class LpConfig identifies the ims put txn class For Promis or Oracle the class names are different LppLogon LpPromis OracleToDciTask DciToOracleTask for example. |
| ImsTask queueDirectionsAdd='toDci adfrsoli akasdpbk akdrsoli akrjrpbk akrpltbd akupd602 akupd702 akupd704 akupd705 akupd706 akupd707 akupd708 akupd709 akupd777 cnrqprbk cntbdcor cntbdman manup102 manup602 manup702 manup704 manup705 manup706 manup707 manup708 manup709 manup777 mod2soli mohdsoli remvsoli reprttbd reqprebk rjasdpbk rjdrsoli rjrjrpbk rjrpltbd rjupd602 rjupd702 rjupd704 rjupd705 rjupd706 rjupd707 rjupd708 rjupd709 rjupd777 rpprebok rptbdpen rptbl702 rptbl704 rptbl705 rptbl706 rptbl707 rptbl708 rptbl709 rptbl777 rq1sttbd rqtbdtbd scclsoli' | Queue directions, tied to the queue names above, the first word is the queue, following words are Colsis function names, in this example we have the suite of AFS/PDS txns. Failure to match transaction names to correct queues and to ensure you've got ALL the transaction names coded will result in Problems! |
| ImsTask queueDirectionsAdd='toNproj akmilest designac dscancel rjmilest upcenter' | This adds the NPROJ names |
| SybaseTask SybaseErr='A Sybase error occurred, is the production Sybase database active? If this problem repeats phone DCI support' | Triggered if a Sybase error occurs. An error might occur given that the Sybase procedures are complicated and testing didn't really cover ALL the possible combinations. However multiple errors within a short time period point to a SERIOUS problem. Missing grant conditions are a quick way to generate lots of messages. |
| SybaseTask BadTxn='A incorrect Colsis Transaction Name was found. Call DCI Support' | Colsis and Dci should agree on the transaction names. The mapping tables aren't correct. |
| ImsTask RumbaError='A rumba connection error occurred. Is the network up? Can people connect via rumba? If the network is OK and this message repeats then phone DCI support' | Rumba couldn't do the screen I/O we asked for. If this repeats and VM is up, VTAM up, IMS up, Colsis up. Then the support person should be called. |
| ImsTask ColsisError='Unable to find Colsis signon screen. Is Colsis up? Can people connect to Colsis. If Colsis is up and this message repeats then phone DCI support' | Colsis is it up? |
| ImsTask IMSError='Unable to find production IMS system, Is the Production IMS system up? If IMS is up and this message repeats then phone DCI support' | IMS is it up? |
|
ImsTask Msg10Error='Unable to find VTAM, Is VTAM up? If VTAM is up and this message repeats then phone DCI support' ImsTask VMError='Unable to find VM, Is VM up? If VM is up and this message repeats then phone DCI support' |
VTAM is it up? |
| LpcLogonTask TxnError='LpcLogon transaction timed out. Is the network up? Can people connect to Colsis? If people can connect to Colsis and this message repeats then phone DCI support' | LpcLogon didn't respond correctly. Check the screen image. Perhaps Colsis went down for servicing? Typically when you halt Colsis you will get one of these since we are doing these TXN every couple of seconds. Once Colsis is down then perpare for a stream of messages from the DCI stating it can't connect. |
| LpConfigTask TxnError='LpConfig transaction timed out. Is the network up? Can people connect to Colsis? If people can connect to Colsis and this message repeats then phone DCI support' | LpConfig didn't respond correctly. Check the screen image. Perhaps Colsis went down for servicing? |
| LpConfigTask UnexpectedColsisError='LpConfig returned an unexpected error message. Contact DCI support' | Check the screen image. If a network failure occurs we can get put back to the VTAM message. |
| TaskBlock NoAnswerError='A Sybase Stored Procedure failed to return an answer. Contact DCI support' | Check the log and stored procedure. This should not occur if everything is runing normally. |
| TaskBlock GeneralError='An unexpected Error occurred. Contact DCI support' | TaskBlock>>raiseError: was called with a symbol. Look where the symbol was used and review the logic. If there is a mismatch between the mapping tables and Colsis or the stored procedures then you might get errors. |
Please note that the LpConfig, and LpcLogon classes have class variable constants that change very very rarely, if at all. Like the name of the transaction and the width of the screen. You'll need to alter the class definitions if you ever decide to change that data.
Examples: Failure when processing LpcLogon.
| January 8, 1996 16:55:14.000 |
LpcLogonTask LOGON SCREEN IMAGE Missing response |
|
| January 8, 1996 16:55:14.000 |
LpcLogonTask Declare Connect Error |
!@#$%^&* 'LpcLogon transaction timed out. Is the network up? Can people connect to Colsis? If people can connect to Colsis and this message repeats then phone DCI support |
| January 8, 1996 16:56:15.000 |
LpcLogonTask Disconnect shows problem PS |
END-OF-MAIL |
| January 8, 1996 16:56:26.000 |
LpcLogonTask Restart process at VM Screen |
VM/ESA ONLINE - LSI Logic Milpitas, Ca |||||||||||||||||||||||||||||||||||||||| ||| |||| |||||| | ||||| ||| ||| || | ||| ||| || |||||| | |||| || | ||||||||| ||| |||| ||| || || | |||| || | ||||||||| ||| |||| ||| || || | |||| || | || ||| ||| |||| |||||| || ||| |||||| | |||| || | ||| |||| ||| |||| |||||| ||||| |||||| | || ||| || || | |||||||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||||||| || Need Help? || || dial "HELP" to contact the LSI || || HELP Desk - (or 408 433-HELP) || |||||||||||||||||||||||||||||||||||||||| USERID ===> PASSWORD ===> COMMAND ===> RUNNING MILSYS01 |
In this example we have invoked LpcLogon.
LpcLogonTask>>processAction calls LpcLogonTask>>doLpcLogon to invoke the LpcLogon IMS transaction. Then LpcLogonTask>>getScreen is called to manage the image, it verifies the results by calling LpcLogonTask>>checkLpcLogon which looks for a non-blank character at the LpcLogon message return area. This character was NOT found, so LpcLogonTask>>waitForData: waits 10 times the screen pause time, or 250 Milliseconds * 100, for a total time of 25 seconds. It then rechecks the Presentation Space (PS). The data still was not found, so we first log the error, and raise an exception to declare an hard error condition.
The exception is handled by code in DciGlobal>>starProcess: The code here logs the error which waits "crashPause" time (Example had 1 minute). Then it calls ImsTask>>disconnect to drop the session. On disconnect we show the problem PS. The disconnect will stop and terminate the Rumba session.
Now in this example the screen response was slow, so on disconnect we have the correct "END-OF-MAIL" message. However it's too late and we are into error recovery. DciGlobal>>starProcess: will restart the process. On connect we restart the Rumba process, and redo the entire logon process.
If a transaction from Colsis was in-flight. For example a partial image was received. This transaction will have NOT been seen and not acknowledged. Colsis will re-send the transaction after it's delay time.
Other LpcLogon Errors encountered:
DFS065 20:15:36 TRAN/LTERM STOPPED
| January 8, 1996 23:59:52.000January 8, 1996 23:59:53.000 | ColsisToDciTask | !@#$%^&*a SybaseError( SQL Server msgno: 6401~msgstate: 1~severity: 16~~Cannot rollback aknowledge_prebook - no transaction or savepoint of that name found.~~srvname: CIMS6BSYBASE~procname: ack_nack_akrprebk~line: 619 ) | ||
In this example the execution of the stored procedure recv_ack_reqprebk resulted in a SybaseError. The error message from Sybase is dumped to the log and we continue. An acknowledgment is NOT sent to Colsis. So Colsis will resent the transaction after deciding it has not seen a response from us. Any Sybase errors should be fixed.
Example: Normal Query_Send processing.
| January 9, 1996 7:29:04.000 | DciToColsisTask | exec query_send_updat777 |
| January 9, 1996 7:29:10.000 | LpConfigTask | LPCONFIG $$ LPCONFIG FUNCTION UPDAT777 TRANSACT# 155 MODEL# LB302222KH SERIES_FLG TYPE S DESC SER: LCB300K FM: CELL-BASED CHIPCODE 3CKH SERIES LCB300K FAMILY CELL-BASED INACTIVE N $* |
A stream of Query_Send Sybase stored procedures are called every 1/2 seconds.
When a query returns a non-zero result set, the stored procedure we executed is logged, then a LpConfig transaction is queued. This is handled by the LpConfigTask which later logs a LPCONFIG transaction. We only show the name of the query_send stored procedures when they return one or more rows.
| January 9, 1996 0:54:36.000 | LpcLogonTask |
VM/ESA ONLINE - LSI Logic Milpitas, Ca
|||||||||||||||||||||||||||||||||||||||| ||| |||| |||||| | ||||| ||| ||| || | ||| ||| || |||||| | |||| || | ||||||||| ||| |||| ||| || || | |||| || | ||||||||| ||| |||| ||| || || | |||| || | || ||| ||| |||| |||||| || ||| |||||| | |||| || | ||| |||| ||| |||| |||||| ||||| |||||| | || ||| || || | |||||||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||||||| |||||||||||||||||||||||||||||||||||||||| || Need Help? || || dial "HELP" to contact the LSI || || HELP Desk - (or 408 433-HELP) || ||||||||||||||||||||||||||||||||||||||||
USERID ===> PASSWORD ===>
COMMAND ===> RUNNING MILSYS01 |
| January 9, 1996 0:54:40.000 | LpcLogonTask |
VM/VTAM V3.3
***************************** ***************************** ** **** **** * **** *** ** ** * ** * ** * *** *** * ****** ** *** * ** *** ** * *** *** * ** ** ** ***** ** * ** * *** *** * *** ** ** *** * **** **** **** * ** *** ** ** ** ***************************** ***************************** ***************************** ***************************** ***************************** *****************************
ENTER ONE OF THE FOLLOWING COMMANDS:
MILSYS01 - CICS - USCOLSIS - SIMWAR5V - UNDIAL
|
| January 9, 1996 0:55:42.000 |
!@# Error, didn't find the Colsis Screen |
!@#$%^&* 'Unable to find production IMS system, Is the Production IMS system up? If IMS is up and this message repeats then phone DCI support |
| January 9, 1996 0:55:43.000 |
LpcLogonTask On Disconnect then reconnect we find that CICS grabbed our screen |
MIS - LSI LOGIC - MILPITAS CURRENT TIME (PDT): 00:55:01
CCCCCC IIIII CCCCCC SSSSSS VVVV VVVV SSSSSS CCCCCCCC IIIII CCCCCCCC SSSSSSSS VVV VVV SSSSSSSS CCCC CC III CCCC CC SSSS SS VVV VVV SSSS SS CCC III CCC SSSS *** VVV VVV SSSS CCC III CCC SSSS *** VVVVVV SSSS CCCC CC III CCCC CC SS SSSS VVVVV SS SSSS CCCCCCCC IIIII CCCCCCCC SSSSSSSS VVVV SSSSSSSS CCCCCC IIIII CCCCCC SSSSSS VVV SSSSSS
ACTIVE SYSTEMS: MCAN - MILLENNIUM 2.0 - CANADA M2LL - MILLENNIUM 2.0
PLEASE, PRESS ENTER TO CONTINUE
CICS 1.7.0 - 8704 NETNAME: M62L24F TERMID: K24F SYSID: CICSPROD |
| January 9, 1996 0:55:58.000 |
LpcLogonTask Recovery will attempt a CSSF LOGOFF to return us to the VTAM message 10 screen |
VM/VTAM V3.3
***************************** ***************************** ** **** **** * **** *** ** ** * ** * ** * *** *** * ****** ** *** * ** *** ** * *** *** * ** ** ** ***** ** * ** * *** *** * *** ** ** *** * **** **** **** * ** *** ** ** ** ***************************** ***************************** ***************************** ***************************** ***************************** *****************************
ENTER ONE OF THE FOLLOWING COMMANDS:
MILSYS01 - CICS - USCOLSIS - SIMWAR5V - UNDIAL
|
| January 9, 1996 0:56:03.000 | LpcLogonTask |
CCCCCCCCC OOOOOOOO LLL SSSSSSSSS III SSSSSSSSS CCCCCCCCCC OOOOOOOOOO LLL SSSSSSSSSS III SSSSSSSSSS CCC OOO OOO LLL SSS III SSS CCC OOO OOO LLL SSSSSSSSS III SSSSSSSSS CCC OOO OOO LLL SSSSSSSSS III SSSSSSSSS CCC OOO OOO LLL SSS III SSS CCCCCCCCCC OOOOOOOOOO LLLLLLLLLL SSSSSSSSSS III SSSSSSSSSS CCCCCCCCC OOOOOOOO LLLLLLLLL SSSSSSSSS III SSSSSSSSS
COLSIS A TRADEMARK OF LSI LOGIC EUROPE PLC
USER-ID PASSWORD
USCOLTST USCOLTST USCOLTST
US COLSIS HOTLINE NUMBER IS 4357 (HELP) OR (408) 433-4357 SCHEDULED DOWN TIMES 8:00PM TO MIDNIGHT MONDAY THROUGH SATURDAY 2:00PM TO MIDNIGHT SUNDAY, CALIFORNIA TIME.
NOTE: THE INFORMATION CONTAINED IN COLSIS IS COMPANY PRIVATE UNAUTHORIZED DISCLOSURE COULD RESULT IN DISCIPLINARY ACTION PF11=SIGNOFF DFS2002 00:56:19 TERMINAL CONNECTED TO IMS M60IMST |
In this example when we attempt to restart the logon to Colsis we are grabbed by CICS into the CICS/VS application. This is a network wide problem, CICS will grab terminals that haven't disconnect properly. Since we are connecting to a pool of terminals via TCP/IP, we sometimes get a terminal that is owned by CICS. However when this occurs we attempt to do a CSSF LOGOFF which will take us back to message 10 and then we continue the logon process
Example: Unexpected LpConfig Error
| January 8, 1996 9:36:09.000 | LpConfigTask | LPCONFIG $$ LPCONFIG FUNCTION AKMDSOLI TRANSACT# 1996000034 DRTRANS# 71 $* |
| January 8, 1996 9:36:14.000 | LpConfigTask | RECORD WAS NOT FOUND ON DATA BASE |
| January 8, 1996 9:36:14.000 | LpConfigTask | !@#$%^&*LpConfig returned an unexpected error message. Contact DCI support |
In this example when we do the LpConfig transaction, Colsis responsed with an error message. We log the screen image and email the support person. If the transaction is not an AK or NAK then it will be resent after two hours. In this case with an AK,NAK we cann't do anything further.
Note the Support person will receive the error message since it is queued as a fatal condition during normal processing. These errors should be rare. They are only queued if the Colsis number is missing, or if the DCI or Colsis number is not-numeric. These types of edit checks should always work since we cannot pass a non-numeric value as a Colsis number. Also a missing Colsis number should not occur for the Colsis system, unless of course we are returning bad numbers as output from the query_send stored procedure. Record was not found on data base errors happen when multiple copies of a transaction flow to us. The first reply is processed by Colsis and the record id is marked completed. Later when the duplicate copy arrives in the Database it response with the original result. This result when it flows backs get this error since Colsis has already processed the first copy.
At the NT server:
Network failures seem to be the root cause of most downtime. During this process you may see message from rumba or telnet saying "Unable to resolve IP address", or "Unable to connect to host'. When Rumba fails to connect to the host because of a network connection failure, host failure, or router failure it exhibits the following behavior.:
A dialog message is displayed and control is returned to DciServer which starts another rumba system. This has the effect of creating multiple rumba session. When you reply to the dialog message the older rumba sessions that are in termination processing will quit. From time to time these additional sessions should be cleaned up.
When terminating the extra rumba sessions sometimes you may get a Dr. Watson error dialog stating the Rumba/Telnet session caused a memory violation, fatal to the old Rumba session, but not usually to Dci. You should be able to terminate all rumba session except for the two currently being used by Dci. Only do this process after the network has been restored and Dci is successfully running since termination during waits for network response seem to cause problems for Rumba.
Note we did have one instance where early forced termination of Rumba during a session outage caused a Dr. Watson error, which lead to an "Interface not Installed/Found" message from Rumba. This problem was fixed by a NT shutdown and restart since Rumba said it could not find a DLL when we attempted to start a Rumba session.
Other messages:
"Session name in use" Seen if doing forced Rumba session terminations during recovery processing, you should wait till Dci has fully recovered before terminating the extra rumba sessions.
Note that you can kill the existing active Rumba sessions, this will cause Dci to go into error recovery.
The Smalltalk server must be recycled every 15 days. There is a bug where if the Smalltalk server is left running for 26 days a timer counter in the tcp/ip logic overflows and crashes the Smalltalk VM. If you fail to restart the server then the VM will crash halting the function of the application.
Stopping Dci
1) Ensure the queues are empty. To stop things nicely you can stop the fromColsis task
Now invoke the "Terminate All Active Processes" menu item.
2) Once control is returned Dci has terminated all processing. Now you can choose to terminate VisualWorks if you for example are going to reboot the NT server, or just restart the interface which does not require rebooting NT.
2a) Complete shutdown -> Choose Process->Exit System... from the Process menu replication control window.
2b) Or just to restart do a Process->Restart System to restart the system without quitting the dciserver.
Adding new Transactions:
Two tables are used by Dci to mapping Colsis column names to Stored Procedure columns and execution offsets. The lsi_dci_colsisdci_mapping table is used to map Colsis to Dci translations. This table has three columns, "stored_procedure", "offset", "Colsis"
| stored_procedure | Offset | Colsis |
| recv_ack_manup709 | 1 | TRANSACT# |
| recv_ack_manup709 | 2 | FAB_FLOW |
| recv_ack_manup709 | 3 | DESC |
| recv_ack_manup709 | 4 | INACTIVE |
| recv_ack_manup709 | 5 | UPDATE |
| recv_ack_manup709 | 6 | OPERATOR |
In this example to process the MANUP709 transaction we map the LpcLogon field OPERATOR to column 6 when we create the execute stored procedure statement. Thus to add a new transaction you must add rows for each field that will appear on the LpcLogon screen and indicate the order which they are used in the execute statement. How Colsis presents the field names is not important but all field names must exist in this table for this function/stored_procedure.
For the reverse path we have the lsi_dci_dcicolsis_mapping table to handle Dci to Colsis traffic flow.
This table too has three columns, stored_procedure, offset, Colsis
| stored_Procedure | Offset | Colsis |
| query_send_updat709 | 1 | FUNCTION |
| query_send_updat709 | 2 | TRANSACT# |
| query_send_updat709 | 3 | FAB_FLOW |
| query_send_updat709 | 4 | DESC |
| query_send_updat709 | 5 | INACTIVE |
A unique set of the stored_Procedure column information is used to generate the queries we invoke every 1/2 seconds against Dci when we are looking for data to send to Colsis.
In this example to process the UPDAT709 transaction we map column 3 to FAB_FLOW in the LpConfig transaction. Note that the order of Colsis field names must match the expectations of the LpConfig transaction. Thus to add a new transaction you must add rows for each field that will appear on the LpConfig transaction. LpConfig does care about the order in which the field names appear.
Promis: Since oracle stored procedures can be stored in packages, you might have packagename.procedure name for the stored procedure information.
Logic:
Each transaction we send to Colsis is acked by an ack colsis txn. For example when we send an UPDAT709 transaction we expect to get back an AKUPD709 txn which will drive the recv_ack_akupd709 stored procedure. This means for each stored procedure defined in lsi_dci_dcicolsis_mapping we need a corresponding txn in the colsisdci mapping table. This response allows us to clear a flag in the Dci staging tables that indicate that Colsis received and processed our Transaction. Also since Colsis may reject our transaction there is also entries for the RJUPD709 transaction which we will receive if Colsis rejects the data on an edit problem.
However for Colsis to Dci traffic we directly return the ack transaction as part of executing the recv_ack_xxxxx stored procedure so an entry in dcicolsis mapping is not required. We never generate naks since from our viewpoint a nak is an error condition. If an error happens the ack is not returned, we log an error message, and later Colsis will attempt a resend. You should check the log from time to time to see if a transaction is being resent since this indicates a problem.
Check e-mail for error conditions.
Check for transactions being resent from Colsis. Currently resends occur about midnight (PST) time. A transaction should not appear in the log as being resent day after day, if this is noticed it usually indicates a problem with some of the stored procedures.
Check Dci staging tables using the procedure "xxxxxxxxx" to see if any Dci transactions are being resent.
Check To/From Colsis queues for excessive queue counts.
Ensure two rumba sessions are running and appear to be connected to Colsis.
Terminate any ghost Rumba sessions.
All processes on the replication control window should read active.
From time to time check the active.log to see if entries are being written. E-Mail problems can cause failures to notify you of problems with Dci, but all error are logged to the file.
All IMS screens containing useful or error data are written to the log file "active.log". If any errors happen during processing dealing with Colsis, Sybase, or Oracle these are also logged. E-Mail is generated when the error will cause down-time, or is determined to be a fatal internal error. You can use Excel to view the "active.log" file, you should see three columns. The first column is the timestamp generated when the error occurs. The second column is the name of the Class where the error occurred, or "!@#$" which indicates a fatal application error. The final column is either screen data, SQL that we execute before execution, or an error. These errors are prefixed by !@#$ in order to make finds within the multiple Megabyte file easier.
Errors fall into 4 classes
1) Sybase or Oracle connection problems
In general sybase and oracle are very stable.
2) Colsis connection, VM, VTAM, IMS, Rumba, Router, Network problems
Colsis is down for backups weekly, network outages are common.
3) Logic problems where unexpected events occur that we trap for. Examples like dropping of a stored procedure, in production, or incorrect alterations to the mapping tables come to mind. Internal program logic will trap most errors, and it flags the event for support via E-Mail.
Rare....
4) Fatal errors which generate a Stack Trace. Stack Traces may be data related, however each stack trace needs to be investigated and decisions made about code changes to prevent it from occurring again. Typical Stack Traces mean logic errors.
More rare, since this is an unexpected event.
PROMIS
A number of log files exist on the VMS machine. These need to be check and managed from time to time. Refer to the original Promis/Colsis interface docs and the new docs for information on how to manage this.
Sybase Client Software Came with SQL Server for NT
Vlab World Class Objects, Inc. 1-617-890-6260. Used for the EHLLAPI interface (3278 emulation)
Rumba For the mainframe NT Standard NT version of this software, used for EHLLAPI interface.
VisualWorks V2.51 Smalltalk Software from ParcPlace
1-408-773-7474
CompuServe, go ppdforum
Internet: http://www.parcplace.com
Purchased VW for NT, Sybase connect for NT, Advanced Tools, DLL and C Connect.
Support is good for 1 year from December 1st 1995.
V2.5 was upgraded to V2.51 via VM.exe upgrade and patchs to source code via PPDT
Configuration notes for various software.
Rumba Configuration: (Rumba NT for the mainframe V1.0)
Rumba is configured to use TN3270 to connection to mil1b as a IBM 3278 Model 2 terminal (24*80).
Under menu Session, invoke EHLLAPI Configuration, the EHLLAPI SDK check-box is CHECKED. Short Name is A
This configuration information allows a EHLLAPI SDK connection from VW using a terminal short name of "A". This configuration was saved in the c:\rumba\mframe directory as IMS.DSP. One other *.DSP file was created, this is IMS2.DSP, with a terminal short name of "B". Note a PATH name change to NT was needed so a DLL can find the *.DSP files, this was a manual change.
No other changes were made to the Rumba software.
PROMIS uses other terminal names and DSP files in order not to conflict with DCI.
SQL/CLIENT Configuration: (SQL Client V6.0 software).
A SQL/SERVER V6.0 CLIENT Utility software package was installed from the SQL/SERVER CD-ROM. The SQL Client Configuration Utility software was used to map a SYBASE session name to a TCP/IP address, driver, and port number. Installation automatically changes the PATH. For the production system you need to ensure the Sybase session name in the PARM.TXT has a mapping in the interface table.
ORACLE Configuration: (Oracle client V7.xxx software).
Client SQL*NET V2.xxxx software installed to talk to a Oracle V7.xxxx database. No specific version are required.
Client SQL*NET V1.xxxx software installed to talk to an Oracle V7.xxxx database using V1 protocol.
NT Configuration (NT V3.51)
The path statement was changed to include the c:\rumba\system and c:\rumba\mframe locations. c:\rumba\system was needed since it includes the EHLLAPI DLL software provided by Rumba. c:\rumba\mframe was needed since that is where IMS.DSP and IMS2.DSP resides and it is needed to allow automatic startup of the two screens by the VW application.
Tasking was set to allow for equal foreground/background sharing. This I believe is a feature of NT server, note that the replication server is CPU intensive, not network/disk intensive, but network priority was choosen as NT server option. Swap space was changed to a few 100MB.
The Compaq Service Support disks were used to update MicroSoft NT, to Compaq's special HAL, and service diagnostics subsystems and UPS support. These alterations to the base NT software are required to better support the advanced features of the Compaq HardWare. It was also suggested to upgrade the NT version to service pack level 4 to clear up any NT OS problems.
We just followed the LSI NT server installation guide to configure the server.
A Program group Dci Server was created:
The Dci Server Application properties are:
Description: Dci Server Application
Command Line: D:\VISUAL\BIN\VW.EX D:\VISUAL\IMAGE\DCISRV.IM
Working Directory: D:\VISUAL\IMAGE
TCP/IP time-outs should be changed from seconds to 15 minutes to allow for network failures. Note this is a rumba issue which has been addressed in Rumba for Mainframe windows 95 V2.0, but not yet in the NT offering. Existing values tend to clutter the screen with ghost Rumba sessions when it fails to connect to mil1b.
The MS Resource kit's srvany.exe was used to allow DciSrv to run as a service, this allows the Dciserver application to startup after a power failure without operator intervention. The screens only appear when a person logs into the server however the application will run in the background as a service without having a person logged on. The documentation on how to do this is contained in the document srvany.wri which came from Microsoft. A copy of this document is contained in the C:\VISUAL\ directory.
A service DciServer was created and points to c:\visual\srvany.exe.
In the Registry:
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/dciserver we added a Parameters key-folder.
In the Parameters entry we added:
AppDirectory: REG_SZ: D:VISUAL\IMAGE
Application: REG_SZ: D:\VISUAL\BIN\VW.EXE
AppParameters: REG_SZ: D:\VISUAL\IMAGE\DCISRV.IM
Which of course asks the srvany.exe program to run the program VW.EXE with DCISRV.IM as the startup parm and to set the working directory to D:\VISUAL\IMAGE. This mirrors the program item information we used in the program manager when we created the Dci replication application group.
VW Configuration (VisualWorks V2.5 and DciServer V1.1+)
The application consists of :
/VISUAL/BIN
VW.EXE The Smalltalk engine
VWUT16.DLL Dll required
VWUT32.DLL Dll required
/VISUAL/IMAGE
DCISRV.IM the image
DCISRV.CHA the change file for the image
DCISRV.SOU the source file for the image.
COPY.LOG a copy of the log file, created on demand by the operator.
/VISUAL/LOG
ACTIVE.LOG the log file
/VISUAL/VLAB/BIN
errors.lst Required.
HLLAPWCO.DLL DLL required for HLLAPI
/VISUAL/srvany.exe the MS service startup application
/VISUAl/srvany.wri the MS service instructions.
For Dci Version 1.14 the image consumed about 16-18MB of memory during idle processing. During the startup phase it was decided not to package the application or and use a runtime engine. This allows for better developer diagnostics which will continue until a decision about stability is made.
For V1.14 the development image had this information. Note the advanced tool kit is not needed to run DCI.
Version Id:
#[25 26 42 0 25 0 0 1 25 26 42 13]
Patches:
AT2.5-advanced-bench
AT2.5-advanced-fullbrow
AT2.5-advanced-install
AT2.5-advanced-launch
AT2.5-advanced-metanum
AT2.5-advanced-parser
AT2.5-advanced-profiler
AT2.5-advanced-projbrow
AT2.5-advanced-sql
AT2.5-advanced-support
AT2.5-advanced-sysanal
CScanner Release 2.5
Database Connect for SYBASE - Release 2.5 <---- Needed
DLL and C Connect-VW2.5 <---- Needed
VW2.5-extras-events <---- Needed
VW2.5-utils-socket <---- Needed
The advanced tool kit was loaded but is not needed for the application. (Useful for tuning)
Database connect for Sybase is needed.
DLL and C Connect is needed.
Also loaded EVENTS.ST and SOCKET.ST from the extras and utils directories.
Additional Smalltalk software loaded via GNU or public domain sources:
Progress.st
NAME Progress Widget
AUTHOR brant@cs.uiuc.edu
FUNCTION create percent done bars (as specs or views)
ST-VERSIONS VW2.0
PREREQUISITES none
DISTRIBUTION world
VERSION 1.0
DATE 10-Apr-95
This code adds a new tool to the Pallette window which allows you to create percent done widgets. Nice but not critical.
Network-Clients.st
Used for the SMTP E-Mail interface, part of the SmallWalker Software, because it is a base class the rest of SmallWalker is not needed.
NAME SmallWalker
AUTHOR Kazuki Yasumatsu <kyasu@crl.fujixerox.co.jp>
Yasuo Soda <soda@fxis.fujixerox.co.jp>
FUNCTION A World-Wide Web browser
ST-VERSIONS VisualWorks 2.0
PREREQUISITES utils/socket.st {Part of base VW software}
CONFLICTS WITH
DISTRIBUTION world
VERSION ID 1.0
VERSION DATE September 29, 1995
SUMMARY
SmallWalker, a World-Wide Web browser for Smalltalk, offers the following
features:
o Supports HTML 3.0 + some Netscape extensions
o Supports Image Formats:
GIF, XBM, XPM, PBM, PGM, PPM and JPEG (needs djpeg v5)
o Supports Internet Protocols:
http, ftp(FTP), news(NNTP), mailto(SMTP)
The code of SmallWalker contains the following re-usable class libraries:
o HyperText
o SGML Parser
o Image Format Reader/Writer
o Network (HTTP, FTP, NNTP, SMTP, POP) & RFC822 Message Parser
o External (Persistent) Dictionary
SmallWalker is provided at no charge under the terms of the GNU
General Public License Version 2, June 1991. The text of that
license is included in the distribution (see the file "COPYING".)
It is provided in source-code form.
NOTE: SmallWalker is originally written by K. Yasumatsu for OW R4.1,
and it is ported to VW2.0 by Y. Soda.
Kazuki Yasumatsu <kyasu@crl.fujixerox.co.jp>
Yasuo Soda <soda@fxis.fujixerox.co.jp>
Changes to the Image:
Reset ObjectMemory to use 2X for cache instruction memory size, see ObjectMemory(class)>>sizesAtStartup:
Changed ExternalDatabaseSession>>delayUntilReady to raise an exception when Sybase takes 8 or so minutes to respond, this is a critical change!
Changed Sybase connection class to use #Sybase42NTInterface versus 4.6 (See VW Sybase install manual)
Changed BlockClosure to create DciProcesses when requested via forkDciAt: or newDciProcess.
Changed WCOMetaObject>>new to not create various WCO objects.
Changed WCOMetaObject>>initialize to not create various WCO objects.
Changed WCOResult>>errorCollection to do lazy initialization to improve memory performance
Changed various WCO methods to remove halt statements.
Due to the static nature of Dci and it's low Smalltalk complexity you should not need to upgrade VW from V2.51 to later versions unless problems with the VW 2.51 engine or image cause problems. This also applies to NT V3.51. Once it's running the software versions should stay static... In theory you could use V4.0 of NT, but why bother living through the hassle of confirming the environment is stable?
A full backup of the NT machine was done on production night. As image changes are made new tapes should be created. Follow the instructions to use MicroSoft backup. You can choose either a full backup or an incremental append to the existing tape.
To restore follow the instructions for restoring a NT image from a backup. If a full restore is not possible then install RUMBA from the master disks, and restore the any *.DSP files with the \VISUAL directory. Then follow the instructions for making DciServer a service on the target machine using the write document in the \VISUAL directory.