RE: creating Member using SEPT I/O? -- MI400

> Behalf Of Leif Svalgaard

> Jean-Michel, if you still remember how you did it, the
> information you have
> about QDMROUTE may be useful to the list....

>

Leif and others,


As mentioned, there is a long time since I last used QDMROUTE (almost 10 
years), we have replaced it's calls by APIs. Furthermore,  I'm not sure my 
notes (mostly handwriting) are correct and usefull because they come from a 
very empiric way of work : dump, test dump again, test again, ... and loop 
thoses steps until the end of the night ;-)

QDMROUTE needs 4 to ? parms (the maximum I've seen is 6)

first four parms are :

        - Parm1         CHAR(2) (not a pointer)
        - Parm2         SPCPTR to a CHAR(30)
        - Parm3         SYSPTR
        - Parm4 SPCPTR to a BDRY(16) CHAR(256) (maybe it's longer now ?)

        - I don't kwnow other parms



PARM1 :
-------
The first parm is a function code informing QDMROUTE what to do :
what I've found :
the rightmost bit of the first byte seems to indicate that QDMROUTE must use 
the OVRxxxF, if any.
other bits of first bytes are unknown to me (forced to '0')

the second byte is the function :

        01      Creation (file ?) (6 parms)
        02      Member creation (5 parms)
        03      DELETION
        04      Member search ??
        05      Creation (I don't the difference between function 05 and 01)
        06      Retrieves description of lot of things : byte in pos 17 of 
PARM4 indicates what to get
                (it's the only function I really used)

        0A      Move file ??
        0D      Rename ???

other values are unknown to me.

PARM2 :
-------
        File/library names. Format is :
        bytes  1 to 10 : File Name
        bytes 11 to 20 : Library Name
        bytes 21 to 30 : ???  (Member ?)

PARM3 :
-------
        I can't what it is now. It seems I've never used it.

PARM4 :
-------
        bytes 1 to 16 a SYSPTR (why ?) pointing to the rtequsted information 
when parm1 function '06' used
        byte 17 and 18: a "sub-function" code : When Function 06 (retrieve) is 
used, it indicates which data to return.
        bytes 19 to 28 : mostly a record name, depending on the "sub-function 
code"
        bytes 29 to 38 : mostly a field name, "   "    "    "   "   "   "       
"

other bytes unknown ...

subfunction codes I've found :

        0200    (BDD)Records list (returns a list of all the records format)
        0300    (BDD)Record description. Record name is specified in bytes 19 
to 28
        0400    (BDD)Field description. Record name in bytes 19 to 28 and Field 
name in bytes 29 to 38
        0700    (DSPF/PRTF) Records list and misc. informations (SFL/SFLCTL 
relationship, ...)
        08C5    (DSPF/PRTF)     Record description. Record name is specified in 
bytes 19 to 28
        0900    (BDD) Keys list. Record name is specified in bytes 19 to 28
        0C00    (??) File information ? '*FIRST ' in bytes 19 to 28


That ends the most interesting information I've on QDMROUTE.
If someone is interested, I can send more information on data returned for 
function 06,
but IMHO I think APIs are a better choice if security is a "sine qua non" 
condition (QMDROUTE is *SYSTEM domain program) and direct access to objects (Cf 
Leif book) is a better choice if speed is the main concern.






Jean-Michel Penasse
EXPERIA Europe
jmpenasse@experia.com
+33(0)4.76.67.07.70
www.experia.com