Null input parameter unexpected d4seek

The selection of Data Carry carries the same claim with its corresponding information to the next function. If Data Carry is not used, the System Controller first checks for any messages and displays appropriate screen indicators It then provides a screen or screens which permit the selection of a claim number Once a claim number has been chosen the System Controller again checks for messages before undertaking any business transaction A business transaction is the part of a function which changes or creates a specific record or set of records.

Any business transaction can be interrupted to "window" to another function of a different type. The original transaction is restored when the operator windows back out of the other function. When the business transaction is then ended, the function is exited and the System Controller returns to the Function Control position to evaluate the next requested function. All the available functions are shown in block form in FIG. The CAS menu screens serve as a table of contents enabling an operator to select a desired system function or transaction.

Following a successful logon, the system displays a Default Primary Menu tailored to the operator's specific needs and security level. See, e. The appropriate Primary Menu screen for a particular operator is determined by a Default Menu Number which is entered in the operator's Staff Table. This Secondary Menu displays less frequently used functions and transactions.

Using the Primary Menu or the Secondary Menu, an operator can access virtually any available system function. System functions are accessed from the Primary or Secondary Menus by actuating the "PF" or "Function " key corresponding to the desired function e. The processing of a claim begins upon receipt of a notice of loss. These "loss notices" are received from agents, insureds, customers or claimants, either through the mail, in person, electronically or over the telephone.

In a typical claims office, a person called a Claim Assistant is primarily responsible for the input of loss notices into the CAS System. This is the Loss Processing Transaction Interface screen.

This screen is used to input skeletal policy information which, in turn, is used to extract policy information from a Policy File which may reside in one of the Host Computer's databases or in a local database.

Even if some of the policy information is maintained in one of the Host's databases, most claim's offices have a Policy Index Table which tracks the name, address, policy number, etc. This Policy Index is available for display through the CAS system to assist in the proper extraction of policy information.

The main element required to extract policy information from the Policy File or Policy Index Table is the policy number. If no policy record is found in a Policy File or Policy Index Table, an explanatory error message is displayed and the information must be input manually.

Even if no policy number is found, the loss report must still be maintained. Therefore, a "non-claim" "record report" is maintained on the system.

When information is successfully extracted from the Policy File or Policy Index Table, the initial input fields i. The loss screens are formatted according to a policy symbol indicating the type of policy and the line of business specified on the Interface screen. The number of screens and their sequence is relative to the number of claims arising from the loss occurrence and the manner in which the loss was reported.

The initial screens accessed contain fields for inputting required information that applies to the entire loss occurrence. Reporting screens are used to record information which is specific to an individual claim arising out of the loss occurrence. Where the notice of loss is received electronically from agents, insureds, customers or a central reporting center, the information is in a form which is used to prefill fields in the LPT. The electronically reported information must be reviewed for accuracy but this type of reporting substantially reduces input time.

The following is a list of screens specific to the automobile line of insurance business which will be used as an example for purposes of this description in their logical order of appearance screens marked with asterisks will potentially become new claims :. Special Procedures optional unless extracted from Policy Index Table. Much of the information necessary to complete the input called for by this screen is prefilled or input through the LPT Interface screen and the information extracted from the Policy File e.

Any additional information that is needed to complete this screen is input manually through the keyboard. The Special Procedures screen, shown in Table VII, is accessed from the Policy Information screen and is used to note any special handling procedures, specific to the policy involved, that are required in the processing of the claim. Multiple screens are available for input and information can be added, modified or deleted as needed.

If special procedures are enumerated in the Policy Index Table this screen will be prefilled. The Vehicle-Driver Coverage Information screen, shown in Table VIII, is used to enter information pertaining to the insured driver's coverage limits as well as vehicle information such as the make and model of the car.

Any information which is prefilled to this screen can be modified. This screen is generally accesssed after information has been entered to the Policy Information screen.

