On 29-Aug-2014 12:46 -0500, Matt Olson wrote:

I am unable to find any information on

Possibly, created merely as an implementation for the documented QSYS2.DISPLAY_JOURNAL() feature, that underlying support is purposely left undocumented; a subtle implication that the feature can be changed without notification to the user.?

The DW forum for the DB2 for i referred to by Charles, I agree, would be the best place to inquire more about the routine [and the expected and supported parameters\values for an invocation].

Anyone know where the magic place is for the documentation on it. I
found all the input parameters, but no documentation on option
types, but playing around yielded what they mean except for option
type 2.

If they (IBM) intended to document the routine, I have no idea where that might be; nothing but an APAR [and PTF cover letter] can be found searching the web.

However, some features tend to mimic others. Thus one might look to the Retrieve Journal Entry (RTVJRNE) or Retrieve Journal Entries (QjoRetrieveJournalEntries) API to see what inputs those require to perform a similar function, inferring possible similarities.

Option type 2 however is what I want to see the most, as it appears
that will display journal information in a legible way instead of all
the data squished together and/or hieroglyphs if a SQL table.

Are the apparent allusions to gibberish being presented, intending to imply how /normal/ Entry Data (ENTDTA) appears; i.e. the binary data that one might see when viewing the journal entry with Display Journal (DSPJRN), rather than the internal data-typed data being cast to character.? Or perhaps implying something more complicated is being presented, for example, the effects of Minimize Entry Specific Data (MINENTDTA) attribute of the journal?

If the issue is minimized entry data, then the first parameter shown accepting the integer value two, might be effecting the equivalent of having requested *YES for the Format Minimized Data (FMTMINDTA) parameter of the RTVJRNE.?

Here is what I've tried so far:

CALL qsys2.display_journal_entry_info(2, 'libraryname',
'journal_name', 83325238, 'libraryname_of_journal_receiver',
'journal_receiver_name', 'R')

'R' is the type code, and 2 is the magical undocumented number.
83325238 is a journal entry number.

Curious... if the integer number two was tried, what was also tried, from which the returned data is [what I referred to earlier as] /apparent gibberish/; i.e. with two, the data was /human readable/? Were each of the values negative one through positive three attempted as the integer data for the first argument to test the effect?

According to wireshark this is what will yield readable data to
iSeries navigator in order to make a journal record table formatted
(aka readable by humans).

I would expect as a PROCEDURE for which the apparent result is a result-set, there should be no requirement to review the comm to see the effects.? Does not the SQL script feature in iNav present the result set(s) produced by the CALL? Hmm. Of course now that I think on those questions, of course the /binary/ aspects of the data are likely almost as difficult to review via that interface, as when directed instead to a 5250 display; as a UDTF vs as a result-set, the ease of which to encompass each column in a HEX() expression is [unlikely to be directly available from the report writer of the script processor and thus] not an option :-(

This thread ...

Return to Archive home page | Return to MIDRANGE.COM home page