US11184463B1 - Interacting with a client system to gather client data to use to diagnose a problem at the client system - Google Patents

Abstract

Provided are a computer program product, system, and method for providing diagnostic services to a client system over a network. A program is transmitted to a client program at the client system including a command to retrieve a block of data. The client program is executed to retrieve the block of data indicated in the command and display data in the block of data in a client user interface at the client system. The client program transmits the data displayed in the client user interface to the diagnostic system in response to user indication to transmit the data displayed in the client user interface. The data received from the client program is rendered in the client user interface. The received data is processed to determine a next operation in a diagnostic workflow program with respect to the client system.

Description

BACKGROUND OF THEINVENTION1. Field of the Invention

The present invention relates to a computer program product, system, and method for interacting with a client system to gather client data to use to diagnose a problem at the client system.

2. Description of the Related Art

To troubleshoot a customer computer system, customers may send computer data and files to a remote diagnostic service over the network by uploading the data and sending via File Transfer Protocol (FTP) or email for analysis by the diagnostic service. The diagnostic software tools to analyze the customer data may not be available or run on the customer computer. In certain situations, customers may decline to transmit information to the remote site out of concerns over loss of control of their data. In addition, some countries have laws that do not allow certain data to be transmitted outside of the country.

There is a need in the art for improved techniques for remote diagnosis of computer systems over the Internet or other networks.

SUMMARY

Provided are a computer program product, system, and method for providing diagnostic services to a client system over a network. A program is transmitted to a client program at the client system including a command to retrieve a block of data. The client program is executed to retrieve the block of data indicated in the command and display data in the block of data in a client user interface at the client system. The client program transmits the data displayed in the client user interface to the diagnostic system in response to user indication to transmit the data displayed in the client user interface. The data received from the client program is rendered in the client user interface. The received data is processed to determine a next operation in a diagnostic workflow program with respect to the client system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an embodiment of a diagnostic computing environment.

FIGS. 2a, 3a, 4a, 5a, and 6aillustrate examples of the display of data at a client system before transmitting to a remote diagnostic system for diagnosis.

FIGS. 2b, 3b, 4b, 5b, and 6billustrate examples of how data from a client system is rendered at the remote diagnostic system for diagnosis of the client system.

FIG. 7 illustrates an embodiment of operations performed at the client system to gather data to send to a remote diagnostic system to diagnosis problems at the client system.

FIG. 8 illustrates an embodiment of operations performed at the diagnostic system to process data transmitted from the client system being diagnosed to render at the diagnostic system and process for diagnosis of the problem at the client system.

FIG. 9 depicts a computing environment in which the components ofFIG. 1 may be implemented.

DETAILED DESCRIPTION

A user at a client system may be hesitant to automatically transmit data to a remote diagnostic system for diagnosis of problems at the client system due to concerns over sending confidential and personal information and concerns about legal restrictions on transmitting data. Described embodiments provide improvements to computer technology for transmitting client data, such as contents of memory dumps, to a remote diagnostic system that provides the client control over the data transmitted. With the described embodiments, the data, such as a memory dump of blocks of data in a memory of the client system that are requested by the diagnostic system, is displayed to provide the user of the client system the opportunity to review the collected data and approve transmittal to the diagnostic system, reject sending the data or allow the user at the client system to redact certain of the gathered data to transmit redacted data to the diagnostic system to process.

In further embodiments, the diagnostic system may process received data from the client system and determine further data that is needed, and allow the client system to again review the further requested data before transmitting the data to the diagnostic system. In this way, the client is incentivized to interact with the diagnostic system to participate in remote computer diagnosis because the client can be assured the data they are sending does not disclose important confidential, sensitive and personal information that is not appropriate to transmit outside of the client system to a third party.

FIG. 1 illustrates an embodiment of adiagnostic system100 that troubleshoots technical problems in aclient system102 over anetwork104. Although oneclient system102 is shown, there may bemultiple client systems102 that interact with thediagnostic system100 to diagnose and troubleshoot technical problems in the plurality ofclient systems102, including software and/or hardware problems. The diagnostic system includes aprocessor106 comprising one or more processor cores that execute programs loaded in amemory108, including adiagnostic program110 to manage diagnostic operations, and one or morediagnostic workflow programs112. Thediagnostic program110 may generate adiagnostic user interface114 to display requested data returned by theclient system102 for diagnostic purposes, including data from amemory dump130 of data blocks in amemory116 at theclient system102 and other client data.

