Create Table Like, But Different. By Raymond Everhart

Transcription

1 reate Table Like, But Different By Raymond Everhart

2 reate Table Like, But Different Author: Raymond Everhart As iseries programmers explore the use of embedded SQL in their applications, the natural tendency is to try to understand new capabilities in terms of familiar techniques. The REATE TABLE LIKE statement is often equated to the REATE DUPLIATE OBJET (RTDUPOBJ) command. Unfortunately, that comparison can lead to frustration. But We ve Always Done it This Way! The usual application development cycle on the iseries calls for the coding of file specifications using DDS as the first step. The reason is because the file must exist before a program that uses that file can be compiled. The benefit of this approach is that the operating system lets you know if the file structure has changed since the program was created. For years, we have been using RTDUPOBJ to create a work file in the QTEMP library based on an existing file. This technique has become so common that we don t even think of doing it any other way. New physical or logical files can be created ad hoc from within programs, but it requires a call to the REATE PHSYIAL FILE (RTPF) or REATE LOGIAL FILE (RTLF) command. In most cases, if you re creating an ad hoc or work file, it s because the next job in the stream needs to use it. Because the next program in the job stream needs a copy of the file to be compiled, the easiest way to handle this situation is by creating a "work" file that always exists on the system. Level checking on files protects you from having files that are out of sync with programs, but it also imposes some design constraints. If a program uses embedded SQL only to access a certain file, no file level checking is performed against that file. This distinction becomes important if you are using a mixture of embedded SQL and native I/O methods in your programs. In the RPG example below, when this program is run, the ITEM file (see line 2) will be level checked, but the ustomer file (see line 7) will not be level checked. One thing to keep in mind is if you are using static SQL, as shown above, the SQL pre compiler requires that the file be found on the system before the program can be compiled. If you want to create and use a truly ad hoc file within your program, you must use a dynamic SQL statement. (I ll show you an example of that later.) Is it New and Improved or Just New? In OS400 v5r2, two new clauses were introduced to the REATE TABLE statement. The REATE TABLE AS statement allows you to create a table based on the fields you select in a sub query. You can optionally populate the new table with the records that match the selection criteria of the subquery. The REATE TABLE LIKE statement creates a new table with the same columns (fields) as the specified table. This new capability is similar to the REATE DUPLIATE OBJET (RTDUPOBJ) or OPY FILE (PYF) command, but there are some important differences.

3 A table created with the REATE TABLE LIKE statement may not have the same level ID as a file created with the OPY FILE or REATE DUPLIATE OBJET command. To understand the difference, you must remember that DB2 Universal Database on the iseries has a few more features than other DB2 UDB and/or SQL compliant databases. Two of the iseries features that are not supported by SQL are the creation of Multiple Member files and the ability to specify a format name on a file. When SQL is used to create a table on DB2 UDB for the iseries, the table name is used as the format name. At first glance, using the table name as the format name is just an annoyance to programmers who have to rename the format when the file is declared within their programs. However, when using the REATE TABLE LIKE Statement, this behavior poses a larger problem. If the original file was created using DDS, the format name will differ from the file name. So if you use REATE TABLE LIKE to make a copy of a file built using DDS, the format names will be different. Even though the old file and the new table have the same fields and layout, the file level IDs will be different because the format names will be different. In some cases, it may not be a big problem to use SQL to recreate the table and change the affected programs to rename the format name. Operations Navigator even has a facility that will analyze an existing file and create the correct SQL statement to create the table. However, making this change to some of your core application files and the hundreds of affected programs is unthinkable. The Simplest Rule The "Simplest" rule to follow in order to avoid level check problems is this: If the file was created with DDS use the OPY FILE or REATE DUPLIATE OBJET command. If the table was created with SQL use the REATE TABLE LIKE statement, the OPY FILE or REATE DUPLIATE OBJET command. If you are looking for a standardized method for creating "work" files from within your applications, consider this approach: To determine the method used to create the object, retrieve the Table Type from the SYSTABLES table. If the Table Type is a T then the table was created with SQL. reate your "work" file using the REATE TABLE LIKE statement. If the Table Type is an "P" then the file was created with DDS reate your "work" file using the OPY FILE or REATE DUPLIATE OBJET command. The program shown below is a simple framework for you to build your own tool: D cmdlen S 15 5 D command S 512 D filename S 10 D library S 10 D newfile S Like(filename) D newlibrary S Like(library) D sqlstmt S 512 D tabletype S 1 *Entry PList Parm filename Parm library Parm newfile Parm newlibrary * Retrieve the table type from the system table lear tabletype /Exec SQL + SELET + TABLE_TYPE into :tabletype + FROM systables + Where TABLE_SHEMA = :library and + TABLE_NAME = :filename /End Exec Select * Process tables & views created using SQL When tabletype = 'T' Eval sqlstmt = 'reate Table ' + %Trim(newlibrary)