It may, however, be accessed from a number of screens within the LPT. The information includes the accident. This screen is generally accessed following input of the Vehicle-Driver Coverage Information screen, it also may be accessed from a number of screens within the LPT.

The Witness Information Screen not shown is accessed from the Description of Accident screen and is used to input basic witness information when necessary e. If information about more than one witness needs. This screen permits the viewing, addition, modification or deletion of witness information. This screen can also be used, for example, to indicate who should be contacted for further information if the insured is unavailable. A Responsible Party screen not shown may be accessed from the Description of Accident screen to enter any relevant information indicating responsibility for the loss.

A Claimant Information screen, shown in Table X, is used to add claimant information e. The information requested in the Claimant Information screen must be input before a claim can be added for that claimant.

Once this information is input, multiple claims can be added for the same claimant as necessary. The Auto-Physical Damage Information screen, shown in Table XI, is used, when necessary, to enter information pertaining to any damage to an insured vehicle. The operator is also prompted to enter a variety of additional information including: incurred loss information, the estimated incurred allocated expense, a repair estimate, etc.

A description of the property, the damage, as well as the estimated incurred loss and other additional information is entered through this screen. An Injured Party screen is provided to enter information about any party injured in the accident i. A Service Provider screen, not shown which may be accessed from the Injured Party Information screen is used to record the names and addresses of the individual s or institute s that provides medical services to the claimant.

Each claim at least one for each of the asterisked screens on the earlier list is displayed in summary form, showing the loss type, the claim symbol an internal processing code , the claimant's name as well as the estimated incurred loss. If more claims are involved than space permits, additional screens will be generated for those remaining.

From the Claim Set up screen, the LPT can be completed, routed to another staff member for additional input or review, or edited further.

In order to complete the LPT all required fields must be validly filled. If the operator is unable to complete the required field s the LPT will not be completed and the claim number s will not be assigned. In such situations, however, pre-determined dummy codes are used to maintain the notice of loss.

Alternatively, if other staff members may be able to provide the necessary information, the incomplete "claim" may be routed to them. This procedure is discussed in more detail below. Routing the incomplete LPT generates a message to the receiving staff member's mailbox to let him know that he should review the incomplete "claim".

He, in turn, can then route the unfinished LPT to any other staff member. There is no limit to the number of times this routing can occur. Editing of the unfinished LPT can be done by actuating certain function keys corresponding to the small "secondary" menu on the bottom of the Claim Set-Up screen. By using the function keys all of the LPT screens can be redisplayed except the interface screen. When a screen is redisplayed it can be edited in accordance with regular system editing procedures.

When the Claim Set-Up screen is completed, pressing the appropriate function key activates an Automated Claim Numbering facility. This facility automatically assigns a number, from a pre-determined range, to each claim or record report of the LPT record reports are given numbers from a separate range from the range of claim numbers. These numbers are the primary method of accessing individual claims for processing and review. When the LPT is routed to a staff member he receives a message in his electronic "mailbox".

The message comprises a very brief summary of certain information already input into the LPT and indicates who routed the LPT, the reason for the routing a referral, usually for review in supervisor's case. When a supervisor retrieves an unfinished LPT from the database which has been routed to him for review, he typically fills in certain information in the various LPT screens including the estimated incurred loss, the estimated incurred allocated expense, special procedures, etc.

The supervisor's input generally completes the LPT. When the LPT is complete complete, meaning all initial information available has been input and the supervisor assigns the claim, a sequential claim number or record report number is automatically generated and assigned by the system to every claim resulting from the loss. A supervisor in the claims office specifies various ranges of claim numbers to be used by the system through a Number Assignment Transaction screen not shown.

A claim that has not yet been assigned and given a claim number or record report number is considered to be "in-process. Thus, to add a companion claim arising out of a previously entered loss a separate function called the Add Companion Claim transaction is provided.

All information previously input through the LPT e. Each LP-Element Change transaction is comprised of prefilled screens containing essentially the same fields as the corresponding original LPT screens.

