On 29-Aug-2014 12:46 -0500, Matt Olson wrote:
I am unable to find any information on
QSYS2.DISPLAY_JOURNAL_ENTRY_INFO.
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 :-(
midrange.com
