Re: ACCESS to IFS -- MI400

What is the difference between a data space index and a user index ?

Any insights into why the QDLS file system performs slower than the other file 
system ?

Is a stream file a distinct object type also ?

Thanks,

Steve Richter



---------- Original Message ----------------------------------
From: Dave McKenzie <davemck@zbiggroup.com>
Reply-To: mi400@midrange.com
Date:  Wed, 2 Jan 2002 19:26:12 -0800

>The mapping of path names to streamfile objects is implemented as a nested
>hierarchy of DSI's (data space indexes--the same kind of objects that
>constitute database access paths).  There's a root DSI contained in QSYS,
>which has an entry for each top-level directory (/dev, /home, etc.); each
>entry containing the virtual address of the DSI for that directory.  The
>top-level DSI's have entries for the objects in that directory, including
>streamfile objects and DSI's for the second-level sub-directories, and so on,
>and so on.  So there's a separate DSI for every directory and sub-directory
>in the IFS.
>
>Actually, there are two root DSI's in QSYS named "QP0DSystem Root" which has
>entries for the "root" filesystem, and "QP0DHidden System Root" which has
>entries for other filesystems (e.g. QOpenSys).  You can see these by doing
>DMPOB QSYS *LIB and scanning for "Root".  The DSI's have hex type 0C 01.  You
>can dump a DSI with SST using the address in the QSYS dump.  In a given DSI,
>to find the index entries for sub-directories, look for x0C01 in the entry;
>it will be followed by some zeros and the virtual address of the DSI.  Note
>that the names in the DSI entries are in Unicode where each character is
>coded as x00 followed by the ASCII code for the character.
>
>HOWEVER, I fully agree with Simon that normal application programming for IFS
>should use high-level languages and API's.  I think anyone trying to use MI
>for it is, in Donald Rumsfeld's phrase, "out of their mind."  I mentioned the
>above purely for the entertainment of the idly curious.
>
>Remember Donald Knuth's dictum: "Premature optimization is the root of all
>evil"
>
>--Dave
>
>On Wednesday 02 January 2002 13:32, Simon Coulter wrote:
>> My comments for what they are worth:
>>
>> Since the Source/Sink MI instructions are both blocked and a royal pain to
>> work with, isn't MI access to database files generally achieved by calling
>> various QDM* and QDB* "APIs"?  So what's the big deal with calling a
>> program to access the IFS?  Using pointers and based storage will allow
>> you to access all the data.
>>
>> If you want speed then use C.  It will be at least as fast as MI access,
>> possibly faster, has direct support for the IFS structure and APIs, and
>> you can embed most MI instructions in C due to support for MI built-ins.
>> (Actually, you could probably have written the code to do this in the time
>> it's taken to experiment.)
>>
>> IFS files are Byte Stream Spaces which are object type X'1E'.  The
>> documentation for RSLVSP allows that object type which implies that you
>> can resolve to an IFS object.  BUT the object name supported by RSLVSP is
>> restricted to 30 characters.  Does that imply that IFS objects have an
>> additional layer imposing the hierarchy?  Much like QDLS where the
>> hierarchy resolves to a single-level-store object.
>>
>> So, if you could convert the IFS path to the underlying *STMF or *DSTMF
>> (since the images in question are on optical disk) then you should be able
>> to resolve to it.  If you can resolve to it you should be able to take a
>> space pointer to it.  If you can set a space pointer then you can access
>> the data since a *STMF is a much simpler object than a database file.
>>
>> Does anyone know if this path to object conversion assumption is valid?
>> If so, does anyone know where the conversion table is located or an API
>> (probably undocumented) to perform the conversion?
>>
>> Regards,
>> Simon Coulter.
>>
>> --------------------------------------------------------------------
>>    FlyByNight Software         AS/400 Technical Specialists
>>    http://www.flybynight.com.au/
>>
>>    Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
>>    Fax:   +61 3 9419 0175   mailto: shc@flybynight.com.au   \ /
>>                                                              X
>>                  ASCII Ribbon campaign against HTML E-Mail  / \
>> --------------------------------------------------------------------
>
>_______________________________________________
>This is the MI Programming on the AS400 / iSeries (MI400) mailing list
>To post a message email: MI400@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/mi400
>or email: MI400-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/mi400.
>
>