MichaelRed had a couple of really good points in his post, so let's start there. I made some assumptions in my first post that may or may not have been correct. First, I assumed that you did not have access to the basic code or the database on your system. If you do indeed have that access, that is probably a better place to start.
Second, I assumed that you did not have root access to your system. If you do have root access, the idea of setting up a printer to dump your reports directly to a file is certainly worth investigation. I haven't the first clue as to how to set you up to print to file in AIX, but if you ask in forum52 (AIX), I'm sure someone over there can tell you how to set up the printer and how to get the files from the AIX box to a machine that you can work with.
Now to the screen scraper . . . First, strongm . . . are you referring to your post in thread222-302107 ? If so, that is a fine example of how to scrape the screen to a bitmap, but a bitmap is of little value in this case. What is needed is the actual text that is on the screen, not an image of the screen. If I hit the wrong thread, please post a link, as I have not been able to find anything else related. I have found several other posts in this and other forums related to screen scraping, but all of them focus on capturing text or images from an existing application screen. In my opinion, that is not the best way to proceed with this project.
Most commercial terminal emulator/screen scrapers work by capturing the data from within the terminal emulation program itself. It seems to me that this is more efficient and should provide for easier adaptation to the different screens you will have to capture data from.
If you elect to try that option, the first step is to write a basic terminal emulator, keeping in mind that you need to store the data in such a way that you can easily retrieve the text that is displayed on a specific portion of the screen. You need to establish a connection to the AIX machine, either using the mscomm control for a serial port connection or the winsock control for a network connection. The serial port option is much easier to implement because you can set up a serial terminal to run parallel to the machine your program is running on and watch what is supposed to be happening in real time.
Once the connection is established, I would set up an array of fixed length strings, with the length of the strings equal to the width of your terminal (probably 80) and the number of elements equal to the number of lines (probably 25). Each element of the array will need to be initialized by copying a string of spaces to it. If you simply empty the string array in the initialization phase, you will have problems with the data extraction.
The data that comes your connection will have control codes embedded that indicate where the text that follows is to be placed, how it is to be formatted, and sometimes commands to beep or pass data to an attached printer (or other device for that matter). The formatting codes can be ignored, as it doesn't really matter if text is underlined, bold, reverse, etc. The port pass through can cause problems if it is used, so if your application does pass through printing or device control, you will have to trap and discard it. The placement codes will have to be held, and you will need to place the text that follows in the appropriate position in the correct element of the array. The control codes that are used vary from terminal to terminal, so you will need to know what model terminal you are emulating. From there, the termcap file included with Linux will provide a list of the control codes used for the terminal so you know what you are trapping.
When the screen is filled, the data you need can be extracted from the array and stored in a database. As you will be gathering different types of data from several different screens (again, I am assuming), I would create a procedure to open a text file with a definition of what data you wish to extract, and use that information to do the actual extraction instead of hard coding the extraction parameters. This will allow for you to write a different configuration file for each screen instead of changing the code for each screen.
After the data is extracted, repeat the initialization routine and send the appropriate command to the server to proceed to the next record. This project will take some coding, but it really is not as bad as it sounds. Just some serious time.
Another thought that comes to mind. . . you mentioned that you are preparing to switch software. Have you selected a new software vendor? If so, have you asked them about the data conversion? Often times in a situation like that the new software vendor will handle the data conversion. There is generally a fee involved, but it is usually reasonable considering the effort involved.
Wow! Another one of those lengthy posts. Hope it is of some help, and of course I'll be watching.
Happy New Year
John
