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;
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.
if GetPath(Path :%size(Path) :ESD_8.ParentFID) = NullPtr;
ErrnoPtr = GetErrno();
dsply ('Path not available due to CPE' +
%subst(%editc(Errno :'X') :7 :4)) ' ' Wait;
else;
PathText = %str(%addr(Path));
dsply ('Path was ' + %subst(PathText :1 :42)) ' ' Wait;
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;
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)
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
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
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
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
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 information—that 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)
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:
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)
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:
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));
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 object—in 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.
if GetPath(Path :%size(Path) :ESD_8.ParentFID) = NullPtr;
ErrnoPtr = GetErrno();
dsply ('Path not available due to CPE' +
%subst(%editc(Errno :'X') :7 :4)) ' ' Wait;
else;
PathText = %str(%addr(Path));
dsply ('Path was ' + %subst(PathText :1 :42)) ' ' Wait;
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 object—in 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;
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...
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;
endsl;
endif;
enddo;
When more entries are available—that 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:
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
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
as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1
Bruce Vining is president and co-founder of Bruce Vining Services, LLC, a firm providing contract programming and consulting services to the System i community. He began his career in 1979 as an IBM Systems Engineer in St. Louis, Missouri, and then transferred to Rochester, Minnesota, in 1985, where he continues to reside. From 1992 until leaving IBM in 2007, Bruce was a member of the System Design Control Group responsible for OS/400 and i5/OS areas such as System APIs, Globalization, and Software Serviceability. He is also the designer of Control Language for Files (CLF).A frequent speaker and writer, Bruce can be reached at
MC Press books written by Bruce Vining available now on the MC Press Bookstore.
 |
||
 |
|
IBM System i APIs at Work Leverage the power of APIs with this definitive resource. List Price $89.95 Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online