Thediagnostic program110 may instantiate aserver socket118 to maintain communication with aclient socket120 in oneclient system102 over the network. Thediagnostic system100 further maintains clientdiagnostic tools122 to distribute toclient systems102 requesting diagnostic services. There may be different clientdiagnostic tools122 to distribute toclient systems102 for different types of problems and applications to diagnose and troubleshoot.

Adiagnostic workflow program112 includes program logic implementing a diagnostic workflow comprising conditional branches of program code having conditional paths to traverse according to requested data received from theclient system102. Different branches of the diagnostic workflow may request different data from theclient system102, such as different blocks of data from aclient system memory116 in amemory dump130. This requested data returned to thediagnostic system100 is used by thediagnostic workflow program112 to determine further conditional branches to traverse until a solution or other state is reached in the diagnostic workflow. There may be differentdiagnostic workflow programs112 for different types of technical andapplication126 problems to diagnose.

Theclient system102 includes aprocessor124 comprising one or more processor cores that execute programs loaded in theclient memory116, including a clientdiagnostic tool122, which may be distributed by thediagnostic system100, and one ormore application programs126, which may be the subject of the troubleshooting and diagnostic operations. The clientdiagnostic tool122 may generate aclient user interface128 to display data accessed from theclient system102 used for diagnostic purposes, including data from amemory dump130 of thememory116 and/or other client data. Described embodiments discuss the client retrievingmemory dump data130. In further embodiments, other data may be gathered at theclient system102 from locations other than amemory116 dump, such as specific requested information gathered using an application program interface (API). Thediagnostic program110 may further instantiate aclient socket120 to maintain communication with theserver socket118 to facilitate communication with thediagnostic system100 over thenetwork104.

Thenetwork104 may comprise a network such as a Storage Area Network (SAN), Local Area Network (LAN), Intranet, the Internet, Wide Area Network (WAN), peer-to-peer network, wireless network, arbitrated loop network, etc.

Thememories108,116 may comprise a suitable volatile or non-volatile memory for storing programs to execute and information used by the programs to execute.

Theprograms110,112,114,118,120,122,126,128 may comprise program code loaded into memory and executed by a processor. Alternatively, some or all of the functions may be implemented in hardware devices, such as in Application Specific Integrated Circuits (ASICs) or executed by separate dedicated processors.

Although a certain number of instances of elements, such as thediagnostic system100 andclient system102 are shown, there may be any number of these elements.

FIGS. 2a, 3a, 4a, 5a, and 6aillustrate an embodiment of pages rendered in theclient user interface128 during operation of the clientdiagnostic tool122.FIGS. 2b, 3b, 4b, 5b, and 6b, illustrate an embodiment of pages rendered in thediagnostic user interface114 during operation of thediagnostic program110 at thediagnostic system100.

FIG. 2aprovides apage200 rendered in theclient user interface128 when a user at theclient system102 first invokes the clientdiagnostic tool122 to start the diagnosis process. The client user may select in the page200 averification mode control202 to indicate to allow the user to review data gathered from theclient system102 before sending to thediagnostic system100 or anautomatic mode control204 to automatically transfer data gathered from theclient system102 at the request of thediagnostic program110 without user review.

FIG. 2bprovides an example of apage210 rendered at thediagnostic user interface114 at thediagnostic system100 in response to theclient102 user initiating the diagnostic session throughpage200 to provide information on the user initiating a diagnostic session at theclient system102 and the selected data review mode, verification or automatic.

FIG. 3aprovides an example of apage300 rendered at theclient user interface128 to showdata302 from amemory dump130 at an address range in thememory116 requested by thediagnostic program110. Thepage300 displays anapprove button304, or graphical control element, that when selected transmits thedata302 to thediagnostic system100 without any changes; arejection button306 that when selected causes the return of a message to thediagnostic system100 that the user at theclient system102 declined to transmit any of the requested data; and aredact button308 that when selected allows the user at theclient system102 to selectdata302 in thepage300 to redact or remove, such as if the data is confidential, personal or sensitive information in a human readable form or extended binary-coded decimal interchange code (EBCDIC) the user is not comfortable sharing.

FIG. 3billustrates an example of apage310 thediagnostic user interface114 displays to show thedata302 formatted asdata312 when the user selected the approvebutton304 to send all thedata302 unredacted to thediagnostic system100.

