Journal Receivers Again
Thad Rizzi
current attached receiver) that are associated with a particular
journal using CL? I am doing a DSPOBJD but I get all receivers in a
library.
Any help is appreciated.
Thad Rizzi
Saml
Sam
"Thad Rizzi" <thad_...@hotmail.com> wrote in message
news:1193433222.1...@v23g2000prn.googlegroups.com...
Saml
Tried GO CMDJRN I suppose?
I know it can be done with an API because I did it. And I think a coworker
did something similar using an OUTFILE. But this doesn't really answer your
question, does it. Sorry.
Sam
"Thad Rizzi" <thad_...@hotmail.com> wrote in message
news:1193433222.1...@v23g2000prn.googlegroups.com...
CRPence
WRKJRNA JRN( theJrn ) OUTPUT(*print) DETAIL(*RCVDIR)
dspsplf qpdspjna splnbr(*last)
or
WRKJRNA JRN( theJrn ) /* F15=Work with receiver directory */
A CLP can not call the procedure in QJOURNAL *SRVPGM to get the
information but a CLLE can. The following link gives documentation for
the Retrieve Journal Information (QjoRetrieveJournalInformation) API:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/apis/QJORJRNI.htm
It seems the Key=1 request will return the receiver directory
information; refer to the /Key 1 Output Section/ at the same URL for the
return data. It seems that using the noted API, one could code to
provide the missing function, per a CPF69A7, for a request to:
WRKJRNA JRN() OUTPUT(*OUTFILE) DETAIL(*RCVDIR) OUTFILE(QTEMP/RCVDIR)
The following example can be a starting point for accessing the data
returned in the Key 1, but large receiver chains could likely blow the
32K maximum CL variable for the return data; a better option is to
either always use a user space or check the bytes information against a
smaller size, and use a user space as output when beyond some threshold
[the /smaller size/ deemed reasonable for the CLP automatic storage;
i.e. the Dcl &RcvVar *char declared size]. The following test CL module
source hard codes QAUDJRN and one variable length record specification
request for only the Key=1 data:
/* */
/* CRTCLMOD MODULE(QGPL/RTVJRNDIR) SRCFILE(QGPL/QCLSRC) */
/* SRCMBR(RTVJRNDIR) DBGVIEW(*ALL) */
/* REPLACE(*YES) */
/* */
/* CRTPGM PGM(QGPL/RTVJRNDIR) MODULE(QGPL/RTVJRNDIR) */
/* BNDSRVPGM(QJOURNAL) ACTGRP(*NEW) */
/* REPLACE(*YES) */
/* */
PGM
dcl &RcvVar *char 32000
dcl &RcvLen *uint ( 4 ) value(32000)
dcl &QJrn *char 20 value('QAUDJRN QSYS ')
dcl &Rcvfmt *char 8 value('RJRN0100')
/* Dec Hex Description of Variable length record key request */
/* 0 0 BINARY(4) Length of variable length record */
/* 4 4 BINARY(4) Key */
/* 8 8 BINARY(4) Length of data */
/* 12 C CHAR(*) Data */
dcl &RtvInf *char 20 /* effectively only 16 */+
value(x'0000000100000010000000010000000000000000')
/* Data map: NbrVlnR|Varlen |KeyRqsd|DtaLen |NoData | */
dcl &ErrCde *char 8 value(x'0000000000000000')
dcl &BytRtn *uint ( 4 ) stg(*defined) defvar(&RcvVar 01)
dcl &BytAvl *uint ( 4 ) stg(*defined) defvar(&RcvVar 05)
dcl &KeyOfs *uint ( 4 ) stg(*defined) defvar(&RcvVar 09)
dcl &KeyAra@ *ptr
dcl &KeyAra *char ( 20) stg(*based) basptr(&KeyAra@)
callprc PRC('QjoRetrieveJournalInformation') +
PARM( (&RcvVar *BYREF) (&RcvLen *BYREF) +
(&QJrn *BYREF) (&RcvFmt *BYREF) +
(&RtvInf *BYREF) (&ErrCde *BYREF) ) RTNVAL(*NONE)
chgvar &KeyAra@ (%addr(&RcvVar))
chgvar %ofs(&KeyAra@) (%ofs(&KeyAra@) + &KeyOfs)
dmpclpgm
dspsplf qppgmdmp splnbr(*last)
dltsplf qppgmdmp splnbr(*last)
ENDPGM
Regards, Chuck
--
All comments provided "as is" with no warranties of any kind
whatsoever and may not represent positions, strategies, nor views of my
employer
Thad Rizzi
> The following CL requests:
> WRKJRNA JRN( theJrn ) OUTPUT(*print) DETAIL(*RCVDIR)
> dspsplf qpdspjna splnbr(*last)
> or
> WRKJRNA JRN( theJrn ) /* F15=Work with receiver directory */
>
> A CLP can not call the procedure in QJOURNAL *SRVPGM to get the
> information but a CLLE can. The following link gives documentation for
>
> - Show quoted text
Great, thanks!
Thad Rizzi
> OK, I just noticed you said in CL. WRKJRNA isn't going to help much...
> Tried GO CMDJRN I suppose?
>
> I know it can be done with an API because I did it. And I think a coworker
> did something similar using an OUTFILE. But this doesn't really answer your
> question, does it. Sorry.
>
> Sam
>
>
> news:1193433222.1...@v23g2000prn.googlegroups.com...
>
>
>
> > Is there an way to get a list of all journal receivers (not just the
> > current attached receiver) that are associated with a particular
> > journal using CL? I am doing a DSPOBJD but I get all receivers in a
> > library.
>
> > Any help is appreciated.
>
>
> - Show quoted text -
I need a file built containing all receivers for a particular
journal. I am going to look at some API's and the response Chuck
sent.
Jonathan Ball
If you're comfortable using the APIs, that's probably a better way to
go. However, you might want to consider looking at the journal itself
to get this information.
The first entry in every journal receiver is an entry with jrncde =
'J', enttyp = 'PR' which identifies the prior receiver (similarly, the
last entry in every receiver identifies the next receiver; jrncde =
'J', enttyp = 'NR'). So, in a CL program you could iteratively issue
the RTVJRNE command against the journal. The first time you would get
the PR entry in the currently attached receiver. Using that entry,
you could then work backward to the beginning of the currently
attached receiver range.
pgm
dcl var(¬found) type(*lgl)
dcl var(&entry) type(*char) len(145)
dcl var(&rcvr) type(*char) len(10)
dcl var(&rcvrlib) type(*char) len(10)
rtvjrne jrnlib/jrnname jrncde(j) enttyp(pr) rtnjrne(&entry)
dountil cond(¬found)
/* do something with the receiver name retrieved, e.g. insert +
into a database table containing all attached receivers */
chgvar var(&rcvr) value(%sst(&entry 126 10))
chgvar var(&rcvrlib) value(%sst(&entry 136 10))
rtvjrne jrnlib/jrnname jrncde(j) enttyp(pr) rtnjrne(&entry) +
rcvrng(&rcvrlib/&rcvr &rcvrlib/&rcvr)
monmsg msgid(cpf9801) exec(chgvar var(¬found) value('1'))
enddo
return
endpgm
Note that you need to monitor for the receiver specified in the
receiver range parameter not being on the system.
CRPence
would not include the full list of receivers, because the break in the
chain would manifest itself as the monitored CPF9801 condition. Such a
break is normal for a restore of a partial chain; i.e. 'broken' in this
case is not always an abnormal condition. Thus if the desire is to be
able to list all receivers that were associated with that journal when
the CLP runs, irrespective of the journal status or receiver chain, the
WRKJRNA or the API from QJOURNAL must be used.
FWiW: The given CLP source is written to assume that the first
RTVJRNE request is against the RCVRNG(*CURRENT). To avoid such an
assumption, RCVRNG(*CURRENT) should be coded explicitly. Although other
parameters could also result in a failed assumption for not having been
explicitly specified, the RCVRNG is IMO the most likely to have had its
default changed. Another which may be worth coding, is SEARCH(*ASCEND),
since the ideal search order is oldest to newest; some systems might
have a default assumption that the newest entries are to be searched
first when using that command.