Based in Currie, Minnesota, population 224, Currie State Bank recently experienced significant technology upgrades that have made their systems more secure and their customers much happier. The overhaul was mainly due to the desire to move their hardware off site, as electrical storms often played havoc with the power supply, putting their customers’ data at risk. They turned to Synergex customer Automated Systems, Inc. (ASI), which has been successfully addressing the needs of community banks since 1981. Automated Systems, Inc. offered Currie the ability to work in a cloud environment. Now Currie just supplies the PCs and phone lines, minimizing their overhead and risk, while ASI maintains the servers and data. States Currie State Bank CEO Doug Hansen, “By moving to cloud computing, we’ve experienced significant savings by dramatically reducing our overhead. We have not had to replace our IT manager that we lost about the time of the conversion, and we have eliminated the costs associated with maintaining expensive servers on site for various operations.”

An added bonus of moving to ASI’s Insite Banking Platform was the ability to offer mobile banking and remote deposit capabilities to Currie’s customers. Currie is one of the few banks in the area to provide this service, which is a significant benefit in a rural area where many customers live far from a bank branch.  “Adding these features has made us significantly more competitive – even with the large banks,” adds Hansen.

Currie plans to upgrade to Insite 8.0, the result of ASI’s Core Genetics initiative, which is based on Synergy/DE 10.1 and offers

• An intuitive user interface that is extensible across the product around how users can, want, and need to use it
• A tile-based menu system that supports launch tiles, enabling a tile to launch an external application and pass it parameters
• Enhanced security including role-based and visual security, and simplified customer security.
• Centralized alerts so all of a customer’s alerts across all of their accounts are displayed.
• More features focused on optimizing bank efficiency and customer touch points.

Automated Systems, Inc. (ASI) is ranked as a Top 10 Core Vendor for Community Banking. (Source: Inntron.com – The international authority for Core Banking systems, vendors, and markets). Since 1981, Automated Systems, Inc.’s Insite Banking Platform has been successfully addressing the needs of community banks. For more information about Currie State Bank’s recent upgrades, see http://www.readperiodicals.com/201406/3358474071.html

Are you up for the challenge?

Up in the attic, and dusting old code,
Mission: .NET – ere the weather turns cold!
Here in the gloom on this Halloween night,
it’s not goblins or ghouls that give me a fright.
And ghosts don’t exist – or so I have learned,
but these webs of old logic have me concerned.

The compiler’s more picky than what I recall;
now types are important in subroutine calls!
There are too many programs where this routine’s run – 
it’ll take me all night to change every one!
It simply takes dates to make them look right,
but I pass it numerics and alphas alike.

There are tricks that bring treats in today’s DBL,
that soothe the compiler so all will work well.
But with much more to do and not much time,
I asked of the darkness, “Will this work out fine?”

subroutine FormatDate
     mismatch someDate      ,n
     formattedDate          ,a
     endparams
record
     testDate              ,d8
proc
     onerror badDate
     testDate = someDate
     formattedDate = someDate,'XX/XX/XXXX'
     if (0)
     badDate,
        formattedDate = 'BAD DATE!!'
     offerror
     xreturn
end

Not expecting replies from the black,
multiple answers nevertheless came back:

• As a solution this just doesn’t rate – you’ll *never* see the message “BAD DATE!!”
• Back to the drawing board, you missed by a mile – this piece of code won’t even compile!
• Your solution is sound; that “mismatch” is dandy. Now shut down the laptop and go get some candy!
• Close but not quite, I’m sorry to say. You need to recode and use “mismatch a"...

Don’t know the answer? Unsure which to choose?
Continue reading for the Code Phantom’s clues!

Question: I’m performing an addition operation involving decimal variables and literals. Then I use ^A to display the results as an alpha. Sometimes, the result has a leading zero. Why is this happening?

The ^A data reference operation casts the decimal descriptor as an alpha descriptor. Temporary decimal values (for example, dvar + 1) are not guaranteed to have a fixed size, just the correct value. Consequently, the space allotted for display sometimes exceeds the number of digits required. The leading zero occurs when the result is the same number of digits as the largest of the operands. For example, when using ^A to cast as alpha, summing 1 + 9 would result in 10 displaying, whereas summing 1 + 8 would result in 09 displaying.

When writing numeric values to the screen, we recommend using %STRING instead.  %STRING causes a conversion equivalent to avar = dvar, “ZZZZZZX”, which is the default format string.
 
The example below demonstrates the different results when using ^A vs. %STRING to display the result of several addition operations:
 

proc
     begin
          data d1    ,d1    ,1

          open(1, O, "TT:")

          writes(1,^A(d1 + d1))       ;displays 02
          writes(1,^A(d1 + 9))        ;displays 10
          writes(1,^A(d1 + 8))        ;displays 09
                       
          writes(1,%STRING(d1 + d1))  ;displays 2
          writes(1,%STRING(d1 + 9))   ;displays 10
          writes(1,%STRING(d1 + 8))   ;displays 9
     end
endmain

We will be closed November 27 and 28 for the Thanksgiving holiday

If you anticipate needing our assistance on either of these days, please contact us at synergy@synergex.com to make arrangements.