Re: ACCESS to IFS

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  / \
> --------------------------------------------------------------------