Shadowbase Support Tips

Andrew J. Bauernschmidt

Andrew Bauernschmidt,
Delivery Specialist

Replicating the BASE24™ Classic “CAF Full Refresh” Procedure in a Business Continuity Environment Using HPE Shadowbase Software and AutoTMF

The following procedure assumes that you already have a valid AutoTMF and HPE Shadowbase product environment in place and will outline the ATMFFILESET syntax and Shadowbase DBS syntax to replicate a BASE24 Classic Full Refresh for a CAF (or PBF) file.

AutoTMF Preparation (if not already installed)

Install the newest version of AutoTMF to the NonStop system. (You need at least SPR ^ABH of AutoTMF.) Once AutoTMF has been installed, issue a run command to enter the AutoTMF prompt.

$QA DJBCAF 361> RUN $SAS3.AUTOTMF.AUTOTMF
HPE Nonstop(tm) AutoTMF(tm) Command Interpreter(T0581L01) - System \VIV1
(C)2017 Hewlett Packard Enterprise Development Company, L.P.
(C)1996-2017 Carr Scott Software Incorporated
AutoTMF 1?
  1. In order to “Audit” BASE24 Classic files, you need to turn on the ‘A’udit attribute for the CAF file.
  1. You then need to AutoTMF prepare the SKELB libraries for BASE24 Classic. For our testing, we AutoTMF prepared a copy of FUP. We created a copy called FUPDB. This is the utility you must use for DDL creates and renames. See the NonStop AutoTMF AAS Manual for detail on how to AutoTMF prepare FUP.
  1. For our testing, we also “simulated” BASE24 Classic by AutoTMF preparing a simple un-audited Enscribe data generator called UNIUD. You must prepare this program with AutoTMF, the same as FUP in the previous step.
AutoTMF 1? prepare $qa.sbtools.uniud;
AutoTMF 2?

Configuration

  1. In AutoTMF, use a combination of the GENERATIONS attribute, and the REPLICATERENAME attribute for the file.
    1. GENERATIONS is a facility for replacing a single file with multiple versions of the file.
    2. REPLICATERENAME enables a renamed file for replication to a remote system by Shadowbase software. AutoTMF ensures that the TMF audit trail contains the purge, create, and data records necessary to replicate the file to a remote system. REPLICATERENAME is configured on the new file name. If the existing file is not audited, CREATEAUDIT must be set for the new file name. The renamed file is always audited when the operation completes.
    3. To set these attributes, use the following commands:
AutoTMF 7? ADD ATMFFILESET $QA.DJBDATA.CAF, GENERATIONS 3;
AutoTMF 8? ADD ATMFFILESET $QA.DJBDATA.CAF0*, REPLICATERENAME;;
    1. Only two generations are required, because the previous generation file should be closed when it is required as the next generation file. Between invocations of refresh, the number of generations can be reconfigured, since only the current CAF (the one with the most recent creation timestamp) is being accessed by the application.

Full Refresh Process

  1. We use a CAFTST as a template for CAF to create an empty NEWCAF daily. Below is a list of files on the Source and Target system when the Full Refresh process is started:
    1. File-set on SOURCE at startup:
$QA DJBDATA 113> fi *caf*
$QA.DJBDATA
 CODE EOF LAST MODIFIED OWNER RWEP PExt SExt
CAF 0 0 11APR2018 9:33 255,5 NCNC 1000 1000
CAFTST 0 0 04APR2018 13:13 255,5 NCNC 1000 1000
$QA DJBDATA 114>
    1. File-set on TARGET at startup:
$QA DJBDATA 42> fi caftst
$QA.DJBDATA
 CODE EOF LAST MODIFIED OWNER RWEP PExt SExt
CAFTST 0 0 03APR2018 16:49 255,5 NCNC 1000 1000
$QA DJBDATA 43>
  1. We added the following DBS to the Shadowbase configuration to replicate the DML events that occur against the CAF during the business day. This works in conjunction with the AutoTMF management of the rename command replication processing.
SB_ADD DBS CAFDBS \VIV1.$QA.DJBDATA.CAF0* $AJBC2 \GRAVIC1.$QA.DJBDATA.CAF0* - -
  1. Start a Shadowbase environment:
AUDCOM - T1122 - V6410L06 - (31MAR18), COPYRIGHT GRAVIC, INC.
1995-2018. PORTIONS COPYRIGHTED BY AND LICENSED FROM THIRD PARTIES. SEE
README FILE. USAGE SUBJECT TO THE TERMS OF A WRITTEN LICENSE AGREEMENT.
PATENTS: SEE WWW.GRAVIC.COM/GRAVICLABS/PATENTS/PRODUCTS.
SHADOWBASE - T1122 - V6410L06 - (31MAR18)
AUD STATUS AT 2018-04-11:09:34:35 :

AUDMON \VIV1.$AJBMN - STATE = RUNNING
CPUS 0:1
OWNER 255,5
CONTROL OPENED \VIV1.$QA.QAUNDR.SRMNCCC [ERROR = 0]
LOG CLOSED
EMS OPENED $0 [ERROR = 0]
TRACE CLOSED
HISTORY ON \VIV1.$QA.QAUNDR.AUDHST [SQLCODE = 0]
COLLECTOR/QMGR/CONSUMER/SOLVMGR STATES:
NAME PROCESS TYPE STATE STATE CHANGE TIME
---------------- ---------------- ---- --------- -------------------
COLL-AJBCL \VIV1.$AJBCL COLL RUNNING 2018-04-11:09:34:35
 LTS (LAST EVENT): 2018-04-11:09:34:35
