The API Corner: The Case of the Missing Stream Files, Part II PDF Print E-mail
Programming - APIs
Written by Bruce Vining   
Thursday, 20 October 2011 00:00

Support MC Press - Visit Our Sponsors

Forums Sponsor



Search Sponsor



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();                                 


             PathText = %str(%addr(Path));                          

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



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;  


             PathText = %str(%addr(Path));                          

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



The second correction is also related to an error path. Near the end of the program are these two statements:





A LEAVE operation should be inserted as shown below:






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.



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



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)));



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;  


             PathText = %str(%addr(Path));                          

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



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;                          



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';                                      


            when RcvVarHdr.QjoNbrER = 0;                              

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


                 JrnEtoRtvKeyHdrDtaPtr = SavSeqNoPtr;                 

                 GetByStrSeqNo.StrSeqNoNbr =                          

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








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-              

DSPLY  using UNLINKFILE                           

DSPLY  Path was /MyPlayDir/MyImbeddedDir          


DSPLY  Job QPADEV0005/VINING/098346 removed *STMF 

DSPLY  tempfile.txt                               

DSPLY  at 2011-09-05-              

DSPLY  using QCMD                                 

DSPLY  Path not available due to CPE3025     


DSPLY  Job QPADEV0005/VINING/098346 removed *DIR

DSPLY  tempdir                                  

DSPLY  at 2011-09-05-            

DSPLY  using QCMD                               

DSPLY  Path was /MyPlayDir


As usual, if you have any API questions, send them to me at 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

Bruce Vining
About the Author:

Bruce Vining is president and co-founder of Bruce Vining Services, L.L.C., a firm providing contract programming and consulting services to the System i community ( He began his career in1979 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 IBM System i APIs at Work

Master APIs with this in-depth, example-rich exploration into these powerful tools.

List Price $89.95
Now On Sale
Last Updated on Thursday, 20 October 2011 15:55
User Rating: / 1

Related Articles: