T24: Problem authorizing bed MG records

[Igor Micev]

Hi All,

I try to resolve the following problem:

I made one subroutine which aim was previously to create records in
one local application. I used UPDATE.JOURNAL() function to authorize
the records. Then I decided to extend its usage, i.e to use it from
version's authorization routine. I made a call to the subroutine in
one of the authorization routines of one MG version, and and it didn't
pass. I noticed that the problem is UPDATE.JOURNAL() and I solved it.
Now I have two MG records that are in NAU file, but cannot enter them,
even cannot see them, but they are listed with MG E.

There are MG.BALANCES records created for those two MG contracts, but
no MG.BALANCES.SAVE records. Obviously it hasn't finished with
updating some other tables.
This two records are sure to make the COB unsuccessful, and we don't
want to return the environment to the last backup.
Can someone propose a way how to authorize those two records, or
reverse them?
The only idea that has just sprouted up for now is using OFS with
operation A, but should I use this option, or better ways are
available to resolve this problem

Any new ideas, ways?

Thanks
Igor

[Saravanan S]

Hi Igor,
   
   i presume the problem is
"you are not able to use 'S' function for the 2 problematic MG contracts. but when you execute the LIST command  from jbase level  , 2 mg contracts are listed under exception
."
now  you need to REVERSE the Mgs listing..

is this the problem?

and i dont think that COB will fatal due to this NAU MG records...  If it is  new MGs - UNAUTH PROCESSING  will put in IHLD and if they are rolled over contracts, then cob will itself delete the INAU records and also MG.BALANCES will refrain to its original position .

also, can you please double check that you are trying to view the INAU MG in its respective company.

thanks.
Saravanan

[VK]

Hi,
never use JOURNAL.UPDATE inside a VERSION-level routines. It will
commit the transaction which is expected to be committed later by core
T24.

[Igor Micev]

Hi Sarvanan,

Yes I cannot see ( 'S' ) and input ( 'I' ) them.
We had a problem with two other similar MG records, but weren't able
to detect the reasons why the COB didn't passed (if it was because of
them, still not sure). Because we're on a test environment, since we
made quite volume development, we don't want to transfer all it again,
in case COB failure happen.
Will try to see (S) them via the NAU file (bcos today is unworking day
here, ti will be on Monday)

Hi Vladimir,

I knew JOURNAL.UPDATE() doesn't work under version routines, but
extending the subroutine functionality i missed to predict the
problems with it. I resolved it with PGM.VERSION variable so now the
subroutine is able to be invoked from mainline and version routines.


Many thanks
Igor

[Igor Micev]

Hi,

I cannot see the records,
The message:
"MG0826000082 MISSING ON FILE FBNK.MG.BALANCES.SAVE"

[Saravanan S]

hi igor,

i presume this is your test env.  being in test area, i think you can try this.

Create a MG.BALANCES.SAVE record by copying  the respective  MG.BALANCES of the problematic records ............ DOING THIS the MG.BALANCES can not roll back to wat it was , before your amendment. but this a simple way to solve this.

 which stage of cob face the pbm.?

Thanks
Saravanan

[Igor Micev]

Hi Saravanan

We copied the MG.BALANCES records to MG.BALANCES.SAVE and then
authorized the records.
Thanks for the helpful suggestion

Igor