FIG. 4aprovides apage400 rendered at theclient user interface128 to showdata402 from amemory dump130 at an address range in thememory116 requested by thediagnostic program110. In theclient user interface128, the user has selected thereject button404 to decline to send any of the gathereddata402 to thediagnostic system100.

FIG. 4billustrates an example of apage410 thediagnostic user interface114 displays to notify the user of thediagnostic system100 that the user selected reject404 to not send any of the requested data.

FIG. 5aprovides an example of apage500 rendered at theclient user interface128 to showdata502 from amemory dump130 at an address range in thememory116 requested by thediagnostic program110. In thepage500 rendered at theclient user interface128, the user has highlightedcertain data fields504,506 to redact and selected theredact button508 to redact the selecteddata fields504,506 from the data to send to thediagnostic system100.

FIG. 5billustrates an example of apage510 thediagnostic user interface114 displays to display the redacteddata512 from theclient system102.

FIG. 6aprovides an example of apage600 rendered at theclient user interface128 to showdata602,604 from two different memory dumps that are automatically sent to thediagnostic system100 in automatic mode without client user review.

FIG. 6billustrates an example of apage610 thediagnostic user interface114displays having panels612,614 of the client sentdata602,604, respectively, automatically sent from theclient system102.

FIG. 7 illustrates an embodiment of operations performed by the clientdiagnostic tool122, which is initially invoked on theclient system102 to troubleshoot a problem withapplications126 and/or hardware at theclient system102. The operations ofFIG. 7 may be invoked when theclient system102 downloads and executes the clientdiagnostic tool122 to initiate a diagnostic session. Upon receiving and executing (at block700) the clientdiagnostic tool122, the clientdiagnostic tool122 executes (at block702) a command to perform a memory dump for specified blocks of data inmemory116 to copy the specified blocks ofmemory116 to thememory dump data130. The specified blocks may be encoded in thetool122 for the first memory dump to perform to start the diagnostic process. The memory dump may be performed by an Inter Process Communication System (IPCS) command in batch mode to dump the specified blocks ofmemory116 to auser dump directory130. The data in thememory dump130 is rendered (at block704) in theclient user interface128, such as the display ofdata302,402,502,602,606 in theclient user interface128 shown inFIGS. 3a, 4a, 5a,6a.

Upon receiving (at block706) user selection of the approve button304 (FIG. 3a), the clientdiagnostic tool122 transmits (at block708) thememory dump data130 unchanged via theclient120 andserver118 sockets to thediagnostic system100.

Upon receiving (at block710) user selection ofdata504,506 in the display data502 (FIG. 5a) to redact, the clientdiagnostic tool122 displays (at block712) the user selecteddata504,506 as highlighted. Upon receiving (at block714) user selection of theredact button508, the selecteddata504,506 is replaced (at block716) with a redact code, such as a character, e.g., “R”. The redactedmemory dump130 data is transmitted (at block718) via theclient120 andserver118 sockets to thediagnostic system100. In one embodiment, the problem being troubleshooted is a problem with a database at theclient system102, then the gatheredmemory dump130 may include a database index with client data. In such case, the user may redact the client data and return to thediagnostic system100 the index structure for thediagnostic workflow program112 to diagnose and repair.

Upon receiving (at block720) user selection of the reject button404 (FIG. 4a), the clientdiagnostic tool122 returns (at block722) a rejection message to thediagnostic system100 via theclient120 andserver118 sockets without any of the displayedmemory dump data402.

With the embodiment of operations ofFIG. 7, the client is allowed to review data before returning the requested data to thediagnostic system100 to allow the user to reject all the data to send or to redact sensitive or personal information the client user notices in the displayed data. This allows the client to control the data sent to the diagnostic system. In most cases, the data rendered from thememory dump130 will include counters, pointers and other program control data that is incomprehensible to the user and will likely be approved by the user to send. However, there may be EBCDIC data the client is not comfortable sharing. In such case, the client can redact the data to prevent it from being shared with thediagnostic system100. This option to redact or reject sending data will encourage the client to have their system diagnosed through thediagnostic tool122 because the client will have control over the data that is sent to use for the diagnosis.

