How to run an executable from within a c program?

C++ program

• This program should be pretty straight forward for the average programming expert. Please keep the programs as simple as possible while keeping with the specifications. I will need two different working versions of both parts. Part I should be able to run individually from Part II. I am not able to write these programs myself because of school, work, and kids. (I've pretty much fallen behind with everything!) I will check several times a day to check if you have any comments or questions. These programs are to be used in a Unix environment. It is extremely important that these programs are completed by April 12, 2003. This problem is not nearly as long or difficult as it may look. I cannot express how much I appreciate your help.(Except for in terms of dollars, I guess!) Thank you Part I: This part looks at the way information is stored in fields and records. The program will read a source file from a real life application, extract the fields and print the result. Specification of the source data We will extracting data from the site http://www.ntsb.gov/ntsb/query.asp. To get data, click on Database Query. Then enter some information into the form. For example, set the start date to 1/1/03 and set the state to California. Then click on Submit Query. When you get the search results, select the data (not header fields, just the fields shown with a white background) and copy and paste into a text editor. Since the search results give only a few records per page, you should do this more than once. It is important that you follow directions because when I test your programs, I will be using a file generated in this manner. I will not be using the same file as you. Specification of the Problem Your code should read in the input data, which as you will see has variable length fields. Your code should extract each field individually and write it to the screen, and to disk. The fields written should be fixed length fields. Thus it may be necessary to truncate some fields. The primary key is the Airplane Registration Number. We will assume there are no duplicates. (Any duplicates should be ignored in future labs.) This is a fixed length (6 character) field. At the same time you should construct a data record (structure) consisting of fixed length fields. The record should be written to a file called datafile.txt. The records should be written one record at a time (not field by field). The required format for output to the screen is Sequence number (RRN) Primary key All other fields in the record in the same order as in the data file (except for the primary key which has been moved to the front). The output for one record should fit on one line. Fields should be separated by '|' character. The format for the output file should be similar, but omit the RRN and '|'. Note that in some cases the last two fields are omitted (Type of Air Carrier Operation, Carrier Name). This should not cause a problem. (Hint: I believe that the only possible values for Report Status are: "Prel", "Fact", "Final".) Your executable file should be named showdata. There should be no restriction on the number of records processed. Specification of the user interface The file name should be taken from the command line. The command to produce the correct result should be showdata rawdata.txt, if the input file is named rawdata.txt. Implementation constraints Extracting data from the input text file— no required structure. However, keep in mind the structure of the input data file described above. You must follow this specification, because that is how the file used to test your program will be generated. You may not change the input format. Your input should be done in binary ("raw") mode. Keep in mind that this will be the front end of the code you will write during the rest of the semester. Design for re-use. The fields should be output as fixed length fields and the beginning and end of the field should be clearly shown as described above. The State should be considered as a separate field from the rest of the Location. If you develop your code in Windows, you should allow for either Windows or UNIX type text files. The difference is in how the end of a line is represented. Windows uses 0x0A0D (or is it 0x0D0A ?), UNIX just 0x0D. Incorrectly named programs or programs that do not take command line arguments will not be accepted Part II:We are going to build an indexed data storage and retrieval system for the data used in Lab 2. This will include a batch load function (from a text file), an index display function, an interactive search feature and delete. We will use an Avail list for deleted records. The easiest way to implement these functions is to use one program for each function. The programs should know the name of the file structure. The only thing that needs to be passed to the program on the shell command line is the argument for the command: $ load data.txt /* create the file structure */ $ list /* outputs a list of all records */ $ search N1079U /* program displays remaining args */ $ add N1079U /* program prompts for remaining args */ $ delete N1079U /* program displays, waits for yes */ Give some thought to sharing code among the six programs. Other commands may also occur to you during implementation and verification. Structure your code so that the index functions are separate from the user interface and can easily be replaced! Specification of the problem A program load should translate a text file containing product records to a file structure of your design. You should have two files, a database file, a primary index. You have already solved the problem of creating the data file in Lab 2. In Lab 3, we add the index function. (For Lab 4, your index file will change but you should be able to use the same database file structure.) The source file format is the same as for Lab 2. Records with missing primary key should be omitted. A program search should allow the user to find a record with a given primary key and display the record's content. A program list should display all records in order by the primary key. The display should show the entire primary key, followed by the other fields, which may be truncated. Each work should fit on a single line, and there should be no blank lines in between. If this format is not followed, the project will not be accepted. A program add should allow the user to add a new record to the file structure. This program should prompt for the other fields. Since we are going to add records, your index should have more space allocated to it than just what is necessary for the source text records. The function should check for duplicate keys and output an error message if encountered. A program delete should allow the user to delete a record with a user supplied primary key. The delete function should place the deleted data record on an Avail list. The Avail list should be kept in the deleted records in the data file. The head pointer for the Avail list should be kept in the header of the index file. Subsequent adds should re-use deleted data records for new data. (Use your hex dump program from Lab 1 to verify that this is so.) Specification of the source data You should use the same source data file as in Lab 2. Specification of the user interface Each command that may be performed on the file structure should be implemented in a separate program. Each program should know the name of the file containing the records in the file structure. The key field should be taken from the command line. Each program should open the file structure, perform a single operation, and close the file structure. Implementation constraints Each program should perform the action required and report the results to the standard output. Transfers to or from the database file should be implemented only with open(...), read(...), write(...) and close(...) functions. (If using C++ I/O, this corresponds to the unformatted I/O functions sgetn and sputn.) There are no constraints on how the index file is read or written. The file structure transfer block size should be the size of four records, for transfers to and from the database file. The file size must be a multiple of this value. Only blocks corresponding to RRNs which are a multiple of 4 should be accessed. The functions that read and write the database should print out the block accessed and also the record accessed within the block ONLY for functions that access only a single record. (i.e., not for the list function.) Constraints on accessing the data file do not apply to the load function since the constraints were not in effect for Lab 2. The code you developed for Lab 2 may be directly reused. The search for an item should be performed using a binary search in a sorted index. The binary search function should print out the locations examined by the search. The index file should be created by the load function and should be stored in order by primary key. You may select your own format for storing the index file. Additions and deletions should be implemented by moving index entries appropriately and storing a sorted index. The avail list should be kept in the deleted data records. The key should be set to a particular value, and the next field in the data record should contain the RRN of the next list item. The remainder of the data field should be set to blanks. The head of the avail list should be kept in the header record of the index file. Code may be written in either C or C++. Suggested structure and required output Reading and writing data records. The block size is sufficient for 4 records. Only blocks corresponding to RRNs which are a multiple of 4 should be accessed, and the appropriate record should then be extracted. For read, your blockread function is given an RRN and returns a pointer to the appropriate record in the buffer. For blockwrite, the function is given an RRN and a pointer to a record which is to be copied into the buffer. Every write also involves a read, since three of the four records in the block remain unchanged. The functions should print a brief descriptive message of the operation, including block numbers (RRN of the start of the block and RRN of the accessed record) whenever a block is read or written, ONLY for functions that access only a single record. (i.e., not for the list function.) Binary search in index Given a key, the function returns two values, a location in the index and a Boolean value indicating whether the key was found in the index. The binary search should print each index location accessed (on one line, please!). Insert into index Since the binary search has already found the correct location, this value can be passed to the indexinsert function along with a key and RRN. Following entries in the index are moved down to make room for the new entry. The function should print the range of index entries which are being moved (first and last only). Delete from index Since the binary search has already found the correct location, this value can be passed to the indexdelete function. Following entries in the index are moved back to remove the index entry. The function should print the range of index entries which are being moved (first and last only). I suggest that common functions should be placed in an include file. Testing Please verify that all functions are working . Structure of the index file (use hexdmp) Structure of the data file (use hexdmp) Correct functioning of all operations. Diagnostic print statements as specified must be included. Placing and removing records to/from the Avail list (use hexdmp to verify). Here is sample data for a Unix format: Prel 2/28/03 Deer Valley, AZ Creitz, Robert D RV-3 N87BC Nonfatal Part 91: General Aviation Prel 2/28/03 COLCHANI, Bolivia Cessna 411 CP-1885 Fatal(1) NSCH Non-U.S., Commercial Taxi Aereo "Colibri" Fact 1/17/03 Quito, Ecuador Fokker F28 HC-BMD Nonfatal SCHD Non-U.S., Commercial Transportes Aereos Militares del Ecuador (D.B.A. TAME) Prel 1/17/03 McMurdo Station, Antarctica Bell 212 N1079U Nonfatal Public Use Prel 1/17/03 Yacuiba, Bolivia British Aerospace Jetstream 31 CP-2404 Nonfatal NSCH Non-U.S., Commercial Servicio Aereo Vargas Espana (D.B.A. SAVE) Prel 1/16/03 Venice, LA Bell 206L-1 N3194P Fatal(1) NSCH Part 135: Air Taxi & Commuter Air Logistics LLC Prel 1/16/03 Indianapolis, IN Boeing 737-83N N303TZ Incident SCHD Part 121: Air Carrier AMERICAN TRANS AIR INC Prel 1/16/03 Midway, UT Yakovlev YAK 52 N2256J Fatal(2) Part 91: General Aviation Prel 1/16/03 SALINAS, CA Cessna 152 N25562 Nonfatal Part 91: General Aviation Prel 1/15/03 BRAWLEY, CA Cessna A188A N5638J Nonfatal Part 137: Agricultural Prel 1/15/03 , PO Dassault Aviation Falcon 900EX N11WM Nonfatal Part 91: General Aviation Fact 1/15/03 Stansted, United Kingdom McDonnell Douglas MD-11 N583FE Nonfatal SCHD Non-U.S., Commercial FEDERAL EXPRESS CORP Fact 1/8/03 Diyarbakir, Turkey British Aerospace RJ-100 TC-THG Fatal(75) SCHD Unknown Prel 1/8/03 Charlotte, NC Beech 1900 N233YV Fatal(21) SCHD Part 121: Air Carrier AIR MIDWEST INC (D.B.A. US Airways Express) Prel 1/1/03 Milford, UT Aircraft Mfg & Dev. Co. (AMD) CH2000 N8500R Nonfatal Part 91: General Aviation Prel 1/1/03 Lansing, IL Air Command Commander Elite Fatal(1) Part 91: General Aviation Fact 1/3/03 Alton, IL Cessna 182S N2724R Nonfatal Part 91: General Aviation Prel 1/3/03 Santo Domingo, Dominican Republic Beech BE-60 HI-774CT Fatal(1) Non-U.S., Non-Commercial Prel 1/2/03 New Port Richey, FL Hughes OH-6 N317LC Nonfatal Public Use Prel 2/28/03 Captiva Island, FL Beech 36 N41VK Fatal(1) Part 91: General Aviation Fact 2/28/03 Columbus, OH Cessna 152 N170SU Nonfatal Part 91: General Aviation Prel 2/27/03 Renfrew, PA Cessna 182G N3404S Fatal(1) Part 91: General Aviation Fact 2/27/03 Jamaica, NY Aerospatiale Concorde F-BVFA Nonfatal SCHD Part 129: Foreign Air France Airlines Prel 2/26/03 Blue Bell, PA Piper PA-44-180 N711AV Nonfatal Part 91: General Aviation Prel 2/25/03 Williamson, NY Cessna 150J N51126 Nonfatal Part 91: General Aviation Prel 2/25/03 Osteen, FL Cessna 172P N97890 Fatal(1) Part 91: General Aviation Prel 2/25/03 YOUNTVILLE, CA FIREFLY 11B N1501H Fatal(1) Part 91: General Aviation

• Answer:

  Hi bobty-ga, Since you are satisfied with the solutions for Part I and Part II of your question, I am posting them as the answer. You can download the final C source code from: [ http://www31.brinkster.com/tanm/GA/bobty-ga.zip ] The code for Part I is the same one you tested earlier. The code for Part II has been somewhat cleaned up and is now better commented. No implementation changes were made, so it should work exactly as it did before. Although I am unable to take up your new question (see my previous posting), I am sure you will have no problems in finding other GA Researchers to take up the challenge. While the functions in the 'index.h' file for Part II will need to be implemented from scratch, the remaining code for Part II should require only minor modifications. If you require any more information, or need any changes to be made to the code, just ask for a clarification. Regards, Theta-ga :-)