QMGR-TGT-AJBQ1 \GRAVIC1.$AJBQ1 QMGR RUNNING 2018-04-11:09:34:35
CONS-DIR-AJBCN \GRAVIC1.$AJBCN CONS STARTED 2018-04-11:09:34:22
 LTS (LAST EVENT): NONE RECEIVED
$QA DJBDATA 63>
  1. Assuming that the current CAF is not audited, the next invocation of Full Refresh will proceed as follows:
    1. CAF is opened by authorization servers (authorization servers prepared in Step 3).
    2. The current CAF is renamed to OLDCAF. Since CAF is not audited, the RENAME succeeds.
$QA DJBDATA 113> FUPDB RENAME CAF,OLDCAF
$QA DJBDATA 114> fi *caf*
$QA DJBDATA 114..
$QA.DJBDATA
 CODE EOF LAST MODIFIED OWNER RWEP PExt SExt
CAFTST 0 0 04APR2018 13:13 255,5 NCNC 1000 1000
OLDCAF 0 0 11APR2018 9:33 255,5 NCNC 1000 1000
$QA DJBDATA 115>
    1. Create a blank NEWCAF file from the template file CAFTST.
$QA DJBDATA 116> FUPDB DUP CAFTST, NEWCAF
$QA DJBDATA 117> fi *caf*
 CODE EOF LAST MODIFIED OWNER RWEP PExt SExt
CAFTST 0 0 04APR2018 13:13 255,5 NCNC 1000 1000
NEWCAF 0 0 11APR2018 9:37 255,5 NCNC 1000 1000
OLDCAF 0 0 11APR2018 9:33 255,5 NCNC 1000 1000
$QA DJBDATA 116>
    1. Use the prepared FUP to rename NEWCAF to CAF. Since CAF no longer exists, AutoTMF renames NEWCAF to generation file CAF001. Furthermore, since CAF001 is configured with REPLICATERENAME, CAF001 is audited and will be replicated to the remote system.
$QA DJBDATA 118> FUPDB RENAME NEWCAF, CAF
$QA DJBDATA 119> fi *caf*
 CODE EOF LAST MODIFIED OWNER RWEP PExt SExt
CAF001 0A 0 11APR2018 9:38 255,5 NCNC 1000 1000
CAFTST 0 0 04APR2018 13:13 255,5 NCNC 1000 1000
OLDCAF 0 0 11APR2018 9:33 255,5 NCNC 1000 1000
$QA DJBDATA 120>
    1. The authorization server processes close CAF (renamed to OLDCAF) and open the current CAF generation file, CAF001.
    2. OLDCAF can be discarded.
    3. When there are IUD’s against CAF (using the prepared IUD program), they are applied to the opened Generation file.
$QA DJBDATA 121> $QA.SBTOOLS.UNIUD I CAF 1 1 3

Note: The prepared data generator (UNIUD) performs I/O against CAF, yet AutoTMF manages the CAF generation files (CAF001, CAF002…) by applying these changes to the appropriate generation.

  1. The first invocation of FR results in a fully replicated CAF generation file. The next invocation of Full Refresh will proceed as follows:
    1. The audited CAF001 is opened by authorization servers.
$QA DJBDATA 122> fi *caf*
 CODE EOF LAST MODIFIED OWNER RWEP PExt SExt
CAF001 0A 20480 11APR2018 9:41 255,5 NCNC 1000 1000
CAFTST 0 0 04APR2018 13:13 255,5 NCNC 1000 1000
$QA DJBDATA 123>
    1. A NEWCAF is created from CAFTST template file.
      1. TACL > FUPDB DUP CAFTST, NEWCAF
$QA DJBDATA 123> FUPDB DUP CAFTST, NEWCAF
$QA DJBDATA 124> fi *caf*
 CODE EOF LAST MODIFIED OWNER RWEP PExt SExt
CAF001 0A 20480 11APR2018 9:41 255,5 NCNC 1000 1000
CAFTST 0 0 04APR2018 13:13 255,5 NCNC 1000 1000
NEWCAF 0 0 11APR2018 9:43 255,5 NCNC 1000 1000
OLDCAF 0 0 11APR2018 9:33 255,5 NCNC 1000 1000
$QA DJBDATA 125>
    1. CAF001 is renamed to OLDCAF. Since CAF001 is audited, RENAME fails with an error 80 (invalid operation on audited file), but Full Refresh will not be notified of the failure.
    2. NEWCAF is renamed to the next CAF generation, CAF002, which is audited and replicated to the remote system.
      1. TACL > FUPDB RENAME NEWCAF, CAF
$QA DJBDATA 126> FUPDB RENAME NEWCAF, CAF
$QA DJBDATA 120> fi *caf*
$QA.DJBDATA
 CODE EOF LAST MODIFIED OWNER RWEP PExt SExt
CAF001 0A 20480 11APR2018 9:41 255,5 NCNC 1000 1000
CAF002 0A 0 11APR2018 9:44 255,5 NCNC 1000 1000
CAFTST 0 0 04APR2018 13:13 255,5 NCNC 1000 1000
OLDCAF 0 0 11APR2018 9:33 255,5 NCNC 1000 1000
$QA DJBDATA 121>
    1. The server processes are notified to close and reopen CAF. AutoTMF maintains which CAF00n iteration is updated.

As always, if you foresee needing to exercise this activity in the near future, and you have a question, or any other question related to Shadowbase Support, then feel free to contact us.


Please reference our Newsletter Disclaimer.