PKCS#10 and Hash -- PKCS#7????

Hi
How could I get a hash from a file or String that contains the PKSC#10 CSR (Certificate Request) an put it into a PKCS#7
Then I will need to verify(dehash) the hash in the PKCS#7 file or String
and how is Base64 involved into all these stuff?
Could anyone please post me some hints?
Thanks

I believe IBM JCE implementation allows you to generate CSR. check out www.ibm.com , then developer, then java tools

Similar Messages

Using JHS tables and hashing with salt algorithms for Weblogic security

We are going to do our first enterprise ADF/JHeadstart application. For security part, we are going to do the following:
1. We will use JHS tables as authentication for ADF security.
2. We will use JAAS as authentication and Custom as authorization.
2. We need to use JHeadStart security service screen in our application to manage users, roles and permission, instead of doing users/groups management within Weblogic.
3. We will create new Weblogic SQL Authentication Provider.
4. We will store salt with password in the database table.
5. We will use Oracle MDS.
There are some blogs online giving detail steps on how to create Weblogic SQL Authentication Provider and use JHS tables as authentication for ADF security. I am not sure about the implementation of hashing with salt algorithms, as ideally we'd like to use JHS security service screen in the application to manage users, roles and permission, not using Weblogic to do the users/groups management. We are going to try JMX client to interact with Weblogic API, looks like it is a flexiable approach. Does anybody have experience on working with JMX, SQL Authentication Provider and hashing with salt algorithms? Just want to make sure we are on the right track.
Thanks,
Sarah

To be clear, we are planning on using a JMX client at the Entity level using custom JHS entitiy classes.
BradW working with Sarah

Creation of Sorted and Standard and Hashed Internal Tables ..

Hi ..
Pls specify me.. how to create .. sorted ,Standard and Hashed Internal Tables...
pls give me the full code regarding ...this ..
Thnks

