Hi Everyone,



Before I have to go and attack the Opensource to find out the answer to
this one....



I have an OME function which takes input from a long varchar, encrypts
it and then tries to write the encrypted data to a long byte.



But although I can read the long varchar, I just cant make my program
write the long byte. I keep failing with error:

E_AD7006 An error was encountered in attempting to perform the
peripheral put operation.



I've initialised the pop_cb.pop_coupon as follows:

II_POP_CB i_pop_cb, o_pop_cb;

II_DATA_VALUE i_underdv, i_segment, i_coupon;

II_DATA_VALUE o_underdv, o_segment, o_coupon;

II_PERIPHERAL *p;



p = (II_PERIPHERAL *)
encrypted->db_data;

p->per_tag = II_P_COUPON;

p->per_length0 = 0;

p->per_length1 = 0;



o_coupon.db_datatype = encrypted->db_datatype;

o_coupon.db_data = encrypted->db_data;

o_coupon.db_length = sizeof(II_PERIPHERAL);

o_coupon.db_prec = 0;



etc...filling in the pop_underdv to point to a long byte data type and
pop_segment to hold the encrypted data in a varbyte like manner.



The o_coupon was successfully passed to the filter function to get
II_INFORMATION.



Changing p->per_tag to II_P_DATA merely stopped the program with a
different error:

E_AD700D No coupon value was passed as required.



Checking the Opensource has shown that I definitly need to pass the
II_P_COUPON value.



Anyone got any ideas what I've done wrong?



Martin Bowes

--

Random Farscape Quote #10:

Chiana - I can kick, kiss or cry my way out of any problem, but this is
way, way, way, way different.

Hi Everyone,



I've managed to track down that the problem is in the 4th attribute and
causes a E_DM0009_BAD_ATTR_SIZE Illegal size for attribute error.



That error is produced in the ./back/dmf/dml/dmtcreate.c program.



Now if anyone could explain that in English, I'd be happier.



Marty

PS. Does anyone know why we can't set the per_tag to II_P_DATA? The
dmpe.c is coded to produce the E_AD700D error if it sees anything other
that II_P_COUPON.



--

Random Duckman Quote #111:

Ajax: I found it a provocative piece of stagecraft, marred only by the

author's over-weening pretense towards psychological insight. But
the

violence was keen!



From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of
Martin Bowes
Sent: 28 December 2007 13:52
To: info-ingres (AT) kettleriverconsulting (DOT) com
Subject: [Info-Ingres] OME, II_PUT and writing a long byte



Hi Everyone,



Before I have to go and attack the Opensource to find out the answer to
this one....



I have an OME function which takes input from a long varchar, encrypts
it and then tries to write the encrypted data to a long byte.



But although I can read the long varchar, I just cant make my program
write the long byte. I keep failing with error:

E_AD7006 An error was encountered in attempting to perform the
peripheral put operation.



I've initialised the pop_cb.pop_coupon as follows:

II_POP_CB i_pop_cb, o_pop_cb;

II_DATA_VALUE i_underdv, i_segment, i_coupon;

II_DATA_VALUE o_underdv, o_segment, o_coupon;

II_PERIPHERAL *p;



p = (II_PERIPHERAL *)
encrypted->db_data;

p->per_tag = II_P_COUPON;

p->per_length0 = 0;

p->per_length1 = 0;



o_coupon.db_datatype = encrypted->db_datatype;

o_coupon.db_data = encrypted->db_data;

o_coupon.db_length = sizeof(II_PERIPHERAL);

o_coupon.db_prec = 0;



etc...filling in the pop_underdv to point to a long byte data type and
pop_segment to hold the encrypted data in a varbyte like manner.



The o_coupon was successfully passed to the filter function to get
II_INFORMATION.



Changing p->per_tag to II_P_DATA merely stopped the program with a
different error:

E_AD700D No coupon value was passed as required.



Checking the Opensource has shown that I definitly need to pass the
II_P_COUPON value.



Anyone got any ideas what I've done wrong?



Martin Bowes

--

Random Farscape Quote #10:

Chiana - I can kick, kiss or cry my way out of any problem, but this is
way, way, way, way different.

At 4:01 PM +0000 12/28/07, Martin Bowes wrote:
It's failing the adc_lenchk check on the 4th attribute.
I'm guessing that this is via a call to dmu_create in
dmpe_create_extension, in which case that attribute
is for the "underlying data type", ie the value holder
column in the extension table. This in turn comes
from an adi_per_under call against the long type.


Marty, you probably already know more about blobs than
anyone else, unless Alison (Stillway) happens to
remember what is going on in there. :-) No, I have
no clue...