Changes are made on a per-screen basis. In other words, information entered via an LPT is redisplayed screen-by-screen for correction of any item on that screen.

Table XVII. The cursor is moved to the desired field location on the display and the original information in that field is typed over. This continues through each succeeding field requiring modification. If the modified information has fewer characters than before, any extra characters may be deleted by erasing to the end of the field.

This method is used to remove all the information in a field. The cursor is placed in the first character space of the field and the "Erase Key" is pressed. This deletes all the information in the field. These are essentially fundamental changes which impact the accessibility of the entire loss transaction.

First, the entire claim number is entered. Then, the appropriate function key is selected for the Control Change function desired.

The majority of the information on LP-Control Changes Claim Number screen is prefilled with the existing control information. However, a field is provided for entry of a new claim number. When the new claim number is entered, this transaction is processed and a comment providing both the old and new claim number is automatically generated to the Activity Log discussed in detail below.

The LPT Inquiry transaction, available for viewing purposes only, consists of a series of screens which are essentially the filled screens of the current LPT. This screen lists all. Claims initially received, set-up, and numbered in one office may need to be transferred to another office to Handle to Conclusion HTC due to a change in the claimant's or insured's address or other change in location.

To do this, the originating office completes an HTC Sent transaction, through CAS, and electronically transfers the claim file to the new claims office. The difference between the HTC Received screens and the LPT screens is the addition of a claim number field, a sending office field and the removal of the claim symbol field as a separate field. When the HTC Received transaction is accessed, an Interface screen returns which is identical to the LPT Interface screen and follows the same completion procedures and subsequent screen flows.

Shown below in Table XXII, is an example of one of the HTC Received screens with the addition of the claim number field and the sending office field marked with asterisks. A "Service Item" is a request by one claims office to another claims office for a partial investigation of a claim that is being handled by the first claim office.

Such requests can include obtaining a police report, a signed statement, etc. A Service Item request may be mailed or electronically transferred to a receiving office. If the request is transferred electronically, the Service Item transaction screens prefill. In such cases, when the Service Item request is received it goes to a predesignated supervisor's mailbox for review and assignment.

The Service Item transaction screens not shown are similar to the LPT screens and follow the same screen flows and completion procedures. The difference between the Service Item screens and the LPT screens is that not as much information is required for processing a Service Item and the Service Item screens contain fields for recording Requesting Office information e.

The Staff Tables function maintains information relevant to the claim office personnel. This information includes authority level, case load maximum, job title, etc. Supervisors determine the proper reserve authority level, payment authority level, diary limit, case load amount, etc. Only claim office personnel having the proper authority are able to view, update, and or delete information on the Staff Tables. When the Staff Table function is accessed, the operator can: view a particular staff member's table; add staff members to the staff directory; search for a particular staff member; or modify information on the Staff Table.

The ability to perform any or all of these functions is entirely dependent on the operator's Staff Table authority. This directory will display on multiple screens, if necessary, depending on the number of staff members.

This screen is a prefilled table of job descriptions applicable to a claim office. By positioning the cursor on the appropriate job description and pressing "Enter" the selected job description pre-fills into an Add Staff Member screen. This Add Staff Member screen is used to input the various authority levels, system IDs and other information regarding the new staff member. See Table XXV. Alternatively, a Find Staff Member screen not shown is available for directly accessing a particular staff member's screen.

All that is necessary is to input that individual's initials or last name. This screen. Additional screens are available within the Staff Tables function to modify staff member information and to delete staff members from the file. If no match is found, the operator will not be able to access any CAS functions.

Once the operator has successfully logged on, the System Controller must look to the Staff Tables to display the proper Primary Default menu which is indicated in the Default Menu Number field of the user's Staff Table.

Still further, the Staff Tables are referenced to properly route alert messages, to limit function access, to limit payment and reserve activities, to prefill operator information for Activity Log entries and to specify when diary and authority level alert messages will automatically be generated.

