| While there is some documentation on the way, I think that what
is in the SRM is most of what is currently written down. So,
Here is a start.
Be warned! It is a first attempt, and
contains no examples. It may be too simple or too jumbled a view
for your needs. It is a personal interpretation from a maintainer
of the ILV routines. The view from inside the code is always different!
I will ask some people who use the routines to contribute examples.
Ruth Kohls
Chapter 1:
The basic principle of decoding ILV buffers is to undo what was
done. So, for every PUT you probably need a corresponding GET,
involving the same modes. The differences: you don't have to
GET values in the same order they were PUT, and you don't have
to GET everything, and don't GET the end of the encoding.
GETs are non-destructive decoding of the data.
You DO have to know what you want. To find out, you can use
prior knowlege (hardcode) or the dictionary (data-driven).
The data gets into the dictionary via management spec,
MSL, & DAP.
Constructions: If you look at a dump of an ilv buffer (get one
with (MCC_ILV_DUMP(encoded buffer)) you will see numbers marked
off with square brackets "[]" and then lots of stuff marked off
with parentheses "()". The numbers in square brackets "[ 1 ]" are the
ID codes, each left parenthesis "(" comes from a put_cons_begin, and
each right parenthesis ")" from a put_cons_end. So, a construction
is a labled value that may contain other labeled values. A
primitive value is labled, but does not contain other values.
ILV is intimately connected with the mcc datatypes. If you
look at the latter, you will find primitives (integers, strings)
constructor types, and constructed types. Constructed types
are things like records where all the field names and datatypes
are defined. Constructors are things like "set". I think of
contructor types as datatyped left parentheses, and contructed types
as forms to be filled in. An ILV construction is a bunch
of primitives, filled in constructor datatypes, constructions,
or some mix, each labelled with its id code.
(PUT_PARAM_BEGIN calls PUT_CONS_BEGIN, and GET_PARAM_BEGIN calls
GET_CONS_BEGIN)
You "open" an ilv-encoded buffer for reading with a GET_PARAM_BEGIN,
and "open" a construction for reading with a GET_CONS_BEGIN.
You "close" one level of construction (or pop out of a
construction) with a GET_CONS_END. (if you do a GET_ID and
there are no more ids in the construction or buffer, you are
automatically popped out one level from you started in)
Mode: the ilv context established with calls to PUT_PARAM_BEGIN or
GET_PARAM_BEGIN tracks the Current mode, which you may change
only with a put_cons_begin or get_cons_begin call. These calls
open a (nested) construction and keep the context updated.
ILV_LIST_VALUE mode indicates that the construction
contains one or more values (of arbitrary complexity) of
datatype ATTRIB-LIST. When this is the Current Mode, each
attribute value is Automatically, without a separate call to
ILV_PUT or ILV_GET, encoded in another level of construction,
with a Reason and its datatype as the other values encoded.
(a Reason is a "registered enumeration" defined in the SRM
in the datatypes chapter as "AttribOPReasonCode".)
ILV_NATIVE_VALUE mode means "what you ILV_PUT... is exactly
what is there" in form. PUT_PARAM_BEGIN and GET_PARAM_BEGIN
establish the context in Native mode.
|
| Hello,
Thanks for the responses, the problem seems to be sorting itself out :
The exact problem was that calling MCC$ILV_GET_CONS_BEGIN,
MCC$ILV_LIST_GET_DATATYPE, MCC$GET etc... all returned an "invalid
parameter" CVR. We assumed that this was due either to an incorrect use
of the routines (in terms of which order should we call them), or to
us using the wrong mechanism for passing the parameters.
As it turns out, there is a difference between the number of parameters
documented in the SRM and the number of parameters expected by the
current set of routines (We are running the EFT kit) : most of
these routines do not want the "mode" parameter.
Now the Release notes do mention that ILV_LIST routines will be
removed from future releases, but I was unable to find anything
about a chang in the number of parameters. Is it me ?
|
|
re: .3, above.
> As it turns out, there is a difference between the number of parameters
> documented in the SRM and the number of parameters expected by the
> current set of routines (We are running the EFT kit) : most of
> these routines do not want the "mode" parameter.
> Now the Release notes do mention that ILV_LIST routines will be
> removed from future releases, but I was unable to find anything
> about a chang in the number of parameters. Is it me ?
The current ILV routines require mode, reasoncode and datatype parameters as
documented in the SRM Update (my ILV routine update is dated Feb. 6, 1990).
I'm afraid I've lost track of when the ILV_LIST... routines changed to ILV...
with Mode (and backward compatibility to the OLD form, except for
ILV_LIST_GET_DATATYPE which stays, and does what it always did),
BUT BE WARNED:
With EFT UPDATE, the old ILV_LIST routines AND the OLD form of the ILV routines
(ILV_PUT, ILV_GET, ILV_PUT_CONS_BEGIN, ILV_GET_CONS_BEGIN) are GONE!!!!
Since our method of detecting the number of parameters to a call was not
portable, if you have the wrong number of parameters for one of these ilv
calls, you get an ACCVIO.
Please be sure to read the release notes with EFT update.
And please ask more specific questions, rather than more general ones if
possible--or ask both! I can't read your original note as "I don't see why
we're getting this CVR." I took it as a more general "incomplete documentation"
problem (obviously). Oh well, we lost nothing but time, and we may gain more
information on ILV for the authors of the "detailed how to" manuals.
Ruth Kohls
|