FIG. 8 illustrates an embodiment of operations performed by thediagnostic program110 anddiagnostic workflow program112 for the problem being diagnosed, to process data or a message received from the clientdiagnostic tool122 when processing a client user approve, redact or reject command with respect to data displayed in theclient user interface128. Thediagnostic program110 receives (at block800) a communication from theclient socket120 via theserver socket118. If (at block802) the client sent all the requestedmemory dump130 blocks, such as after selecting the approve button304 (FIG. 3a), then thediagnostic program110 formats (at block804) the received data based on a format and size of the received data using conditional formatting logic to determine a format used to produce formatted data understandable to a user of thediagnostic system100 to render in thediagnostic user interface114, such as shown inpage310 inFIG. 3b. The formatting may provide information to describe the dump data that is useful for debugging and diagnosis by the diagnostic technician operating thediagnostic system100.

Thediagnostic workflow program112 is invoked to process (at block806) the received memory dump blocks130 to determine a next step in the diagnostic workflow according to the conditional logic of the workflow. If (at block808) the next step in the diagnostic workflow is a solution to the technical problem being diagnosed, then thediagnostic workflow program112 determines (at block810) a solution or message from the determined next step in the diagnostic workflow and returns the solution/message to theclient system102 client via theserver118 andclient120 sockets. The solution may comprise a program fix to execute on theclient system102 to fix the problem being diagnosed or instructions of changes to make at theclient system102.

If (at block808) the determined next step in the diagnostic workflow is a request for additional client data, then thediagnostic workflow program112 determines (at block812) from the next step in the diagnostic workflow a next section (offset) ofclient memory116 to retrieve from afurther memory dump130. Thediagnostic program110 ordiagnostic workflow program112 may transmit (at block814) the request for determined next section of memory, such as an address of a range of blocks, to the client system via theclient socket120 to cause the clientdiagnostic tool122 to start processing from block702-722 inFIG. 7 to retrieve the requested next blocks from a memory dump to process in thediagnostic workflow program112.

If (at block816) the client sent redacted data, then thediagnostic program110 determines (at block818) whether theclient system102 provided sufficient unredacted data to allow thediagnostic workflow program112 to determine next step in diagnostic workflow. In one embodiment, thediagnostic program110 may call thediagnostic workflow program112 to process the unredacted data to determine whether the result of the processing is a next step in the diagnostic workflow or an error. In an alternative embodiment, thediagnostic program110 may apply rules to determine whether the unredacted data is sufficient to allow for continued processing by thediagnostic workflow program112. If (at block818) the unredacted data is sufficient for thediagnostic workflow program112 to continue, then control proceeds to block806 to determine the next step or operation in the diagnostic workflow. If (at block818) the unredacted data is not sufficient or incomplete to continue diagnostic processing, then thediagnostic program110 determines (at block820) those parts of the redacted data needed to determine the next step in the diagnostic workflow and returns (at block822) a message to the client to provide the needed parts of the redacted data or initiate a contact window with the client to provide direct contact with the client user, via phone, email or instant messages, to assist with diagnosis.

If (at block824) the client sent a message rejecting sending any data, then thediagnostic program110 may send (at block826) a message to the client with contact information for in-person support.

With the embodiment of operations ofFIG. 8, the diagnostic system may use the data dump returned by the client to continue the diagnostic processing to determine a next step in the diagnostic process. If further data is needed to continue with the diagnostic, then thediagnostic program110 will send a request for the further needed data, which may require theclient system102 to perform another memory dump to return to thediagnostic system100. Further, thediagnostic program110 may determine if sent redacted data is sufficient to continue with the diagnostic workflow processing. In this way, the described embodiments allow the user to control the data sent to thediagnostic system100 to use to diagnose the client system and at the same time determine whether sent redacted data is sufficient to continue with processing.

The present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

The computational components ofFIG. 1, including thediagnostic system100 and theclient system102 may be implemented in one or more computer systems, such as thecomputer system902 shown inFIG. 9. Computer system/server902 may be described in the general context of computer system executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computer system/server902 may be practiced in distributed cloud computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

As shown inFIG. 9, the computer system/server902 is shown in the form of a general-purpose computing device. The components of computer system/server902 may include, but are not limited to, one or more processors orprocessing units904, asystem memory906, and abus908 that couples various system components includingsystem memory906 toprocessor904.Bus908 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnects (PCI) bus.

Computer system/server902 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server902, and it includes both volatile and non-volatile media, removable and non-removable media.