In each of these cases, the Staff Tables are referenced to insure the proper operation of other system functions which are user specific. Another available function, which is a derivative of the Staff Tables, is the Caseload Monitoring function. This function can produce a series of reports which permit supervisors and other claim office managers to monitor the case loads of individual staff members, claim units and the office as a whole. This series of reports can include information such as monthly claim openings and closings, the number of claims handled by line of business, and total caseload counts.

This report, which can be done by individual staff member, claim unit or the entire office, shows the number of claims of a specific monetary range which are being handled. This is an important management tool since higher valued claims generally require substantially more time and effort to complete.

The Directory Tables function is used to store and display names, addresses and other pertinent information about currently used services and individuals. Each listing in the directory tables is automatically assigned a unique directory code upon initial input. The code includes a category designation so that, for example, a list of defense attorneys can be readily displayed. This screen is a listing of entries in the Directory Tables.

The Directory Tables List screen will automatically display the appropriate category of entries for filling in certain empty text fields during Text Processing. In such cases placing the cursor on the correct listing and actuating the correct function key will fill in the blank field. Additional screens not shown are also provided to delete and modify individual entries.

The screen structure and format is very similar to that used for the Staff Tables function. The Info Search Facility provides the ability to search for information resident on the local data base on-line as well as data that has been purged to an off-line database.

Info Search will access both "in process" and "processed" claims. The Info Search Facility performs searches by using any of the following criteria: 1 claim number; 2 claimant name; 3 insured name; and 4 policy number. One or more of these pieces of information may be input through the Info Search Facility screen. If the entire name is not known, the system will also search on a partial name.

To further restrict the search and limit the number of records returned, additional information about the claim s can be input through the Info Search Facility screen such as loss date, insured address, claimant address, etc.

A Select Applicable Insured Information screen not shown is displayed when the insured name is searched through the Info Search Facility screen and multiple records are found. Similar screens are available when claimant information is used as the search basis. Off-line Information is displayed in the same manner through separate Off-Line Claim Information screens not shown. The Activity Log is a record of the key activities involved in the processing and adjustment of a claim.

The Activity Log is created in one of two ways. Alternatively, the system will create an Activity Log automatically, if one does not already exist, when an operator moves directly to the Activity Log function for a specific claim. If another CAS transaction generates a comment to the Activity Log and the Log does not already exist, it will likewise be automatically created.

There is no limit to the number of Comments screens in an Activity Log. The screens within the Activity Log are displayed in reverse chronological order allowing the operator to view the most recent entries to the Log first. Any time an entry is made to the Activity Log, the claim number, insured name, claimant name, loss date, claim description and estimated incurred loss fields are pre-filled.

All these fields are protected and cannot be. When a comment is automatically generated to the Activity Log, these fields are likewise prefilled and protected. In fact, every field in the Activity Log is protected once an entry has been made. This provides an audit trail for any necessary claim review. An Activity Log Index screen, shown in Table XXXV, is provided to show the general status of a claim and serves as an index to multiple claims of a particular loss occurrence.

The Activity Lot Index screen, which is prefilled, can be used to select the desired claim by positioning the cursor next to the claim number and pressing the appropriate function key.

This information may appear pre-filled if these dates or comments were previously entered or generated. If the fields are pre-filled, they can be modified by overlaying the information. If there are no pre-filled dates or comments, the correct date or comment can simply be added in the blank field. An Activity Log Payment Comments not shown is available for viewing. This screen is pre-filled and displays all payment comments which have been automatically generated to the Activity Log.

This provides a quick, efficient way to evaluate a claim's payment record. There are three types of reassignment transactions: claim; family; and global.

The latter is accomplished through a Global Reassignment screen not shown. This transaction requires a high security level and can only be undertaken by certain staff members. A Claim Status Change function is used when one of the following activities is required on a claim file: 1 close a claim when no closing check is being issued at the time of the closing; 2 reopen a closed claim that is to remain open; or 3 change the reserves on an open claim.