Standard tables
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.
Sorted tables
This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.
Hashed tables
This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.
Special Features of Standard Tables
Unlike sorted tables, hashed tables, and key access to internal tables, which were only introduced in Release 4.0, standard tables already existed several releases previously. Defining a line type, table type, and tables without a header line have only been possible since Release 3.0. For this reason, there are certain features of standard tables that still exist for compatibility reasons.
Standard Tables Before Release 3.0
Before Release 3.0, internal tables all had header lines and a flat-structured line type. There were no independent table types. You could only create a table object using the OCCURS addition in the DATA statement, followed by a declaration of a flat structure:
DATA: BEGIN OF <itab> OCCURS <n>,
<fi> ...
END OF <itab>.
This statement declared an internal table <itab> with the line type defined following the OCCURS addition. Furthermore, all internal tables had header lines.
The number <n> in the OCCURS addition had the same meaning as in the INITIAL SIZE addition from Release 4.0. Entering 0 had the same effect as omitting the INITIAL SIZE addition. In this case, the initial size of the table is determined by the system.
The above statement is still possible in Release 4.0, and has roughly the same function as the following statements:
TYPES: BEGIN OF <itab>,
<fi> ...,
END OF <itab>.
DATA <itab> TYPE STANDARD TABLE OF <itab>
WITH NON-UNIQUE DEFAULT KEY
INITIAL SIZE <n>
WITH HEADER LINE.
In the original statement, no independent data type <itab> is created. Instead, the line type only exists as an attribute of the data object <itab>.
Standard Tables From Release 3.0
Since Release 3.0, it has been possible to create table types using
TYPES <t> TYPE|LIKE <linetype> OCCURS <n>.
and table objects using
DATA <itab> TYPE|LIKE <linetype> OCCURS <n> WITH HEADER LINE.
The effect of the OCCURS addition is to construct a standard table with the data type <linetype>. The line type can be any data type. The number <n> in the OCCURS addition has the same meaning as before Release 3.0. Before Release 4.0, the key of an internal table was always the default key, that is, all non-numeric fields that were not themselves internal tables.
The above statements are still possible in Release 4.0, and have the same function as the following statements:
TYPES|DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
WITH NON-UNIQUE DEFAULT KEY
INITIAL SIZE <n>
WITH HEADER LINE.
They can also be replaced by the following statements:
Standard Tables From Release 4.0
When you create a standard table, you can use the following forms of the TYPES and DATA statements. The addition INITIAL SIZE is also possible in all of the statements. The addition WITH HEADER LINE is possible in the DATA statement.
Standard Table Types
Generic Standard Table Type:
TYPES <itab> TYPE|LIKE STANDARD TABLE OF <linetype>.
The table key is not defined.
Fully-Specified Standard Table Type:
TYPES <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
WITH NON-UNIQUE <key>.
The key of a fully-specified standard table is always non-unique.
Standard Table Objects
Short Forms of the DATA Statement :
DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>.
DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
WITH DEFAULT KEY.
Both of these DATA statements are automatically completed by the system as follows:
DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
WITH NON-UNIQUE DEFAULT KEY.
The purpose of the shortened forms of the DATA statement is to keep the declaration of standard tables, which are compatible with internal tables from previous releases, as simple as possible. When you declare a standard table with reference to the above type, the system automatically adopts the default key as the table key.
Fully-Specified Standard Tables:
DATA <itab> TYPE|LIKE STANDARD TABLE OF <linetype>
WITH NON-UNIQUE <key>.
The key of a standard table is always non-unique.
Internal table objects
Internal tables are dynamic variable data objects. Like all variables, you declare them using the DATA statement. You can also declare static internal tables in procedures using the STATICS statement, and static internal tables in classes using the CLASS-DATA statement. This description is restricted to the DATA statement. However, it applies equally to the STATICS and CLASS-DATA statements.
Reference to Declared Internal Table Types
Like all other data objects, you can declare internal table objects using the LIKE or TYPE addition of the DATA statement.
DATA <itab> TYPE <type>|LIKE <obj> WITH HEADER LINE.
Here, the LIKE addition refers to an existing table object in the same program. The TYPE addition can refer to an internal type in the program declared using the TYPES statement, or a table type in the ABAP Dictionary.
You must ensure that you only refer to tables that are fully typed. Referring to generic table types (ANY TABLE, INDEX TABLE) or not specifying the key fully is not allowed (for exceptions, refer to Special Features of Standard Tables).
The optional addition WITH HEADER line declares an extra data object with the same name and line type as the internal table. This data object is known as the header line of the internal table. You use it as a work area when working with the internal table (see Using the Header Line as a Work Area). When you use internal tables with header lines, you must remember that the header line and the body of the table have the same name. If you have an internal table with header line and you want to address the body of the table, you must indicate this by placing brackets after the table name (<itab>[]). Otherwise, ABAP interprets the name as the name of the header line and not of the body of the table. You can avoid this potential confusion by using internal tables without header lines. In particular, internal tables nested in structures or other internal tables must not have a header line, since this can lead to ambiguous expressions.
TYPES VECTOR TYPE SORTED TABLE OF I WITH UNIQUE KEY TABLE LINE.
DATA: ITAB TYPE VECTOR,
JTAB LIKE ITAB WITH HEADER LINE.
MOVE ITAB TO JTAB. <- Syntax error!
MOVE ITAB TO JTAB[].
The table object ITAB is created with reference to the table type VECTOR. The table object JTAB has the same data type as ITAB. JTAB also has a header line. In the first MOVE statement, JTAB addresses the header line. Since this has the data type I, and the table type of ITAB cannot be converted into an elementary type, the MOVE statement causes a syntax error. The second MOVE statement is correct, since both operands are table objects.
plz reward if useful

Generally when does optimizer use nested loop and Hash joins ?

Version: 11.2.0.3, 10.2
Lets say I have a table called ORDER and ORDER_DETAIL.
ORDER_DETAIL is the child table of ORDERS .
This is what I understand about Nested Loop:
When we join ORDER AND ORDER_DETAIL tables oracle will form a 'nested loop' in which for each order_ID in ORDER table (outer loop), oracle will look for corresponding multiple ORDER_IDs in the ORDER_DETAIL table.
Is nested loop used when the driving table (ORDER in this case) is smaller than the child table (ORDER_DETAIL) ?
Is nested loop more likely to use Indexes in general ?
How will these two tables be joined using Hash joins ?
When is it ideal to use hash joins ?

Your description of a nested loop is correct.
The overall rule is that Oracle will use the plan that it calculates to be, in general, fastest. That mostly means fewest I/O's, but there are various factors that adjust its calculation - e.g. it expects index blocks to be cached, multiple reads entries in an index may reference the same block, full scans get multiple blocks per I/O. It also has CPU cost calculations, but they generally only become significant with function / package calls or domain indexes (spatial, text, ...).
Nested loop with an index will require one indexed read of the child table per outer table row, so its I/O cost is roughly twice the number of rows expected to match the where clause conditions on the outer table.
A hash join reads the of the smaller table into a hash table then matches the rows from the larger table against the hash table, so its I/O cost is the cost of a full scan of each table (unless the smaller table is too big to fit in a single in-memory hash table). Hash joins generally don't use indexes - it doesn't use the index to look up each result. It can use an index as a data source, as a narrow version of the table or a way to identify the rows satisfying the other where clause conditions.
If you are processing the whole of both tables, Oracle is likely to use a hash join, and be very fast and efficient about it.
If your where clause restricts it to a just few rows from the parent table and a few corresponding rows from the child table, and you have an index Oracle is likely to use a nested loops solution.
If the tables are very small, either plan is efficient - you may be surprised by its choice.
Don't be worry about plans with full scans and hash joins - they are usually very fast and efficient. Often bad performance comes from having to do nested loop lookups for lots of rows.

