1

In the Guts with GaryGary Henriques

Systems Update

•MCP 13.0/SSR 54.1 Update•MCP 14.0/SSR 55.1 Update•MCP 15.0/SSR 56.1 Update•MISER 2013.1 Systems Update– Database Reorganization– MISERNet Updates

•Garbage Collection •House Keeping•Unisys Benchmark –FS1760•MISSILE•ACCESSCODE AGING

3

Agenda

Systems Update

•Unisys Support ending 10/31/13

• Final release that supported FS1300, FS1400, FS1600 and Libra 595 systems

•Will support MISER 2013.1

•Detailed list of IC Levels in Clearpath MCP Release 13.1 Migration Guide

MCP 13.0/SSR 54.1 Update

4

Systems Update

•Released by Unisys in April 2012

• Support for MCP 14.0 release ends October 2015

• Installed on Orlando FS1800 - 07/28/12

• Install date for Charlotte FS4150 – October 2013

•Qualified with MISER 2013.1, 2013.2

MCP 14.0/SSR55.1 Update

5

Systems Update

•MCP 15.0 being released by Unisys this month.

•MCP 15.5 Field Tested in Orlando on LX170 laptop.

•MCP15.0/SSR 56.1 is fully qualified for use with MISER release 2013.1

•Plan to install MCP 15.0 on Orlando FS1800 in August

MCP 15.0/SSR 56.1

6

Systems Update

•MISDB• 26 existing datasets modified• 1 index set modified• 4 new datasets and 16 new sets/subsets added• 0 deleted• • ATMDB• 2 existing datasets modified• 0 index sets modified• 6 new datasets and 12 new sets/subsets added• 0 deleted

MISER 13.1 Update – Database Reorganizations

7

Systems Update

• Set MCP, COMS, and DMSII release compatibility levels for 2013.1 •Correct timing-related table corruption problem • Implement new GET_ATM_TRAN_HIST interface to

ATMDBSUPPORT for TPSL •Prevent "Invalid Index" fault in SEND_DCKEYIN procedures

•Print transaction input fields in Diagnostic printer file • Fix output of "<database> STATUS HISTORY" on DMSII SSR 55.1

•Changes required for compatibility with SSR 56.1 release

MISER 2013.1 Update – MISERNET Updates

8

Systems Update

• Schedule Automated mass GCs

•WFL/GC/MISER–WFL/COMPILE/GC•WFL/INCLUDE/COMPILES/GC– SOURCE/MISER/GC/=

•2012 44 Sets•2013 All sets + ATMDB

Database Garbage Collection

9

Systems Update

• 00000100BEGIN • 00000200ARRAY A[0:9]; • 00000300DATABASE MISDB; • 00000400OPEN UPDATE MISDB; • 00000500A[0]:= 26; • 00000600REPLACE POINTER(A[1]) BY "GC ND-HISTORY-SET", 0; • 00000700DMINQ[0](A); • 00004600END.

Database Garbage Collection

10

Systems Update

• BEGIN • 00000200ARRAY A[0:9]; • 00000300DATABASE MISDB; • 00000400OPEN UPDATE MISDB; • 00000500A[0]:= 26; • 00000600REPLACE POINTER(A[1]) BY "GC CFK-CIF-SET", 0; • 00000700DMINQ[0](A); • 00000800REPLACE POINTER(A[1]) BY "GC CFK-ACCT-SET", 0; • 00000900DMINQ[0](A); • 00001000REPLACE POINTER(A[1]) BY "GC CFK-CIF-TAX-SET", 0; • 00001100DMINQ[0](A); • 00001200REPLACE POINTER(A[1]) BY "GC CFK-TAX-SET", 0; • 00001300DMINQ[0](A); • 00004600END.

Database Garbage Collection

11

Systems Update

• (“MISER/GC/ER"); • ("MISER/GC/NL"); • ("MISER/GC/CFK"); • ("MISER/GC/CFM"); • ("MISER/GC/NDA"); • ("MISER/GC/TAG"); • ("MISER/GC/CKMO"); • ("MISER/GC/HOLD"); • (“MISER/GC/LOAN"); • ("MISER/GC/TELLER"); • ("MISER/GC/VENDOR"); • ("MISER/GC/NL-BILL"); • ("MISER/GC/PAY-EMP");

