× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Gene Gaunt wrote:

Try MATPRATR option x'18' then back up two bytes to get QTEMP position.

dcl dd data auto char(32) bdry(16);
dcl dd datalength def(data) pos(1) bin(4) init(32);
dcl spcptr nrl@ def(data) pos(17);
dcl sysptr libl@(250) bas(nrl@) pos(17);
dcl spcptr data@ auto init(data);
dcl mspptr work@;
dcl dd qtemppos bas(work@) pos(1) bin(2);

matpratr data@, *, X"18";
subspp work@, nrl@, 2;
brk "1";
pend;


I'm assuming from your code that MATPRATR returns a pointer to the 16 bytes
preceding the actual NRL. Shouldn't your library pointer list (libl@) be
268 to accommodate the total possible list?

The QTEMP position indicator is 18 bytes before the first library (pointer)
in the list. The eight bytes before the first entry is a machine timestamp,
and the 2-byte QTEMP position indicator is 10 bytes before that. The 2-byte
count of total libraries follows that. The 2-byte count of system libraries
precedes the QTEMP position indicator. The H'0000010C' at offset 1DE0
appears to be the count of how many library pointers there can be (H'10C' is
268 - 15 system libraries, 2 product libraries, 1 current library, and 250
user libraries). See the partial *PCS dump below (V5R3):

001DE0 0000010C 00000000 00000000 0009000A 000E0000 00000000 8DBC196B
F9250000
001E00 00008000 00000000 0A573286 C10004FF 00008000 00000000 3B6778EE
920004FF
001E20 00008000 00000000 3C652042 CB0004FF 00008000 00000000 298E90AF
F70004FF

In this library list there are 9 libraries in the system portion of the
list, the QTEMP position indicator is in the 10th position (the first
library in the user portion of the list) which you can see as 000A above,
and there are 14 total libraries (000E) in the list. The timestamp
(8DBC196B F9250000) equates to 1-07/08/28-13:55:04.308. The timestamp is
that last time the NRL was manipulated (via ADDLIBLE, RMVLIBLE, or
CHGSYSLIBL) since the NRL was initially set (the timestamp is initially all
H'00'). The first library pointer is at offset 1E00.

The data is structured the same way for all releases, and, in fact, was the
same on the System/38 (at least as of the last release, release 8). The
only thing that has changed is where the NRL list starts within the PCO. It
changed from offset 832 (H'340') on the System/38 to offset 1296 (H'510') on
V1R1 of OS/400, to offset 7552 (H'1D80') on V5R1, to offset 7680 (H'1E00')
on V5R2 and V5R3, and to offset 8608 (H'21A0') on V5R4. Who knows where it
will be on V6R1?

I've been just adding code to detect the release and change the offset
accordingly, but I'm definitely going to use Gene's suggestion (thanks
Gene).

The real question is will we be able to get to this on V6R1? Currently this
is in the associated space of the *PCS and is in the user domain. Will this
change on V6R1?


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.