Karl

Hi Karl,

As per the manual...
I've set the pop_underdv->db_datatype to II_LBYTE and then used a call
to the II_LO_HANDLER with
II_INFORMATION to set the db_length in the pop_underdv. This has set it
the db_length to 1980.

I then set the pop_segment to have the same db_length(ie. 1980). When I
actually get data to write,
the first two bytes of pop_segment->db_data is set to the true data
length (eg. 48) and the rest of db_data
is filled with the data to be written.

The pop_coupon db_length is set to sizeof(II_PERIPHERAL) (ie. 40 bytes).

Before the write I increment the coupons per_length1 field by the amount
of data actually being written.

I also increment the pop_cb.pop_segno1.

So I'm stuffed If I can see what its bitching about!

Unless someone can see something wrong with what I'm doing, I'll have to
put a heap more diagnostics into the Opensource and see if I can slowly
narrow it down.

I seriously doubt that Karl.

I rely on positive idiocy. I have no idea why it shouldn't work, so I'm
not blinded by reality when it comes to exploring possibilities.

Marty

PS. When I get this bitch to work, I'll see if I can add the checksum
and encrypt/decrypt functions to the Opensource.

At 1:16 PM +0000 12/31/07, Martin Bowes wrote:
I haven't tried reading the manual yet , but I would have thought
that the underdv type should be II_BYTE or whatever it's called,
not LBYTE. Surely pop_underdv is the underlying data type which
would be byte.

I had the dmpe part of blobs sorta-kinda figured out when I
had to fix the coupon contents for parallel copy, but that
was a couple years ago and I've managed to forget a lot of
it. I never did have any clue what was going on inside of
adc_xform and the other ADF bits related to blobs. Recent
edit history entries are pretty few and far between. What
we need is some sort of reasonably comprehensive overview
document on how blobs work; I suspect there might have
been such a thing on paper, once upon a time, but nobody
has ever claimed ownership of such a thing that I know of.

Karl

Hi Karl,

Sonofabitch!

You're right!

And its so clearly stated on p18 of the manual when it said:...
Large objects are stored as a number of segments, each of which is of
some simple and small data type. This type is called the underlying data
type for the large object. See Structure IIADD_DT_DFN Fields. Operations
performed on large objects generally operate on a segment at a time.

I wonder how I missed that!

I've made the changes and now the program survives the II_PUT. A few
more tweaks and it might actually output what I wanted it to!

Amen to that brother!

Marty

Hi Karl,

My OME Function is:
II_STATUS
long_encrypt (
II_SCB *scb,
II_DATA_VALUE *passwd, /* The password or phrase */
II_DATA_VALUE *intext, /* text to encrypt */
II_DATA_VALUE *encrypted /* encrypted text */
)
{...
};

And now, when I link this all up...
select hex(encrypt('asdf', string )) from long_x

Now gives me...with a few diagnostics...
pop_segment ->
db_data(48)=DA5F867D2119DA05CEB92BE289DB4E09EC32A4 1F9012993E28A4D4944284
508A803683F6F30E1BA02A87C95BFFA99F5A
pop_segment -> db_data(8)=35237588432E810C
encrypt(): survived Final II_PUT. Wrote: 2 segments of total length 56
char

Trouble is the select returns...
010000000000000038000000000000000000000003000080FF FFFFFFFFFFFFFF

I eventually realised that the data returned by the select was in fact
the pop_coupon->db_data which has been coerced into a II_PERIPHERAL. I
had set my functions encrypted -> db_data to the db_data used by the
coupon being employed to write the encrypted chunks of data into a long
byte. This was as per the examples in demo/udadts.

I'd be pretty sure that the II_PUT is writing the data correctly now.
But it seems I just havent nailed tieing the data being written to the
'encrypted' parameter. Where it's gone is a mystery!

I would have thought tieing the encrypted->db_data to the coupon would
have worked as this is analogous to reading the input data (intext a
long varchar).

Any Ideas?

Marty
--
Random Farscape Quote #2:
Aeryn - Who knows, we might end up making things better.
John - With our record, do you think thats likely?

You are a beautiful man Karl! I owe you a beer!

I've just finished the long decrypt version and now....

The initial string is: This is a small string stored in a long varchar!

After select left(decrypt('asdf', encrypt('asdf', string)), 100) from
long_x\g
I get: This is a small string stored in a long varchar!

I'll move onto giving it a really long varchar to play with and see what
happens.

Marty
--
Random Duckman Quote #110:
Charles/Mambo: Dad hasnt got lucky since he convinced a blind Seinfeld
obsessed groupie he was Jason Alexander in a Duck suit.