The API Corner The Case of The Missing Stream Files Part II

The API Corner: The Case of the Missing Stream Files, Part II
Written by Bruce Vining

Thursday, 20 October 2011 00:00 - Last Updated Thursday, 20 October 2011 15:55
Process the data returned by the QjoRetrieveJournalEntries API.
Last month, in " The Case of the Missing Stream Files ," we saw how to call the
QjoRetrieveJournalEntries API, documented
here
, in order to access all journal entries associated with the removal of an IFS link from a
directory. The links removed might be *STMFs, *SYMLNKs, *DIRs, etc. As the goal of the
project is to determine who removed the links, today we'll look at how to process the results of
calling the QjoRetrieveJournalEntries API.
In terms of this processing, there are two corrections to the program shown last month. In one
of the error paths, the program collects error-related information but, due to a copy/paste
omission on my part, neglects to display the error that has been encountered. To correct this
oversight, locate the following code in the sample program (and don't worry about what the
code is doing, we'll get to that shortly).
if GetPath(Path :%size(Path) :ESD_8.ParentFID) = NullPtr;
ErrnoPtr = GetErrno();
else;
1 / 20
PathText = %str(%addr(Path));
dsply ('Path was ' + %subst(PathText :1 :42)) ' ' Wait;
endif;
In order to display the error information, insert the DSPLY operation shown below in bold.
dsply ('Path not available due to CPE' +
%subst(%editc(Errno :'X') :7 :4)) ' ' Wait;
else;
2 / 20
endif;
The second correction is also related to an error path. Near the end of the program are these
two statements:
other;
endsl;
A LEAVE operation should be inserted as shown below:
other;
3 / 20
leave;
endsl;
The earlier article also included an implicit assumption that when we started journaling we only
wanted to journal existing subdirectories of the /MyPlayDir directory. If, within your application
environment, you are creating new subdirectories as part of your ongoing operations, you will
want to specify INHERIT(*YES) when using the STRJRN command (in addition to the
SUBTREE(*ALL) parameter). INHERIT(*YES) indicates that as new objects are created, they
are to inherit the journal options that are in effect for the parent directory. In our case, any new
subdirectories of /MyPlayDir are to inherit the journaling characteristics of the /MyPlayDir
directory. To enable this inheritance, if you are already journaling subdirectories of /MyPlayDir,
you can use the following commands.
ENDJRN OBJ(('/MyPlayDir')) SUBTREE(*ALL)
STRJRN OBJ(('/MyPlayDir')) JRN('/qsys.lib/vining.lib/ifsjrn.jrn') +
SUBTREE(*ALL) INHERIT(*YES)
4 / 20
With the above out of the way, let's now look at our processing of the journal entries.
When we left off last month, the program had just entered a DOU loop where the
QjoRetrieveJournalEntries API was called. The API call requests that all journal entries that are
associated with link removals, and that will fit within the allocated 10,000,000 bytes addressed
by the pointer variable RcvVarPtr, are to be returned. When the API returns control to the
DSPFRMV program, the program can immediately access the header information returned by
virtue of the data structure RcvVarHdr being BASED on the pointer variable RcvVarPtr and
RcvVarHdr being defined LIKEDS the QSYSINC-provided data structure QJO0100H. The
QJO0100H data structure, and our immediate use of this header structure, is shown below.
DQJO0100H DS
D* Qjo RJNE0100 Hdr
D QJOBRTN03 1 4B 0
D* Bytes Returned
D QJOOFJE 5 8B 0
D* Offset First Jrn Entry
5 / 20
D QJONBRER 9 12B 0
D* Number Entries Retreived
D QJOCH 13 13
D* Continuation Handle
EntHdrPtr = RcvVarPtr + RcvVarHdr.QjoOfJE;
To access the first journal entry returned, DSPFRMV takes the address of the receiver variable
(RcvVarPtr) and adds to this the Offset to the first journal entry returned in the receiver variable
(RcvVarHdr.QjoOfJE). The resulting value is then stored in pointer variable EntHdrPtr. The
EntHdrPtr is defined as the basing pointer for data structure EntHdr (entry header), where
EntHdr is defined LIKEDS the QSYSINC-provided data structure QJO00JEH. Setting EntHdrPtr
as described above provides direct access to QJO00JEH entry header information related to
the first journal entry returned by the API. The definition for QJO00JEH is this:
DQJO00JEH DS
6 / 20
D* Qjo RJNE0100 JE Hdr
D QJODNJH 1 4B 0
D* Dsp Next Jrn Hdr
D QJODNVI 5 8B 0
D* Dsp NVI
D QJODESD 9 12B 0
D* Dsp Entry Specific Data
D QJOPH 13 16U 0
D* Ptr Handle
D QJOSNBR 17 36
D* Seq Number
D QJOJC00 37 37
7 / 20
D* Jrn Code
D QJOET 38 39
D* Entry Type
D QJOTS 40 65
D* Time Stamp
D QJOJN02 66 75
D* Job Name
D QJOUN 76 85
D* User Name
D QJOJNBR 86 91
D* Job Number
8 / 20
D QJOPGMN 92 101
D* Program Name
D QJOBJECT 102 131
D* Object
Having established addressability to the first returned journal entry, DSPFRMV now enters a
FOR loop to process all entries returned. The FOR loop is constrained by the variable
RcvVarHdr.QjoNbrJR, the number of entries returned in the current receiver variable.
Related to each returned journal entry, there is general information, found in the data structure
EntHdr.Hdr.QJO00JEH, and entry-specific informationthat is, information specific to the
journal type returned. In the case of DSPFRMV, the journal entries being returned are all of type
B4 (due to the setting of GetByJrnType.JrnTypes to 'B4' prior to calling the
QjoRetrieveJournalEntries API), and the entry-specific data associated with B4 entries is
defined in DSPFRMV as shown below.
dESD_8 ds qualified based(ESD_Ptr)
9 / 20
d ObjFID 16
d ParentFID 16
d NameDsp 10u 0
d ObjJID 10
d ObjType 7
To see the layout of the entry-specific data returned for a specific journal entry type, and the
meaning of the various fields returned, you can use the Journal Entry Information Finder, which
is found here . To review B4 entry type information within the Finder, enter B4 under Search by
letter, press Go, and then click the variable width portion of the B4 entry type.
To access this entry-specific data, DSPFRMV takes the address of the current journal entry
(EntHdrPtr) and adds to this the Displacement to the entry specific data (EntHdr.Hdr.QjoDESD).
The resulting value is then stored in pointer variable EntSpcDtaPtr (Entry specific data pointer).
Note that APIs use the terms Offset and Displacement in very specific ways. An offset is relative
to the start of the receiver variable. A displacement (also sometimes referred to as length) is
relative to the data structure currently being processed. So when using Offset to the first journal
entry (QjoOfJE), the offset is added to RcvVarPtr, and when using Displacement to the entry
specific data (QjoDESD), the displacement is added to EntHdrPtr. This access to the
entry-specific data is done with the following statement:
10 / 20
EntSpcDtaPtr = EntHdrPtr + EntHdr.Hdr.QjoDESD;
The EntSpcDtaPtr is defined as the basing pointer for data structure EntSpcDta (Entry specific
header), where EntSpcDta is defined LIKEDS the QSYSINC-provided data structure
QJOJEESD (Entry specific data). Setting EntSpcDtaPtr as done above provides access to
QJOJEESD information related to the journal entry currently being processed. The data defined
by data structure ESD_8 can then be found starting at field EntSpcDta.Hdr.QJOESD (Entry
specific data). To access the ESD_8 data, the program assigns the basing pointer ESD_Ptr to
the address of EntSpcDta.Hdr.QJOESD as shown below.
ESD_Ptr = %addr(EntSpcDta.Hdr.QJOESD);
Having established addressability to the ESD_8 data structure, DSPFRMV now accesses the
name of the link that has been removed. The name of the link can be found in the data structure
ObjNameDta and accessed using the Name displacement (NameDsp) found in ESD_8. This
data structure, and the access to it, is shown below.
dObjNameDta ds based(ObjNameDtaPtr)
11 / 20
d ObjNameLen 10u 0
d ObjNameCCSID 10i 0
d ObjNameCntryID 2a
d ObjNameLangID 3a
d 3a
d ObjName 640c ccsid(1200)
ObjNameDtaPtr = ESD_Ptr + ESD_8.NameDsp;
As IFS link names can contain a variety of different alphabets, IFS names are returned in
Unicode and, for the last several releases, specifically UTF-16 (CCSID 1200). An admittedly
simplistic approach to converting the Unicode link name to the job CCSID currently in use for
DSPFRMV is done using the following:
12 / 20
if ObjNameCCSID = 1200;
Object = %char(%subst(ObjName :1 :%div(ObjNameLen :2)));
endif;
At this point, DSPFRMV has the necessary information to display the job that removed the link,
the type of link, the name of the link, the time the link was removed, and the program removing
the link. This is done with the code below.
dsply ('Job ' + %trimr(EntHdr.Hdr.QjoJN02) + '/' +
%trimr(EntHdr.Hdr.QjoUN) + '/' +
%trimr(EntHdr.Hdr.QjoJNbr) +
' removed ' + %trimr(ESD_8.ObjType));
dsply (%subst(Object :1 :52));
13 / 20
dsply ('at ' + EntHdr.Hdr.QjoTS);
dsply ('using ' + EntHdr.Hdr.QjoPgmN);
The ESD_8 data structure, in addition to providing a displacement to the removed links name
(NameDsp) and the type of removed object (ObjType), provides a File Identifier to the directory
in which the removed object was located. This field, ParentFID, is a 16-byte identifier that
uniquely identifies an IFS objectin this case, the directory of the removed object. The Get
Path Name of Object from Its File ID API, Qp0lGetPathFromFileID documented here , returns
an absolute path to the identified object and is called so that the DSPFRMV program can
display a path to the removed object as shown below.
dsply ('Path not available due to CPE' +
%subst(%editc(Errno :'X') :7 :4)) ' ' Wait;
else;
14 / 20
endif;
The Qp0lGetPathFromFileID API, prototyped in DSPFRMV as GetPath, will return a null pointer
if the API is unable to determine a path to the File ID (ESD_8.ParentFID). DSPFRMV, if an error
is found, displays text identifying an error message in QCPFMSG that explains the error. The
most likely cause of an error will be that the parent directory has been removed. In this case,
the message "Path not available due to CPE3025" will be DSPLYed. If no error is found,
DSPFRMV will display the first 32 characters of a path to the removed objectin this case, a
message such as "Path was /MyPlayDir/MyImbeddedDir." A future article will look at how
DSPFRMV can display the path even if the parent directory has been removed.
Having displayed all of the pertinent information about the removed object, DSPFRMV then
saves the journal sequence number related to the current journal entry (this may be used later
in the program), establishes addressability to the next returned journal entry, and starts
processing the next returned journal entry with these statements:
LstSeqNoChr = EntHdr.Hdr.QjoSNbr;
15 / 20
EntHdrPtr += EntHdr.Hdr.QjoDNJH;
endfor;
When all journal entries in the receiver variable have been processed, DSPFRMV determines
whether more journal entries are available by testing the continuation handle (QjoCH) found in
the receiver variable header (RcvVarHdr) and, if so, what action should be taken. Note that this
variable, RcvVarHdr.QjoCH, is also the variable used to condition the DOU in which the
QjoRetrieveJournalEntries API is called.
if RcvVarHdr.QjoCH = '1';
select;
when RcvVarHdr.QjoNbrER = 0;
// RcvVar not large enough to return even one entry...
16 / 20
dsply 'Unable to access journal entries' ' ' Wait;
leave;
when X > RcvVarHdr.QjoNbrER;
// Get next set of journal entries
JrnEtoRtvKeyHdrDtaPtr = SavSeqNoPtr;
GetByStrSeqNo.StrSeqNoNbr =
(%dec(LstSeqNoChr :20 :0) + 1);
iter;
other;
leave;
17 / 20
endsl;
endif;
enddo;
When more entries are availablethat is, RcvVarHdr.QjoCH = '1'DSPFRMV determines

whether the previously returned journal entries were successfully processed. If the number of
previously returned entries (RcvVarHdr.QjoNbrER) is 0, then the receiver variable is not
sufficiently large to process any entries and the DOU loop is left after displaying an appropriate
message to the user. This situation is highly unlikely as the DSPFRMV receiver variable is sized
at 10,000,000 bytes. If a non-zero number of journal entries were previously returned, and
successfully processed as the FOR loop control variable X is greater than the number of entries
returned (RcvVarHdr.QjoNbrER), DSPFRMV sets the starting journal sequence number for the
next set of journal entries to be returned by the QjoRetrieveJournalEntries API to the value last
processed sequence number plus 1 and iterates through the controlling DOU loop. This
re-iteration will cause the QjoRetrieveJournalEntries API to be called for the next set of journal
entries. If a non-zero number of journal entries were previously returned, but not successfully
processed, the OTHER operation will be true and the program will leave the current DOU. This
last situation should not occur as only an RPG run-time error should cause the FOR loop to be
left prematurely, in which case you would cancel the program.
After all journal entries have been processed (that is, RcvVarHdr.QjoCH = '0') the controlling
DOU is exited, the storage associated with the receiver variable is de-allocated, and the
program ends. Sample output of the program might be like this:
18 / 20
DSPLY Job QPADEV000F/VINING/095249 removed *STMF
DSPLY unlinkedbypgm.txt
DSPLY at 2011-09-04-11.11.14.734704
DSPLY using UNLINKFILE
DSPLY Path was /MyPlayDir/MyImbeddedDir
DSPLY Job QPADEV0005/VINING/098346 removed *STMF
DSPLY tempfile.txt
DSPLY at 2011-09-05-09.45.39.068080
DSPLY using QCMD
DSPLY Path not available due to CPE3025
19 / 20
DSPLY Job QPADEV0005/VINING/098346 removed *DIR
DSPLY tempdir
DSPLY at 2011-09-05-09.46.28.639536
DSPLY using QCMD
DSPLY Path was /MyPlayDir
As usual, if you have any API questions, send them to me at bvining@brucevining.com . I'll see
what I can do about answering your burning questions in future columns.
as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1
20 / 20

The API Corner The Case of The Missing Stream Files Part II

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

The API Corner The Case of The Missing Stream Files Part II

Diunggah oleh

Hak Cipta:

Format Tersedia

The API Corner: The Case of the Missing Stream Files, Part II

Written by Bruce Vining

Process the data returned by the QjoRetrieveJournalEntries API.

if GetPath(Path :%size(Path) :ESD_8.ParentFID) = NullPtr;

dsply ('Path was ' + %subst(PathText :1 :42)) ' ' Wait;

if GetPath(Path :%size(Path) :ESD_8.ParentFID) = NullPtr;

dsply ('Path not available due to CPE' +

%subst(%editc(Errno :'X') :7 :4)) ' ' Wait;

dsply ('Path was ' + %subst(PathText :1 :42)) ' ' Wait;

A LEAVE operation should be inserted as shown below:

ENDJRN OBJ(('/MyPlayDir')) SUBTREE(*ALL)

STRJRN OBJ(('/MyPlayDir')) JRN('/qsys.lib/vining.lib/ifsjrn.jrn') +

D* Qjo RJNE0100 Hdr

D* Offset First Jrn Entry

D* Number Entries Retreived

EntHdrPtr = RcvVarPtr + RcvVarHdr.QjoOfJE;

D* Qjo RJNE0100 JE Hdr

D* Dsp Next Jrn Hdr

D* Dsp Entry Specific Data

D QJOBJECT 102 131

dESD_8 ds qualified based(ESD_Ptr)

EntSpcDtaPtr = EntHdrPtr + EntHdr.Hdr.QjoDESD;

d ObjName 640c ccsid(1200)

ObjNameDtaPtr = ESD_Ptr + ESD_8.NameDsp;

Object = %char(%subst(ObjName :1 :%div(ObjNameLen :2)));

dsply ('Job ' + %trimr(EntHdr.Hdr.QjoJN02) + '/' +

' removed ' + %trimr(ESD_8.ObjType));

dsply (%subst(Object :1 :52));

dsply ('at ' + EntHdr.Hdr.QjoTS);

dsply ('using ' + EntHdr.Hdr.QjoPgmN);

if GetPath(Path :%size(Path) :ESD_8.ParentFID) = NullPtr;

dsply ('Path not available due to CPE' +

%subst(%editc(Errno :'X') :7 :4)) ' ' Wait;

dsply ('Path was ' + %subst(PathText :1 :42)) ' ' Wait;

// RcvVar not large enough to return even one entry...

dsply 'Unable to access journal entries' ' ' Wait;

when X > RcvVarHdr.QjoNbrER;

// Get next set of journal entries

(%dec(LstSeqNoChr :20 :0) + 1);

When more entries are availablethat is, RcvVarHdr.QjoCH = '1'DSPFRMV determines

DSPLY Job QPADEV000F/VINING/095249 removed *STMF

DSPLY using UNLINKFILE

DSPLY Path was /MyPlayDir/MyImbeddedDir

DSPLY Job QPADEV0005/VINING/098346 removed *STMF

DSPLY using QCMD

DSPLY Path not available due to CPE3025

DSPLY Job QPADEV0005/VINING/098346 removed *DIR

DSPLY using QCMD

DSPLY Path was /MyPlayDir

Anda mungkin juga menyukai