A Claim Status Changes Claims Select screen not shown is used to enter the claim number for which a change is required. This screen is displayed after selection of an type of Claim Status Change through the Claim Status Change menu screen. If the claim is being closed without a payment, the Claim Status Change-Close transaction must be used to close the claim. There are two types of claim reopenings.

A regular Payment transaction is used to reopen and close a claim if an additional payment is made and the claim does not need to remain open. A Claim Status Changes-Reopen transaction is required to reopen a claim which will remain open. The loss type will remain the same as it is when the claim was closed. When a Reserve Change is processed, a comment is automatically generated to the Activity Log.

The claim number, policy number, insured and claimant name fields will pre-fill with the previously entered information. The Initial Reserve field will pre-fill with the original that was entered in the LPT and the Estimated Incurred and Paid fields will prefill with the most current totals. The Text Processing function provides the ability to perform various types of text processing without leaving the CAS system. Text Processing can generate preformatted documents and pre-fill blank fields in the documents' bodies by extracting information input through other system functions.

Upon operator request, all applicable information, previously input into CAS via other transactions e. LPT is pre-filled into the requested document. In the event that all the information necessary for form completion cannot be extracted from the system, the Text Processing function prompts the operator to manually input the additional information. A core group of generic forms are preformatted for use in all claims offices.

However, each claims office can customize its own forms. After the form is created it is brought within the Text Processing function where it is coded so that all blank fields will prefill. Thus, a local claims office is not constrained by the preformatted forms.

A Document Claim Selection screen not shown is used to select the claim s for which documents are needed. A Document Claim Request screen, not shown is used to select the particular claim for which correspondence is desired. A Document Request screen, shown in Table LX, displays a list of preformatted documents applicable to the selected claim.

From this screen an operator may select the specific form s to be printed. Only those documents appropriate for the type of claim which has been input are listed. If multiple claims are selected for correspondence generation, form lists are displayed one at a time for each claim. Text Processing pulls applicable information from within the system and pre-fills as many fields requiring completion as possible.

If all the required fields are completed and if a particular designation is made i. If the system is unable to pre-fill all of the fields, the requester is prompted to input the necessary information via a Directory Completion screen if the information is contained in a directory table or with a Document Completion screen if the information is not contained anywhere in the system.

It lists the. If a designation is made i. Each Document Completion screen is unique for each specific document. Any blank fields displayed on the Document Completion screen are those which the system was unable to complete with the available system information. Fields which are necessary in order to generate the document, are highlighted and underlined. A document cannot be sent to the print queue if a required field is blank. Ultimately, if a required field cannot be filled, the document request must be cancelled.

Some forms are generated automatically without any operator intervention. This may occur, for example, when an LPT is processed, or when certain LPT screens are completed and a form is generated to provide system or legal backup for the loss notice.

If the system reaches an automatic form generation point, and the necessary information to send the form to the Text Processing Print queue is unavailable, an alert message is generated. The CAS system also supports the preparation of free form documents through the Word Processing function, as indicated previously.

This permits an operator to type any letter or form that is needed. The usual edits are available to permit the revision of any errors. There are two main output facilities available through CAS. Local Copy is available to print out single screen transactions or to print out one screen of a multi-screen transaction. Local copy is sent to the designated printer without LOHC intervention.

As indicated above, the Text Processing function provides the means for the selection and completion of the majority of the claim office forms and letters. All documents are complete coming off the printer. Some documents are ready for mailing immediately after printing. However, multipart forms need to be torn apart and distributed. Depending upon office structure, an output operator generally pulls all text processing output and mails or completes the "processing" of the output.

Depending on the form, a document request is also sent to a mail print queue or a file print queue or both. After documents are sent to one or both of these print queues, the request for document printout is initiated, as described above, via the print queue facility. Documents are listed by group paper type with the number of documents requested and any special handling instructions. A Document Summary File Print Queue screen not shown is also provided to give an overview of the documents to be printed and filed.

