Technical Tips including DB2 z/OS, DB2 LUW, COBOL, JCL, VSAM, CICS, 3rd party vendor tools (BMC, CA, IBM, Macro4, etc.)
Tuesday, September 30, 2008
CA/Platinum Fast Unload tips
Fast Unload is much faster than DB2's DSNTIAUL. One of the reasons is, it does not use DB2 SQL to fetch the data. Instead it fetches the data directly from the underlying VSAM dataset. But this does not happen always. Sometimes it may have to fetch the data from the table. This is controlled by the keyword "SQL-ACCESS".
SQL-ACCESS NONE:
When you specify "NONE" for SQL-ACCESS, it does not use SQL access. If the select statement
cannot be processed using VSAM or EXCP, an error message is issued & processing ends. This is the DEFAULT.
Note: You must specify NONE to unload data from Image Copies, Concurrent Copies & DSN1COPYs.
SQL-ACCESS ONLY:
When you specify this option, it uses only SQL access to unload the tablespaces. This option lets you use any valid SELECT statement. Only one SELECT statement is processed at a time. The statements using VSAM or EXCP are processed first, followed by the SQL ACCESS SELECT statements, which are processed in the order specified in the control statements. You cannot include an ORDER-CLUSTERED clause, or the PART or OBID parameters with this option. You must specify SQL-ACCESS ONLY to use TRIM with ASCII objects. With SQL-ACCESS ONLY, DB2 determines locking. To preserve data integrity, you must specify LOCKSIZE TABLE on the tablespace.
SQL-ACCESS EXTENSION:
When you specify "EXTENSION" for SQL-ACCESS, it uses EXCP or VSAM processing if possible; otherwise uses SQL access. If you specify SQL-ACCESS EXTENSION, only those SELECT statements that require SQL access use it; all other SELECT statements are multitasked & unloaded using VSAM or EXCP. If you specify SQL-ACCESS EXTENSION with the PART or OBID parameter & SQL-ACCESS is required, an error message is issued and processing terminates.
Tuesday, September 23, 2008
How to find DBID, PSID, OBID of a tablespace
For an existing table, to obtain the DBID and PSID, run the following query:
SELECT DBNAME, DBID, NAME, PSID
FROM SYSIBM.SYSTABLESPACE
WHERE DBNAME = "database-name"
AND NAME = "table_space-name"
To obtain the table OBID, run this query:
SELECT NAME, OBID
FROM SYSIBM.SYSTABLES
WHERE TSNAME = "table_space-name"
AND CREATOR = "creator-name"
Thursday, September 18, 2008
ISPF/TSO tips
- PANELID ON will show the panel name in the top left corner
- PFSHOW ON will show the PF Keys assignment at the bottom of the screen
- You are editing a PDS (partitioned dataset) member; you've made significant number of changes to the member; now you are thinking about creating a new member with these changes rather than saving the changes in the member you are editing. Can you do this? Yes, you can. Just issue this command: CRE .ZF .ZL memname. And, don't forget to issue CANCEL command on the member that you are editing, otherwise, you might save the changes accidentally (if AUTOSAVE is turned ON in your ISPF profile)
- Talking of ISPF profile, how will you know what are all the options available and which are turned on/off? Issue PROF on a dataset while in VIEW or EDIT mode.
- C ALL 'abc' 'xyz' will replace all occurrences of string abc to xyz
- C ALL 'abc' 'xyz' n will replace all occurrences of string abc to xyz in column n
- C ALL 'abc' 'xyz' n1 n2 will replace all occurrences of string abc to xyz between columns n1 and n2
- C ALL P'¬' 'abc' n1 n2 will replace ANY character found between columns n1 and n2 to abc. Use this very carefully.
- X ALL 'abc' will exclude all the lines that have the string 'abc'
- COMP X 'dataset(optional_member_name)' will display the differences between current PDS/PS and the compared dataset excluding all the lines that match. This is very useful if you are making changes to a source code and want to compare it with the baseline. There is another powerful feature available along with comparing two datasets. You can bring in the changes found in the compared dataset which is not available in the current dataset. If you would like know how to do this, please send me an email or post a comment
"HIDE EXCLUDE"
RESET will behave as before; RESET HIDE will return the row of dots to your display.
Wednesday, September 17, 2008
How to query tables from different DBMSs?
The answer is 'federation'. If you have DB2 UDB, and want to join a table from Oracle or DB2 for z/OS, create a federated table image of the table that resides in the other DBMS. Once you create a federated table, you can write queries treating it like a table that resides on the local DB2 UDB server.
For example:
SELECT L.col1, L.col2, F.cola, F.colb
FROM Local_Table L, Federated_Table F
WHERE L.col3 = F.colc
Remember that for "federation" to work, you need DB2 Connect or a similar product.
You can find more details here:
IBM Federated Database Technology
Monday, September 15, 2008
Migrate dataset to tape
HMIG 'dataset name' ML2
HRECALL with DFDSS option
When you need a dataset that has been migrated to tape, you can issue the HRECALL command. However, if the recalled dataset doesn’t fit in one volume the command fails. To get through this, you can have it span multi-volumes using the following command:
HSEND RECALL ‘migrated-dataset-name’ DFDSSOPTION(VOLCOUNT(ANY))
‘TTR’ in PDS and PDSE
Partitioned Data Set uses an addressing scheme called TTR (Track-Track-Record) which is based on the DASD geometry. TTR addresses are stored in hexadecimal format. So an address of X’002E26′ would mean track number X’002E’ and record X’26′. The name TTR comes from the fact that first two bytes of the address denote track number and third byte denotes record number. This dependence on the DASD geometry makes it very difficult to migrate PDS from one type of DASD to another one, e.g. from 3380 to 3390.
The PDSE addressing scheme is not dependent on the physical device geometry. It uses a ’simulated’ 3-byte TTR address to locate the members & the records which makes the migration easier. Incidentally, this simulation of addresses places some limitations on the number of members and the number of records per member in a PDSE. A TTR address of X’000001′ in a PDSE points to the directory. The addresses from X’000002′ to X’07FFFF’ point to the first record of each member, which is why there is a limit of 524,286 members. The addresses from X’100001′ to X’FFFFFF’ point to records within each member, which is why there is a limit of 15,728,639 records in each member.