4 + '/' + %Trim(newfile) + ' Like ' + %Trim(library) + '/' + %Trim(filename) /Exec SQL + Execute Immediate :sqlstmt /End Exec * Process physical and logical files created with DDS When tabletype = 'P' Eval command = 'RTDUPOBJ ' + 'OBJ(' + %Trim(FILENAME) + ') ' + 'FROMLIB(' + %Trim(LIBRARY) + ') ' + 'OBJTYPE(*FILE) ' + 'TOLIB(' + %Trim(NEWLIBRARY) + ') ' + 'NEWOBJ(' + %Trim(NEWFILE) + ') ' Eval cmdlen = %Len(%Trim(command)) all 'QMDEX' Parm command Parm cmdlen EndSL * End the Program Eval *INLR = *On Why Bother? You might be wondering why you should bother with REATE TABLE LIKE at all. The answer is at the beginning of this article: design constraints. SQL gives you an alternative, so you can do things you can t do easily using DDS and native I/O. Of course, one alternative is to use L or APIs to handle some of these functions. Just remember one thing, if you master DDS, RPG, and L you re still limited to the iseries or some RPG/obol emulator environment. If you master SQL you can work on any platform. How can I use REATE TABLE AS? The code snippets below show some of the capabilities of REATE TABLE AS. The example archives transactions from a table. The transactions are copied to a new table and then purged from the original table. The table contains a time stamp field named TSTAMP. When the program is run, all of the transactions that are older than six months are archived. Each archive table will have a fivecharacter prefix followed by a five digit sequential number. Our sample software application has twenty eight transaction tables. The only column in common to all of the tables is the TSTAMP column. The challenge is to write one program module that can handle the archive function for all of these tables. Step 1. Build the archive table name. While SQL supports long names for tables, we know that OS/400 supports only 10 characters for an object s system name. DB2 UDB on the iseries will automatically create a unique system name if the table name specified is over 10 characters long. Both the system name (10 characters) and the table name are stored in the DB2 UDB catalog. We are going to take advantage of this feature and allow the database manager to determine what the next system name will be. We are going to build a table name that is made up of a five character prefix, the date and time that the job was run. This will result in a 31 character table name. The SQL statement shown below returns the file name as the result. D newfile S 31 D prefix S 5 INZ('HIST_') /Exec SQL + SELET + :Prefix har(urrent_timestamp) + into :newfile /End Exec

5 This code returns a value that looks like this: HIST_ This value should always be unique as an SQL file name because of the microsecond precision of the urrent_timestamp function. You need to enclose this value in double quotes when you use it in the REATE TABLE AS statement. When the table is created, the system name will be HIST_00001 for the first table, HIST_00002 for the second table created and so on. When you refers to this table in SQL, you can use either the system name or the SQL name. Step 2. reate the archive file and copy records into it. The SQL statement shown below is called dynamic because it can be different each time the statement is executed. The SQL statement will not be syntax checked until the program tries to execute it. The EVAL statement builds the SQL statement using variables, built in functions. and constants. The Execute Immediate command does a syntax check on the statement stored in the sqlstmt variable and then submits it to the database manager for processing. Please note the WITH DATA clause at the end of the SQL statement. By adding WITH DATA to the statement, the data set created by the subquery will be added to the new table. * reate a new table and copy the eligible records into it Eval sqlstmt = 'reate Table ' + %Trim(newlibrary) + '/"' + %Trim(newfile) + '"' + ' As (select * From ' + %Trim(library) + '/' + %Trim(filename) + ' WHERE Date(TSTAMP) < ' + '(urrent_date 6 months) ' + 'With Data' /Exec SQL + Execute Immediate :sqlstmt /End Exec The code shown above will generate a value in the sqlstmt variable that will look something like this: reate table FileLib/"HIST_ " as (Select * from FileLib/ItemTrans Date(TSTAMP) < (urrent_date 6 months)) With Data Step 3. Delete the records from the original table. Once again you use a dynamic SQL statement. This statement deletes the records from the original file using the same record selection used to copy records into the archive file. Eval sqlstmt = 'Delete from ' + %Trim(library) + '/' + %Trim(filename) + ' WHERE Date(TSTAMP) < ' + 'urrent_date 6 months) ' /Exec SQL + Execute Immediate :sqlstmt /End Exec The code shown above will generate a value in the sqlstmt variable that will look something like this: Delete from FileLib/ItemTrans

6 Where Date(TSTAMP) < (urrent_date 6 months) An alternate way to delete these records is to delete only the records from the source file that exist in the archive file. The value in sqlstmt would need to look something like this: Delete from FileLib/ItemTrans Where TSTAMP in (Select TSTAMP from FileLib/"HIST_ ") So in just three steps, you have accomplished all of your objectives. Of course, you will need to add a little more code to make this example fully functional. By adding journaling to your files and commitment control to the program, you can make the program recover gracefully in case of an error. Raymond Everhart has over 18 years of IT experience with IBM midrange computers. He was a consultant, programmer, and educator for an IBM premier business partner in Upstate New York for 10 years, before relocating to the Dallas/Ft. Worth area in Since then, Raymond has been helping local companies implement new technologies with his consulting, programming, and mentoring services. You can reach Raymond with your questions at reverhart@raecodesign.com.