|
I'm as new to this as you are, but my experience says what is in the
attr buffer when you write is what you get back when you read it.
The mir sees your data as a stream of bytes with a specified length, and
makes no attempt to insert one ILV-encoded attr value into an existing
stream, and any other operation that would assume knowing the structure
of your data.
|
| RE:.1 Yes, the MIR routines really only looks at the length and
starting address of the buffer (i.e., it's just a stream of bytes).
RE:.0 If you have two attributes in the your private attribute
repository, and you wish to modify one, without changing the other,
you must 1) read the record, 2) modify the record (using ILV gets and
puts, in your case) 3) write it back out. If you need transaction
processing, then that would involve more work.
I had a routine which would search through an ILV encoding and just
modify the value for a given ID code (by copying it to another ILV
buffer). I should try and find it, someone may find it useful.
BTW, The SRM (Section 10.12.3) states:
"... If the attribute partition is used often for passing through the call
interface, then it may be useful to ILV-encode the data. However, the
MIR routines do not make any assumptions about the storage of the
attributes. If the data is not ILV-encoded, the owner of the data must
know the record layout. If it is ILV-encoded, the owner of the data
should call the ILV routines to build and parse the attribute partition
record."
Hope this clarifies things a little.
-Matt.
|