System memory906 can include computer system readable media in the form of volatile memory, such as random access memory (RAM)910 and/orcache memory912. Computer system/server902 may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only,storage system913 can be provided for reading from and writing to a non-removable, non-volatile magnetic media (not shown and typically called a “hard drive”). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such instances, each can be connected tobus908 by one or more data media interfaces. As will be further depicted and described below,memory906 may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.

Program/utility914, having a set (at least one) ofprogram modules916, may be stored inmemory906 by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. The components of thecomputer902 may be implemented asprogram modules916 which generally carry out the functions and/or methodologies of embodiments of the invention as described herein. The systems ofFIG. 1 may be implemented in one ormore computer systems902, where if they are implemented inmultiple computer systems902, then the computer systems may communicate over a network.

Computer system/server902 may also communicate with one or moreexternal devices918 such as a keyboard, a pointing device, adisplay920, etc.; one or more devices that enable a user to interact with computer system/server902; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server902 to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interfaces922. Still yet, computer system/server902 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) vianetwork adapter924. As depicted,network adapter924 communicates with the other components of computer system/server902 viabus908. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with computer system/server902. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

The terms “an embodiment”, “embodiment”, “embodiments”, “the embodiment”, “the embodiments”, “one or more embodiments”, “some embodiments”, and “one embodiment” mean “one or more (but not all) embodiments of the present invention(s)” unless expressly specified otherwise.

The terms “including”, “comprising”, “having” and variations thereof mean “including but not limited to”, unless expressly specified otherwise.

The enumerated listing of items does not imply that any or all of the items are mutually exclusive, unless expressly specified otherwise.

The terms “a”, “an” and “the” mean “one or more”, unless expressly specified otherwise.

Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more intermediaries.

A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments of the present invention.

When a single device or article is described herein, it will be readily apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be readily apparent that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the present invention need not include the device itself.

The foregoing description of various embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto. The above specification, examples and data provide a complete description of the manufacture and use of the composition of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims herein after appended.

Claims (20)

What is claimed is:

1. A computer program product for providing diagnostic services to a client system over a network, wherein the computer program product comprises a computer readable storage medium having computer readable program instructions executed by a diagnostic system to perform operations, the operations comprising:

transmitting a client program to the client system including a command to retrieve a block of data, wherein the client program is executed to perform operations at the client system comprising:

retrieving the block of data indicated in the command;

displaying data in the block of data in a client user interface at the client system; and

transmitting the data displayed in the client user interface to the diagnostic system in response to user indication to transmit the data displayed in the client user interface;

receiving, from the client program, data rendered in the client user interface; and

processing the received data to determine a next operation in a diagnostic workflow program with respect to the client system.

2. The computer program product ofclaim 1, wherein the command comprises a memory dump command to create a memory dump of blocks of data in a memory of the client system, wherein the block of data to retrieve comprises an offset in the memory dump from which the block of data is extracted, and wherein the block of data to retrieve includes at least one of pointers, control block, counters, understandable words in a language.

3. The computer program product ofclaim 1, wherein the client program renders in the client user interface a redact graphical control element configured to enable a user of the client system to select portions of the block of data displayed in the client user interface to redact, wherein user selection of the redact graphical control element redacts the selected portions of the block of data from the data transmitted to the diagnostic system.

4. The computer program product ofclaim 3, wherein the operations further comprise:

rendering in a diagnostic user interface executed in the diagnostic system the received data from the client program with the selected portions of the block of data redacted as indicated as redacted.

5. The computer program product ofclaim 3, wherein the operations further comprise:

determining whether the redacted selected portions of the block of data are needed to continue processing in the diagnostic workflow program;

determining parts of redacted data needed to determine a next operation in the diagnostic workflow program; and

notifying at least one of a user at the client system or a diagnostic technician using the diagnostic workflow program of the determined parts of redacted data needed to determine the next operation in the diagnostic workflow program.

6. The computer program product ofclaim 3, wherein the selected portions of the block of data to redact comprise database data and wherein data returned to the diagnostic system includes an index structure for the diagnostic workflow program to diagnose and repair.

7. The computer program product ofclaim 3, wherein the client program renders in the client user interface an approve graphical control element that when selected by the user transmits all of the block of data displayed in the client user interface to the diagnostic system and a reject graphical control element to return none of the data rendered in the client user interface and return indication of rejecting returning any of the data rendered in the client user interface.

8. The computer program product ofclaim 1, wherein the determining the next operation comprises:

processing the received data to select a conditional processing branch in the diagnostic workflow program, wherein different branches in the diagnostic workflow program requests different blocks of data from the client system to retrieve to use to continue processing in the diagnostic workflow program along a selected branch.

9. The computer program product ofclaim 1, wherein the operations further comprise:

processing the received data and a format and size of the received data with conditional formatting logic to determine a format in which to render the received data to be understandable to a user of the diagnostic system;

formatting the received data with the determined format to produce formatted data; and

rendering in a diagnostic user interface executed in the diagnostic system the formatted data.

10. A system for providing diagnostic services to a client system over a network, comprising:

a processor; and

a computer readable storage medium having computer readable program instructions executed by the processor to perform operations, the operations comprising:

transmitting a client program to the client system including a command to retrieve a block of data, wherein the client program is executed to perform operations at the client system comprising:

retrieving the block of data indicated in the command;

displaying data in the block of data in a client user interface at the client system; and

transmitting the data displayed in the client user interface to the system in response to user indication to transmit the data displayed in the client user interface;

receiving, from the client program, data rendered in the client user interface; and

processing the received data to determine a next operation in a diagnostic workflow program with respect to the client system.

11. The system ofclaim 10, wherein the client program renders in the client user interface a redact graphical control element configured to enable a user of the client system to select portions of the block of data displayed in the client user interface to redact, wherein user selection of the redact graphical control element redacts the selected portions of the block of data from the data transmitted to the system.

12. The system ofclaim 11, wherein the operations further comprise:

rendering in a diagnostic user interface executed in the system the received data from the client program with the selected portions of the block of data redacted as indicated as redacted.

13. The system ofclaim 11, wherein the operations further comprise:

determining whether the redacted selected portions of the block of data are needed to continue processing in the diagnostic workflow program;

determining parts of redacted data needed to determine a next operation in the diagnostic workflow program; and

notifying at least one of a user at the client system or a diagnostic technician using the diagnostic workflow program of the determined parts of redacted data needed to determine the next operation in the diagnostic workflow program.

14. The system ofclaim 10, wherein the determining the next operation comprises:

processing the received data to select a conditional processing branch in the diagnostic workflow program, wherein different branches in the diagnostic workflow program requests different blocks of data from the client system to retrieve to use to continue processing in the diagnostic workflow program along a selected branch.

15. The system ofclaim 10, wherein the operations further comprise:

processing the received data and a format and size of the received data with conditional formatting logic to determine a format in which to render the received data to be understandable to a user of the system;

formatting the received data with the determined format to produce formatted data; and

rendering in a diagnostic user interface executed in the system the formatted data.

16. A method implemented in a diagnostic system for providing diagnostic services to a client system over a network, comprising:

transmitting a client program to the client system including a command to retrieve a block of data, wherein the client program is executed to perform operations at the client system comprising:

retrieving the block of data indicated in the command;

displaying data in the block of data in a client user interface at the client system; and

transmitting the data displayed in the client user interface to the diagnostic system in response to user indication to transmit the data displayed in the client user interface;

receiving, from the client program, data rendered in the client user interface; and

processing the received data to determine a next operation in a diagnostic workflow program with respect to the client system.

17. The method ofclaim 16, wherein the client program renders in the client user interface a redact graphical control element configured to enable a user of the client system to select portions of the block of data displayed in the client user interface to redact, wherein user selection of the redact graphical control element redacts the selected portions of the block of data from the data transmitted to the diagnostic system.

18. The method ofclaim 17, further comprising:

determining whether the redacted selected portions of the block of data are needed to continue processing in the diagnostic workflow program;

determining parts of redacted data needed to determine a next operation in the diagnostic workflow program; and

notifying at least one of a user at the client system or a diagnostic technician using the diagnostic workflow program of the determined parts of redacted data needed to determine the next operation in the diagnostic workflow program.

19. The method ofclaim 16, wherein the determining the next operation comprises:

processing the received data to select a conditional processing branch in the diagnostic workflow program, wherein different branches in the diagnostic workflow program requests different blocks of data from the client system to retrieve to use to continue processing in the diagnostic workflow program along a selected branch.

20. The method ofclaim 16, further comprising:

processing the received data and a format and size of the received data with conditional formatting logic to determine a format in which to render the received data to be understandable to a user of the diagnostic system;

formatting the received data with the determined format to produce formatted data; and

rendering in a diagnostic user interface executed in the diagnostic system the formatted data.

Images