What is the difference between standard,sorted and hash table

<b>can anyone say what is the difference between standard,sorted and hash tabl</b>

Hi,
Standard Tables:
Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition.
This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to
the number of table entries.
Sorted Tables:
Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique, or non-unique, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables.
This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of
table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key.
Hashed Tables:
Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition.
This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and
using internal tables that are similar to database tables.
Regards,
Ferry Lianto

Actual difference between a standard , sorted and hashed atble

hi ,
1. what is the actual difference between a
standard,sorted and hashed table ? and
2. where and when these are actually used and applied ?
provide explanation with an example ....

hi
good
Standard Internal Tables
Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition.
This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to
the number of table entries.
Sorted Internal Tables
Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique, or non-unique, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables.
This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of
table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key.
Hashed Internal Tables
Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition.
This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and
using internal tables that are similar to database tables.
THANKS
MRUTYUN

Atilde (~) and hash (#) are broken

I have a 2009 Macbook Pro 13-inch, on which I recently installed Windows 7. I have discovered however that my atilde key and my hash key are both set to the incorrect symbol. On all English keyboards, the atilde key outputs as § or ± with shift held down, while the hash key has been replaced by the pound symbol (£). I am at a loss as to why this would be the case or as to how to fix it. I have changed my keyboard to US International and several other english keyboards, but it doesn't change anything. When changing to a different language (such as Chinese) I can type the normal atilde and hash, but this has obvious limitations. Any help would be greatly appreciated. Thank you.

Martel101 wrote:
I have changed my keyboard to US International and several other english keyboards
Have you tried changing the keyboard setting inside Windows to one that has (Mac) after the name?

Sorted and hashed tables

what happens when duplicate entries are present in sorted and hashed tables?

Hi,
Sorted internal tables can be of two types:
unique or non unique.
If u enter duplicate records in Sorted tables with unique it will show error.
If u enter duplicate records in Sorted tables with non-unique key it will not show error.
Hashed tables are with only unique key
so no way to enter the duplicate records.
for more information see the following link
http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb35de358411d1829f0000e829fbfe/content.htm
Reward if helpful.
Jagadish

Eracom CSA 8000 and SUN PKCS#11 API

I'm trying to use Eracom as a cryptographic accelerator for using with JSSE in establishment of SSL connections. I'm using its software version that I haven't installed the hardware but they both have the same functionalities and both uses PKCS11 as their interface to actual operations. The problem is that I have a token contains many entries includes secret keys, Private keys and certificates. But when I construct a keystore in my program in does not contain any entries. I looked at the log created by Eracom and noticed that it does not log in at all. However some of those entries are public and can be seen with Cryptoki Token Browser a GUI for working with tokens.
I used that graphical interface and logged in as security officer. Then I generated a RSA keypair with subject set to 'CN=myserver'. I used Derive Key on public key to generate a certificate request and in turn prepared a certificate based on that request and imported that certificate using Create Object option. In this case it works it lists it as an entry and uses it in SSL server.

You need to use the trustanchors nssModule, read the JavaTM PKCS#11 Reference Guide at --
http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#Config
For example, you can write your config file like this --
name=NSS
nssSecmodDirectory=path_of_your_dbs
nssLibraryDirectory=path_of_dll_or_so
nssModule=trustanchors

XML Digital Signature and sun PKCS#11

Hi,
I am trying to use xmldsig/xmlsec from Java Web Services Developer's Pack to do signing of XML documents. My goal is to use the keys from the card via sunpkcs11 to perform this signature.
At this stage, i'm able to get the correct key from the card via sun pkcs 11 (J2SE 5) and able to sign some data with it.
However, when i try to sign a xml document via xmldsig, i get the error which i believe to occur while trying to read the private key from the card as a string, which results in a "not a byte[]" exception.
At this stage, are there any ways to configure the xmldsig/xmlsec to use the pkcs11 provider?
I understand that the current implementation of XML Digital signature is using apache XML libraries. Is the source code for the wsdp downloadable from SUN?
If not, will it be possible to make use of the open-source apache XML jars, set it up for pkcs11 and use it instead?
Finally, has anyone done what I'm trying to do? Will be glad to know
Thank u in advance,
Louis

Hello
Did you resolve yout problem, because i have the same when i try to sign message
String testData = "Hello World";
p11KeyStore = KeyStore.getInstance("PKCS11");
p11KeyStore.load(null, new char[] {'1', '2', '3', '4'});
sig = Signature.getInstance("SHA1withRSA");
sig.initSign( (PrivateKey) p11KeyStore.getKey(myAlias, null));
sig.update(testData.getBytes());
signatureBytes = sig.sign()
This code fails and i get java.lang.RuntimeException: Not a byte[]
at sun.security.pkcs11.wrapper.CK_ATTRIBUTE.getBigInteger(CK_ATTRIBUTE.java:168)
at sun.security.pkcs11.P11Key$P11RSAPrivateKey.fetchValues(P11Key.java:419)

Classpath and hash Character (#)

Hi,
I have some jar files in my java classpath and it looks as if the JVM does not manage to find them when the jar file path contains a hash character (#) (java.lang.NoClassDefFoundError Exception is raised)
I haven't found anything about this in docs.
Can anyone help me ?
Thanks
Michel

Maybe not.
However, once I do not need these classes which are stored in a file path with a hash character, everything works fine.
You can experiment by yourself following this basic scenario:
1) store your famous HelloWord.class in a directory containing a hash Character (e.g. C:\tmp\te#st )
2) run your jvm as follows: java -classpath C:\tmp\te#st HelloWord
3) you should see the message
"Exception in thread "main" java.lang.NoClassDefFoundError: HelloWorld"
if not, tell me. I am completely wrong.
PS: Enviromment: WindowNT, sdk 1.4.0 or sdk 1.3.1
Michel

Bind join and hash join

Hi
I would like to know if there is difference between bind join end hash join.
For example If I write sql code in My query tool (in Data Federator Query server administrator XI 3.0) it is traduced in a hashjoin(....);If I set system parameters in right way to produce bind join, hashjoin(...) is present again!
how do i understand the difference?
bye

Query to track the holder and waiter info
People who reach this place for a similar problem can use the above link to find their answer
Regards,
Vishal

Differences between sql id and hash value

Hello All,
I have read the following from Tom's web site. Ask Tom &quot;What is a child cursor&quot;
Dear Tom,
Appreicate your services to the oracle community.
What is the column combinations which is leading to SQL_ID. is SQL_ID = hash_value + address ? Regards Lalitha
Followup August 28, 2012 - 1pm UTC:
sql id = hash( sql statement )
hash value is maintained for backward compatibility, sqlid is a new, better hash.
I am just wondering what did he mean when he said "hash value is maintained for backward compatibility, sqlid is a new, better hash."?
If both of them are the output of hash function, could someone please explain clearly what is the differences between SQL_ID and HASH_VALUE?
Thanks for your help.

SQL_ID is just a fancy representation of hash value | Tanel Poder&#039;s blog: IT &amp; Mobile for Geeks and Pro…
Regards
Jonathan Lewis

Modify HUGE HASH partition table to RANGE partition and HASH subpartition

I have a table with 130,000,000 rows hash partitioned as below
----RANGE PARTITION--
CREATE TABLE TEST_PART(
C_NBR CHAR(12),
YRMO_NBR NUMBER(6),
LINE_ID CHAR(2))
PARTITION BY RANGE (YRMO_NBR)(
PARTITION TEST_PART_200009 VALUES LESS THAN(200009),
PARTITION TEST_PART_200010 VALUES LESS THAN(200010),
PARTITION TEST_PART_200011 VALUES LESS THAN(200011),
PARTITION TEST_PART_MAX VALUES LESS THAN(MAXVALUE)
CREATE INDEX TEST_PART_IX_001 ON TEST_PART(C_NBR, LINE_ID);
Data: -
INSERT INTO TEST_PART
VALUES ('2000',200001,'CM');
INSERT INTO TEST_PART
VALUES ('2000',200009,'CM');
INSERT INTO TEST_PART
VALUES ('2000',200010,'CM');
VALUES ('2006',NULL,'CM');
COMMIT;
Now, I need to keep this table from growing by deleting records that fall b/w a specific range of YRMO_NBR. I think it will be easy if I create a range partition on YRMO_NBR field and then create the current hash partition as a sub-partition.
How do I change the current partition of the table from HASH partition to RANGE partition and a sub-partition (HASH) without losing the data and existing indexes?
The table after restructuring should look like the one below
COMPOSIT PARTITION-- RANGE PARTITION & HASH SUBPARTITION --
CREATE TABLE TEST_PART(
C_NBR CHAR(12),
YRMO_NBR NUMBER(6),
LINE_ID CHAR(2))
PARTITION BY RANGE (YRMO_NBR)
SUBPARTITION BY HASH (C_NBR) (
PARTITION TEST_PART_200009 VALUES LESS THAN(200009) SUBPARTITIONS 2,
PARTITION TEST_PART_200010 VALUES LESS THAN(200010) SUBPARTITIONS 2,
PARTITION TEST_PART_200011 VALUES LESS THAN(200011) SUBPARTITIONS 2,
PARTITION TEST_PART_MAX VALUES LESS THAN(MAXVALUE) SUBPARTITIONS 2
CREATE INDEX TEST_PART_IX_001 ON TEST_PART(C_NBR,LINE_ID);
Pls advice
Thanks in advance

Sorry for the confusion in the first part where I had given a RANGE PARTITION instead of HASH partition. Pls read as follows;
I have a table with 130,000,000 rows hash partitioned as below
----HASH PARTITION--
CREATE TABLE TEST_PART(
C_NBR CHAR(12),
YRMO_NBR NUMBER(6),
LINE_ID CHAR(2))
PARTITION BY HASH (C_NBR)
PARTITIONS 2
STORE IN (PCRD_MBR_MR_02, PCRD_MBR_MR_01);
CREATE INDEX TEST_PART_IX_001 ON TEST_PART(C_NBR,LINE_ID);
Data: -
INSERT INTO TEST_PART
VALUES ('2000',200001,'CM');
INSERT INTO TEST_PART
VALUES ('2000',200009,'CM');
INSERT INTO TEST_PART
VALUES ('2000',200010,'CM');
VALUES ('2006',NULL,'CM');
COMMIT;
Now, I need to keep this table from growing by deleting records that fall b/w a specific range of YRMO_NBR. I think it will be easy if I create a range partition on YRMO_NBR field and then create the current hash partition as a sub-partition.
How do I change the current partition of the table from hash partition to range partition and a sub-partition (hash) without losing the data and existing indexes?
The table after restructuring should look like the one below
COMPOSIT PARTITION-- RANGE PARTITION & HASH SUBPARTITION --
CREATE TABLE TEST_PART(
C_NBR CHAR(12),
YRMO_NBR NUMBER(6),
LINE_ID CHAR(2))
PARTITION BY RANGE (YRMO_NBR)
SUBPARTITION BY HASH (C_NBR) (
PARTITION TEST_PART_200009 VALUES LESS THAN(200009) SUBPARTITIONS 2,
PARTITION TEST_PART_200010 VALUES LESS THAN(200010) SUBPARTITIONS 2,
PARTITION TEST_PART_200011 VALUES LESS THAN(200011) SUBPARTITIONS 2,
PARTITION TEST_PART_MAX VALUES LESS THAN(MAXVALUE) SUBPARTITIONS 2
CREATE INDEX TEST_PART_IX_001 ON TEST_PART(C_NBR,LINE_ID);
Pls advice
Thanks in advance

[Solved] vim, indent and hash

I know this isn't strictly a programming problem, but bear with me...
To make a long story short, I have a Perl file in which some comment lines start with the hash(#) as the first character of the line, i.e. before the # there's nothing, not even spaces. The problem is that trying to indent this line with == does not work. Now, with my current vim setup, when *insert* a new line that starts with an #, indentation is done properly. Also, if there is space before the #, but the indentation is wrong, == correctly indents it. The problem is when the # is the very first character of the line, and (it goes without saying) the indentation is wrong, == does nothing.
I've googled and read all about disabling smartindent, cindent, and whatnot, and nothing seems to work. I'm really grasping at the straws with this one, so all ideas are welcome...
Last edited by gauthma (2010-10-26 16:22:11)

For future reference of whomever might encouter this problem... the file /usr/share/vim/vim73/indent/perl.vim has, in line 55 and following, the, erm, following:
" Don't reindent coments on first column
if cline =~ '^#.'
return 0
endif
Commenting those out solved the problem. Of course I now wonder why would those lines be there in the first place, but I digress...

PKCS#10 and Hash -- PKCS#7????

Similar Messages

Maybe you are looking for