Database Garbage Collection

12

Systems Update

• ("MISER/GC/SAVINGS"); • ("MISER/GC/VOUCHER"); • ("MISER/GC/ACH-TRLR"); • ("MISER/GC/BILLINGS"); • ("MISER/GC/EFT-CARD"); • ("MISER/GC/EMPLOYEE"); • (“MISER/GC/EXC-ITEM"); • ("MISER/GC/NOTE-PAD"); • ("MISER/GC/STOP-PMT"); • ("MISER/GC/FEE-WAIVE"); • ("MISER/GC/LNHISTORY"); • ("MISER/GC/NDHISTORY"); • ("MISER/GC/NLHISTORY");

Database Garbage Collection

13

Systems Update

• ("MISER/GC/SVHISTORY"); • ("MISER/GC/XFER-DATA"); • ("MISER/GC/GL-HISTORY"); • ("MISER/GC/RETIREMENT"); • ("MISER/GC/VC-HISTORY"); • ("MISER/GC/CIF-HISTORY"); • ("MISER/GC/ACH-CONTROL"); • ("MISER/GC/IRS-TRAILER"); • ("MISER/GC/ND-ANALYSIS"); • ("MISER/GC/ND-OP-MULTI"); • ("MISER/GC/QUEUE-BATCH"); • (“MISER/GC/TAX-ID-CASH"); • (“MISER/GC/DISTRIBUTION");

Database Garbage Collection

14

Systems Update

• ("MISER/GC/EFT-TRAN-HIST"); • ("MISER/GC/TRANSFER-SETS"); • ("MISER/GC/REWARDS-PARAMS"); • ("MISER/GC/TRAN-WAREHOUSE"); • ("MISER/GC/REWARDS-TRAILER");

Database Garbage Collection

15

Systems Update

• File retention enhancements–New version of OBJECT/MIS/CLEAN/DAILY

•Job and Location• (PROD)WFL/REMOVE/DAILY on PRODUCTION• Added to WFL/001/AUTO/START following Scheduler run.

•Functions• Removes old log files and work files. Both old Miser files (such as backuplogs and

tranlogs) and system files (such as sumlogs) can be removed with this utility. The user determines the retention period. • Files selected by ALTERDATE file attribute. • User can determine what directories to consider for file removal

Housekeeping

16

Systems Update

•Options• User can adjust the values of the variables PBD and PED in WFL/REMOVE/DAILY.

These values determine the date range to consider for file removal. The default values are PED=390 and PED=8, which means files last updated in the period from 390 days ago until 8 days ago (in essence, keeping a week’s worth of files) are candidates as long as they are specified in the selection data file DATA/REMOVE/INPUT

•Switches • SW1 – causes the LOCKEDFILE attribute to be turned off first on all files selected for

removal. This is the recommended setting since many Miser files are now locked, preventing their removal until the attribute is turned off.

Housekeeping

17

Systems Update

•Taskstring/Taskvalue/Card file• The input file DATA/REMOVE/INPUT is used to specify the directories to

scan for removal candidate files. This file contains one directory per line with the directories separated by commas and the family name specified afterwards. Thus the file consists of one or more sections (one for each family), with each section as follows: • <first directory>• ,<second directory>• ….• ,<last directory>• FROM <pack>• The use of wild cards is permitted for the directory names, with a question mark (?)

standing in for a single character and an equals sign (=) standing in for a directory.

Housekeeping

18

Systems Update

• ACH/= • ,. ATM/??????/TRANFILE • , ??????/001/= • , TRANLOG/=• FROM PRODUCTION • • , MISERNET/BACKUPLOG2/= • FROM AUDITPACK • • , BKUP/= • , MISERNET/= • , ATMMISERNET/= • , VBMISERNET/= • FROM BACKUP • • , *ATLAS/ADMIN/ATLASSUPPORT/TRANSLOG/= • FROM DISK • • , *SUMLOG/= • , MISERNET/BACKUPLOG/= • FROM PACK

Housekeeping

19

Systems Update

•TASKSTRING• The taskstring can be used to facilitate multiple runs (as many as necessary) of the

WFL. This might be useful when the `retention period varies from one type of file to another. • For example, it may be necessary to keep most files for two weeks but sumlogs can

be removed after seven days. In this case, a second copy of the WFL can be created with a different name, where a taskstring is specified for OBJECT/MIS/CLEAN/FILES, as follows:• RUN OBJECT/MIS/CLEAN/DAILY; TASKSTRING=”SPECIAL”;• The taskvalue can be specified to allow the removal of non-data files. In normal

operation, the program will not consider WFL source files (type JOBSYMBOL) and code files (COBOL85CODE, DMALGOLCODE,DCALGOLCODE) as candidates for removal, even if they fall within the date range of files marked for removal. However, in some cases the user may wish to remove these types of files as well. The default behavior may be changed by setting the taskvalue for the program as follows:

Housekeeping

20

Systems Update

• TASKVALUE=1: also remove WFL source files (type JOBSYMBOL) if they fall within the date range of files being removed.• TASKVALUE=2: also remove codefiles

(COBOL85CODE,DMALGOLCODE,DCALGOLCODE) and o WFL source files if they fall within the date range of files being removed.• In addition, the value of PED as explained above is 8, rather than 15, For example, a

second WFL called WFL/REMOVE/DAILY/SPECIAL is set up for files to be retained longer. A data file called DATA/REMOVE/INPUT/SPECIAL is created that contains the list of directories to be scanned by the second WFL.

Housekeeping

21

Systems Update

•Workload scaling• The baseline workload consisted of a Miser database with:• 140,000 open accounts• 30,000+ online transactions per day• 5,000 NDA-intran records

• In performing this benchmark we selected 3 scenarios to test.• 1x level workload test• 3x Increased account volume & transaction volume 3 times• 6x Increased account volume & transaction volume 6 times

FS1760 Benchmark

22

Systems Update

• The Unisys FS1760 Enterprise Server running SSD (solid State) disk can easily run a Miser FI with 700,000 to 900,000 accounts, with transaction level of over 300,000 per day. • The results from this benchmark and the associated scenarios show that the Unisys

FS1760 is capable of processing the workload model profiled in this exercise, plus more. During the system 6X test, the Unisys FS1760 System achieved a maximum rate of 306 transactions per second across multiple Channels/TPSL programs. This transaction volume far exceeds that which is processed by most MISER customers today.

• System configuration• Unisys FS1760 running 6 CPMs @ 1800 MIPS (2 Intel Quad core 3.3 GHz Xeon

processors)• In-Built disk system: 6 200 gig SSD drive and 16 300 gig drives

FS1760 Benchmark

23

Systems Update

•3x Scenario • FS1760 running 6 CPM• Misernet running 7 TPSL active programs • Transaction Volume Modeled: 115,000• Account Volume: 394,212• Transaction type: Checking paid in/paid out & Savings paid in/paid out • Online Transaction posting (115,000 transaction posting across 7 TPSL

programs) elapsed time was 15 minutes

• Unisys COMS reported an average transaction rate for the 7 TPSL programs at 110 transactions per second with average response time of 0.005 seconds per transaction. System maxed at 233 transactions per second.

FS1760 Benchmark

24

Systems Update

• To calculate the full day capability using 80% of the benchmarked transaction per second rate:•• 233 Transactions per second multiplied by 80% = Transactions per second• 186 x 60 seconds x 60 minutes = 669,600 per hour• 669,600 x 8 hours = 5,356,800 daily transactions• • Statistically there is not an FI that will process transaction volume at peak rates for

a solid 8 hour period. The ALTIN method of processing transactions is worst case, because the next transaction is coming in as fast as Misernet can deliver it.

FS1760 Benchmark

25

Systems Update

•Batch Processing review from Benchmark: • Batch Elapsed Time: 35 Minutes

•Sample Jobs from Batch run• • NDFP 6 minutes, 31 seconds• NLFP 1 minutes, 28 seconds• LNFP 1 minute, 21 seconds• SVW101 4 minutes, 34 seconds• MSR900A 6 minutes, 37 seconds• SVD090 2 minute, 9 seconds

FS1760 Benchmark

26

Systems Update

•6x Scenario • FS1760 running 6 CPM• Misernet running 7 TPSL active programs • Transaction Volume Modeled: 296,562• Account Volume: 770,590• Transaction type: Checking paid in/paid out & Savings paid in/paid out •• Online Transaction posting (296,000 transaction posting across 7 TPSL programs)

elapsed time was 27 minutes• Unisys COMS reported an average transaction rate for the 7 TPSL programs at 212

transactions per second with average response time of 0.008 seconds per transaction. System maxed at 306 transactions per second.

FS1760 Benchmark

27

Systems Update

• To calculate the full day capability using 80% of the benchmarked transaction per second rate:•• 306 Transactions per second multiplied by 80% = Transactions per second• 244 x 60 seconds x 60 minutes = 878,400 per hour• 878,400 x 8 hours = 7,027,200 daily transactions• • Statistically there is not an FI that will process transaction volume at peak rates for

a solid 8 hour period. The ALTIN method of processing transactions is worst case, because the next transaction is coming in as fast as Misernet can deliver it.

FS1760 Benchmark

28

Systems Update

•Batch Processing review from Benchmark: • Batch Elapsed Time: 1 Hour 17 Minutes

•Sample Jobs from Batch run• • NDFP 14 minutes, 18 seconds• NLFP 2 minutes, 58 seconds• LNFP 2 minutes, 48 seconds• SVW101 8 minutes, 42 seconds• MSR900A 12 minutes, 57 seconds• SVD090 3 minute, 45 seconds

FS1760 Benchmark

29

Systems Update

• In order to send files seamlessly to Miser (no operator intervention on FIS side)• Files must be valid wrapped files• Files must not be zipped• Files must be dropped in /users/<id>/<id>• To wrap files, we recommend using the Miser utility• WFL RUN OBJECT/MIS/WRAPPER• Program will then request the names of the files you wish to send.• By default the name of the wrap file to upload is WRAPPED.• Several options are available, such as the capability to verify that all files were

wrapped, to specify a custom wrap file name, to log all files wrapped, and to specify the name of files to be wrapped in a card file.• In some cases (extremely large files) files may be zipped by prior arrangement with

customer care (since they will need to be unzipped manually on our Missile server).

MISSILE

30

Systems Update

• If you have files larger than 2 GB you may need to break them into pieces in order to have them MISSILE successfully• Example– R $SYSTEM/DUMPALL ("COPY <tranlog> REC 1 THRU 5000 TO PART1”)– R $SYSTEM/DUMPALL ("COPY <tranlog> REC 5001 THRU 10000 TO PART2”)

• You would then have 2 pieces called PART1 and PART2 that would be wrapped and missiled separately

• If desired, files may be sent in SSL (encrypted mode).• We use passive mode, secure SSL.• You will need to accept our certificate.• The server will use a port between 5000 and 5025 so these ports must be open in

your firewall.

MISSILE

31

Systems Update

• This will work if either the DAC or SPM keys are present. For example in 55.1, the command IK SHOW “551-I” will show the key 551-INFOGUARD-DAC .• The following example shows how to set up accesscode again for an existing

usercode DBA/accesscode JDSELAV. • RUN $SYSTEM/MAKEUSER• $SET LIST IGNORE• USER DBA ACPWAGIN ACPWDEFDAYSACTIVE=60,ACPWDEFDAYSWARN=5;• USER DBA ACCESSPWAGING AT ACPWNAME=”JDSELAV”

(ACPWDAYSACTIVE=60,ACPWDAYSWARN=7)• USER DBA; • The resulting display will include something like this…

Accesscode Aging w/o Locum

32

Systems Update

• ACCESSCODENEEDED• ACPWDEFDAYSACTIVE = 60• ACPWDEFDAYSWARN = 5• ACCESSPWAGING % GROUP: LENGTH=8 WORDS, 2 ENTRIES• AT ACPWNAME = ( "JDSELAV" )• ( ACPWENFORCEEXP• ACPWDAYSACTIVE = 60• ACPWDAYSWARN = 5• )• ,AT ACPWNAME = ( "AMKEATI" )• ( ACPWENFORCEEXP• ACPWDAYSACTIVE = 60• ACPWDAYSWARN = 5

Accesscode Aging w/o Locum

33

Systems Update

• The user will be warned when logging on within the warning period, and be prompted to change the password.

• While technically satisfying the capability to require users to change their accesscode passwords, there are two shortcomings that are not addressed here. • Password complexity enforcement.• Synchronization of accesscode passwords across usercodes.

Accesscode Aging w/o Locum

34

THANK YOUGary Henriques407-309-5055