Again, documents are listed by group and number of documents requested along with any special handling instructions. A number of Detail Queue screens not shown reformat the summary information of the Document Summary Mail and File Print Queues into detailed columns that list:.

The documents displayed are listed in claim number order. The Local Output Hold Control facility LOHC is an electronic storage facility designed to hold information which is waiting to be printed as a result of a transaction input to the local database.

The Print Transaction, when requested, generates a hard copy of selected processed completed , multi-screen CAS transaction screens. This may be used, for instance, when a claim is to be transferred to another office for completion or partial investigation. If a daily system backup is run, the Transaction Logging data is deleted. A number of system and database reports are also printed which flow through the LOHC. Such reports include processing error reports, reassignment reports, overnight system reports, etc.

All the reports reflect a system generated creation date. The creation date is the date the report originally entered the print queue loaded in LOHC.

For On-Line reports, this is the date the information to produce the report was input. For Off-Line reports, this is the date following overnight processing. All reports are stored in the LOHC facility until they ar printed. Once loaded to LOHC, they have a predetermined retention period. After the retention period, an automatic purge occurs and reports that have been sent but not printed will no longer be available. A Status Option Menu not shown is used to select reports to be displayed.

The reports are then displayed in accordance with the specific field requested such as date, form number, group or report number. One or more fields can be entered in the Status Option Menu e.

A Default Status screen, shown in Table XLIV, displays all reports in ascending order by group and secondarily, in descending order by date within the group. An operator can delete or print all sent or unsent pages of a report by positioning the cursor on the left side of the desired report and pressing the appropriate function key. In addition, an operator can change the printer destination, the number of copies or select specific pages to be printed by using the Print With Options menu shown in Table XLV.

Payments are one end result of the processing of claims. The entire investigation adjustment process and the. On the error on the server side, could you post an example of the last few entries from the s4server log file right before you have the problem? Every time I think about the durability of codebase, I want to kick myself for waiting to long to purchase the source code release on server. By the time I got around to it, Sequiter was gone. As to Delphi, do you ever get the Null problem described above or is that purely a Visual Basic problem?

Responding to the question relative to CB server source code, I've been intending for some time to ask the copyright owners about that but have been distracted by real life. Hope to get that done later this year and hopefully have that code posted too. I have the executable for that in its last version, but do not have permission yet to release it in Open Source. Glad that there is ongoing interest in this product, as it is a reliable, robust, high performance data access solution.

Jim that would be beyond terrific!! Also was the source code to code reporter ever released. As to using codebase it is still my favorite C library of all time.

It is highly portable, with few dependencies and just works. Just so you know, Sequiter has released the remaining source code to the Open Source Community including the server and the server administration module. We are working on organizing this code. It turns out there are version control issues and we need to establish that the source code can actually be compiled into working versions Stay tuned.

We hope to have this published to this repository by the middle of Great news! Thank you for updating this wonderful code. It seems the portability version is not included in this release. Is it planned to include it too? Now that codebase is open source, can somebody post the s4server source code to this project?

Skip to content. Star New issue. Jump to bottom. Copy link. I thought R3 was the last release on codebase 6. From codebase technical support a long time ago. From sequiter tech support. Null Input Parameter unexpected, usually in a d4seek operation, without any sense. The only error saved in the s4server. Few times with Windows ErrorNumber , but usually 0. I appreciate this discussion; we would also be interested in the client-server source.

Occasionally we run into an odd issue that seems to be related to several different things. Overall however we've found it over the years to be quite durable and plan to continue to support it. See if this solution works for you by signing up for a 7 day free trial. What do I get with a subscription?

With your subscription - you'll gain access to our exclusive IT community of thousands of IT pros. We can't always guarantee that the perfect solution to your specific problem will be waiting for you. If you ask your own question - our Certified Experts will team up with you to help you get the answers you need. Who are the certified experts? How quickly will I get my solution?

We can't guarantee quick solutions - Experts Exchange isn't a help desk.