Conference acadmy::tpas_notes

Andre,


    - the (old) import procedures for the databases TPAS$DB and
      TPAS$STKRM_DB use the SQL IMPORT/EXPORT mechanism for building a
      database. The (new) load procedure for the TPAS$NOR$DB database uses
      the RMU LOAD/UNLOAD mechanism for building the NOR database.

      Why not use the same method for all databases? We use heavily
      modified versions of the (old) import procedures in our (DMS)
      batch commandfiles and we would prefer to use one method consistently
      for all TPAS databases.

> The reason why the NOR DB is done with an RMU/UNLOAD LOAD is due to the
> fact that the NOR Database here contains many other tables used in the 
> calculation of the NOR data. These tables are not needed for TPAS Logic
> and add size to the database. We could potentional do the UNLOAD and LOAD
> into another database, then do an SQL EXPORT. That will be a consideration 
> we will look at, but I cannot commit at this moment.


    - as mentioned before in the NOTES-file the RMU statements used do NOT
      work from a non-privileged account. The workaround in NOTE 67.0
      doesn't seem to work....

      Could you drop the RMU-commands and replace them by something that
      does work from a non-privileged account?

> Yes we will be rebuilding the command files to take the RMU/VERIFY 
> out of the TPAS_*IMPORT*PRCDR.COM and create separte TPAS*VERIFY*PRCDR.COM
> But that won't be until the next release, which is not yet scheduled.

    - building the NOR database takes a long time (on our development
      cluster almost one hour). This can become a problem for us because we
      have a very full month-end schedule. I think the long run time for
      the NOR build is mainly caused by the fact that RMU/LOAD is used
      followed by SQL statements to create the RDB indexes.

      Please consider to use SQL IMPORT or RMU/RESTORE for building the NOR
      database! I have used RMU/RESTORE on the NOR database a couple of
      times on our development cluster and it takes only 2 minutes to build
      a new database.
> See reply 1. I will look at RMU/RESTORE - but don't won't that also
> require the RMU privs.  Currently I am on V4 RDB, so I am not sure
> about all the privs for V6

    - the import/load procedures produce a lot of '%SQL-I-DEPR_FEATURE'
      messages because 'old-style' SQL is used.

      Could you change the 'old-style' SQL commands in 'new-style' SQL
      commands to get rid of these confusing messages?
> Again, I can't do anything with this until we upgrade RDB.

    - on our live (DMS) system we copy the TPAS I V2 database build files
      (the *.RBR files) from ACADMY"TPAS_XFER"::TPAS$OUTBOUND:. The TPAS II
      V3 copy procedures pull them from another directory, being 
      ACADMY"TPAS_XFER"::TPAS_II$OUTBOUND:.

      Does this mean that for the time being the TPAS database build files
      will be available in both the TPAS I V2 and the TPAS II V3 format and
      it's up to us to pull the files we need from the proper directory?
> You are right. There will be a period of time when TPAS I and TPAS II
> will be running in different sites. This phased in approach is allowing
> sites to come up in different time table. 
> The TPAS$DB data will be maintained for business as usually. It will
> not be until ALL sites are running TPAS II that the new features (NOR and 
> Order MLP) will be utilized. 
> Currently a July 1 time frame is being targeted for TPAS I to be stopped.

Regards,
    Lois 

Andr�

In what way did the work round in 67 not work?  You have to do two things:

1.  Set up an ACL on a file that isn't going to be deleted, created etc. so 
that you have a permenant example to refer to.

2.  Modify the import/load command files to use the set ACL like command 
just after the new database is created.

Lois,

I think a better solution would be to leave the RDBs alone and simply drop 
the tables, recreate them and then add the data (via RMU load?).  Then once 
the ACL has been set it will remain.

Also why so many RDBs?  Easier to manage one TPAS database with all the 
tables in it.


Regards

Charley

    Re. 80.1

> > Yes we will be rebuilding the command files to take the RMU/VERIFY 
> > out of the TPAS_*IMPORT*PRCDR.COM and create separte TPAS*VERIFY*PRCDR.COM

    Good Idea! This will also make it possible to run it separately in case
    of e.g. database problems.

>       Please consider to use SQL IMPORT or RMU/RESTORE for building the NOR
>       database! I have used RMU/RESTORE on the NOR database a couple of
>       times on our development cluster and it takes only 2 minutes to build
>       a new database.
> > See reply 1. I will look at RMU/RESTORE - but don't won't that also
> > require the RMU privs.  Currently I am on V4 RDB, so I am not sure
> > about all the privs for V6

    RMU/RESTORE will probably require the RMU privs. To stay in line with
    the other databases I would prefer SQL IMPORT anyway.

> > The TPAS$DB data will be maintained for business as usually. It will
> > not be until ALL sites are running TPAS II that the new features (NOR and 
> > Order MLP) will be utilized. 

    Does this mean that for the time being we could decide not to load the
    NOR database until this feature is switched on or will this cause some
    kind of problem in TPAS?

    Re. 80.2

> In what way did the work round in 67 not work?  You have to do two things:
> 
> 1.  Set up an ACL on a file that isn't going to be deleted, created etc. so 
> that you have a permenant example to refer to.
> 
> 2.  Modify the import/load command files to use the set ACL like command 
> just after the new database is created.

    Sorry, my mistake! Somehow some other ACL's were put on the NOR
    database. After I removed them it did work!

> I think a better solution would be to leave the RDBs alone and simply drop 
> the tables, recreate them and then add the data (via RMU load?).  Then once 
> the ACL has been set it will remain.
> 
> Also why so many RDBs?  Easier to manage one TPAS database with all the 
> tables in it.

    I basically agree with both statements.

    Thanks for the speedy replies,

    Andr�

	The different ways of loading the databases and the removal of the 
	RMU/VERIFYies to different command stream has been given an SPR # of
	95032301.


> > The TPAS$DB data will be maintained for business as usually. It will
> > not be until ALL sites are running TPAS II that the new features (NOR and 
> > Order MLP) will be utilized. 

>    Does this mean that for the time being we could decide not to load the
>    NOR database until this feature is switched on or will this cause some
>    kind of problem in TPAS?

	Yes. that is exactly what it means. You currently do not need
	the TPAS$NOR_DB to do pricing as there are no pricing records
	set to use NOR as the base price.

Regards,
Lois

Hi Lois,

We have implemented for May, and have been reviewing the support of the local site TPAS 
application.

For the OUTBOUND RBR files,made available monthly, we have DEC Scheduler processes set up to pull 
the files on the Friday before they are due. This way, we can resolve any copy problems that 
occur, during the day Friday, before our update processes on Sunday night of the fiscal monthend. 
Hence, should we assume the following ....

- That both the STKRM and TPAS RBR files update files will be made available by the Friday 
morning of the last fiscal week of the month? If not present by the Friday, treat this as an 
error, to be investigated?

This came up when we noted that missing feed files does not set a DEC Scheduler error status in 
the copy jobs, yet, missing feeds at this point should likely be an error condition.


thanks for your help,

Bob Cameron
Canadian IM&T, Finance
Canadian Sales Sub Impl 

Bob,

I have updated all the file availability schedules. Please check note 95 and
all the replies.
Unfortunately, all the data files are not available at the same time.
The Corporate Stockroom Data is not made available to us until the last fiscal
saturday.
Note that all the copies use serial numbering so that you could execute the
copies daily and only copy any new files.

regards,
Lois