Ansicht
Dokumentation
13308 - errors on APYJRNCHGX
ROGBILLS - Synchronize billing plans PERFORM Short ReferenceThis documentation is copyright by SAP AG.
errors on APYJRNCHGX
Hi Tom,good that you are testing this - normally this is not tested at all!!!
I would suggest, that you test at least everything except the
*LASTSVAE, *LASTRESTORE or so! Becuase of SAP storing the JRNRCVs in
a different library as the database this never works.
I would use a procedure similar to the follwoing one:
o - Investigate what *JRNRCVs are
necessary for the recovery-timeframe:
o DSPLIB R3SIDJRN
o Then search with option 8 the
start point of time of each *JRNRCV:
o Search with option 8 for that
start point of time, that is the last one before the backup
(QSQJRNfirst) and search
o for the last one before the crash
point of time (QSQJRNlast). These are your 2 *JRNRCV, that will be
used later
o on for the first and the last
*JRNRCV.
o (This can be done already during
the RSTLIB in order to save time!)
o - Now the "old" Journalreceiver have
to reattached to thew new restored Journal in lib R3SIDDATA with the
o command WRKJRN + Enter
o Then you should select in the next
screen QSQJRN as journal and R3SIDDATA as Lib. Use Option 9 in order
o to reattach the old receiver to
the journal. Otherwise the command APYJRNCHG will fail afterwards!!!
o (This can be done already during
the RSTLIB in order to save time?)
o - Find out the from-sequencenumber:
o DSPJRN JRN(R3SIDDATA/QSQJRN)
RCVRNG(R3SIDJRN/QSQJRNfirst R3SIDJRN/QSQJRNlast)
FROMTIME(backup time)
o Scroll as far, as the backup
starts. When you did a "save while active" backup, please use the
sequence-number
o of the F Code SS, that indicates
the commit point during your backup!
o - Find out the to-sequencenumber:
o DSPJRN JRN(R3SIDDATA/QSQJRN)
RCVRNG(R3SIDJRN/QSQJRNlast R3SIDJRN/QSQJRNlast)
FROMTIME(crash time)
o Select one sequencenumber, that is
in the timeframe before your crash!
o - Issuing of the APYJRNCHG:
o SBMJOB CMD(APYJRNCHG JRN
(R3SIDDATA/QSQJRN) FILE((R3SIDDATA/*ALL *ALL))
RCVRNG(R3SIDJRN/QSQJRNfirst R3SIDJRN/QSQJRNlast)
FROMENT(from entry) TOENT(to entry) CMTBDY(*YES))
JOB(APYJRNCHG) LOG(*JOBD *JOBD *MSG) JOBMSGQFL(*PRTWRAP)
But, your problem looks a bit more like a IBM problem, that the
journal apply insite crashes. I would perhaps try my version and if
it stays, open a PMR at IBM.
Regards
Volker
e-mail: volker.gueldenpfennig "at" easymarketplace.de
web: www.easymarketplace.de
--- In DoNotReply@consolut.eu, Rooyen Tom van <tvroZo...> wrote:
> Hi all,
>
> While testing the APYJRNCHGX for a forward recovery command we get
errors.
>
> The situation we test is:
>
> * Full Save database SAVACT(*LIB) (via BRMS)
> * update the database
> * recover database on other server and associate the journal
receivers
> with the database updates with the journal
> * try to recover the updates with APYJRNCHGX
>
> the command we use is this:
>
> ===> APYJRNCHGX JRN(R3P44DATA/QSQJRN) FILE((R3P44DATA/*ALL))
> RCVRNG(R3P44JRN/QS
> QJRN1000 R3P44JRN/QSQJRN1000) FROMENT(*LASTSAVE) TOENT(*LAST) CMTBDY
(*YES)
>
>
> We also tried *LASTRST
>
>
>
> the error we get is the following:
>
> Message ID . . . . . . : MCH5601 Severity . . . . . . . :
40
>
> Message type . . . . . : Escape
>
> Date sent . . . . . . : 12/03/04 Time sent . . . . . . :
11:17:17
>
>
>
> Message . . . . : Template value not valid for instruction.
>
> Cause . . . . . : The location of the value is template with an
offset to
>
> field in bytes X'0030', an offset in field in bits X'0000', a
length of
>
> field of 8, and an instruction operand number of 1. The reason
code is
>
> X'0000'. If the reason code is X'0000', a reason code may not be
> available.
>
> Message ID . . . . . . : MCH5601 Severity .
> Date sent . . . . . . : 12/03/04 Time sent
> Message type . . . . . : Escape
> CCSID . . . . . . . . : 65535
>
> From program . . . . . . . . . : #joreten
> Instruction . . . . . . . . : 0019C8
>
> To program . . . . . . . . . . : QJOREAPY
> To library . . . . . . . . . : QSYS
> Instruction . . . . . . . . : 08B4
>
>
> I have found an apar related to this problem MA26422 which
specifies the
> same error, However i do not think that this applies in our
situation,
> furthermore, the ptf fix specified in the apar we already have on
our
> systems so the dump should not occur.
>
> Does anyone know of issues with this command, or other restrictions
for
> using it?
>
>
> kind regards,
>
> Tom
Durban Tours - Südafrika Safari
BAL Application Log Documentation ROGBILLS - Synchronize billing plans
This documentation is copyright by SAP AG.
Length: 5459 Date: 20240419 Time: 163145 sap01-206 ( 3 ms )
