Analytics Announcing CCA Analytics! by Marie Kelly
At the recent Insight 204 Symposium held in the Boston area, CCA unveiled the latest addition to the product family—CCA Analytics. Analytics is a high-performance data analysis tool that provides the features and performance required to quickly analyze large volumes of data and gather business intelligence information from the database. It works not only with Model 204, but with other ODBC data sources.
Unlike analytical tools which are deployed against a small, read-only subset of large operational databases, Analytics can directly query even the largest databases, saving you the time of constructing smaller data marts. It utilizes the data management found in IBM OS/390 platforms with the data visualization capabilities of Microsoft Windows so that you can manipulate huge databases right on the desktop.
Using Analytics, you can drill directly into the operational data to examine the detail records that produce summaries and statistics. Because you work with original source data, you can base business decisions on credible and current information.
Build a data warehouse in two weeks When IT professionals think of business intelligence solutions, they usually think of a data warehouse—a complex architecture designed for decision-support activities that involves the systematic integration of many software components. A full-blown data warehouse can take months or even years to complete—enter Analytics.
The New York State Board of Cooperative Education Services (BOCES) in Syracuse, NY used Analytics to build an interim data warehouse solution in just two weeks—long before the completion of their extensive data warehouse application.
Designing a data warehouse with Analytics BOCES is now using Analytics to help design their data warehouse application. BOCES is deriving business intelligence from their data and testing with it to ensure that they design the most useful data warehouse at the outset. According to IT Director, Larry Dismore, "The practical benefit is that people can begin making better administrative decisions immediately and actually influence the way the data warehouse is built, rather than waiting for six months to try it out. This will help us build exactly what we need the first time."
A picture is worth a thousand words Operating in a graphical environment, Analytics displays data so that users can easily define and quickly execute even the most complex analytical queries with a minimum of technical support. Analytics can also dynamically export data to a variety of output formats used by other analysis tools on the PC client and other host platforms.
Creating and storing segments Using Analytics you can segment your data according to your business logic. Creating a segment can involve many complex and detailed queries; you can save a segment, giving it a recognizable name. Working with segments includes:
For more information on CCA Analytics, contact your account representative at CCA or visit CCA’s Product Information Area.
System 1032 Tips on using System 1032 procedures as ODBC stored procedures by Tym Stegner
A prime feature of the System 1032 ODBC Driver is its ability to call PL1032 procedures via the ODBC stored procedure (SP) mechanism. For the most part, you can call any given System 1032 procedure directly from an ODBC source, as a stored procedure.
However, some inherent limitations to ODBC stored procedures affect how you handle System 1032 procedures. This article identifies these limitations and describes how to work around them.
Output parameters ODBC supports three types of stored procedure parameters:
To most closely match the System 1032 style of parameter, your application should specify the Output parameters as the InputOutput parameter type.
If your application does not support InputOutput parameters, or if you need the Output type functionality, add a comment to the System 1032 Output parameter that begins with the word ONLY, as shown in the following example. This must be done before the procedure is entered into the dictionary using the ODBC_DICTIONARY tool.
Procedure DEMO( newSSN : output text comment "ONLY OUTPUT" ) ... End_Procedure
Note: To modify the comment of a parameter, you must recreate the procedure.
Array or Group parameters The ODBC specification and SQL have no concept of an array or a System 1032 group. Therefore, you cannot use an array or a group either as an Input or an Output parameter if you expect to call the procedure via the SP mechanism.
Optional parameters While ODBC supports the idea of optional parameters, the System 1032 convention of specifying only the comma to indicate a skipped parameter might be insufficient. In a test done using Microsoft Query on the System 1032 PRINT_FILE procedure unused parameters were specified only with a comma; this evoked an Invalid or missing argument error.
You can work around this limitation by:
Wrapping a procedure ODBC application programmers often use the PRINT_FILE procedure, found in the S1032_UTL library. The PRINT_FILE procedure queues files, usually System 1032-generated reports, to be printed. The tool procedure offers many of the options of the OpenVMS PRINT command as procedure parameters: 32 parameters in all.
As explained, when this procedure is called directly as an ODBC stored procedure inQuery, you must specify all 32 parameters, even if the application needs only the first and seventh parameters, FILE_NAME and COPIES, for example.
You can create a wrapper (also called a stub) procedure to do basically the same work, but with an application-specific parameter list:
Procedure MY_PRINTFILE( - xFILE_NAME Text Varying, - ! 1 xCOPIES Integer Optional ) ! 2 call PRINT_FILE(xFILE_NAME,,,,,,xCOPIES) End_Procedure
Now the ODBC SP needs only concern itself with the actual parameters required by the application; with no concern about null-specifying the omitted optional parameters; in fact, S1032 handles the optional parameters as efficiently as always.
System 1032 dataset context Keeping track of dataset context is the most challenging programming design you face sharing procedures between System 1032 and ODBC. There is no concept of a persistent selection set across ODBC commands as there is in System 1032. Each time you issue an SQL command against an ODBC data source, you issue it against a new instance of that table.
For ODBC Driver, a stored procedure is then associated with an output table, a table already defined in the ODBC dictionary. The table might be a temporary table (a V3.00 feature) that does not exist outside of the execution of the SP mechanism. ODBC manages the opening or creating and the closing of the associated table.
Any other datasets used by the stored procedure, opened via the implicit open mechanism or explicitly by the procedure, are completely unknown to ODBC Driver. As ODBC Driver is not managing the dataset access, it has no knowledge of whether a dataset is open or closed. Therefore, the stored procedure itself should close the datasets it uses when it is finished with them.
In a similar fashion, if a procedure result creates selection sets in more than the stored procedure's target table, ODBC does not know about these other table selections.
If in fact these datasets are in use in named table form in other parts of the application (meaning that the datasets are registered in the dictionary), the instance of the dataset opened by ODBC is totally separate from the instance of the dataset opened in your stored procedure. Due to the nature of ODBC, the dataset is often opened multiple times, under different aliases. These aliases cannot be known to the stored procedure, nor the procedure programmer.
Summary The paradigm of procedures in the ODBC context is a bit limited for System 1032 procedures, but with minor modifications, the bulk of your application logic is directly callable from ODBC.
Consulting Services Seven Steps to Successful Outsourcing by David Webb
Many Model 204 sites worldwide have outsourced some of their key functions; other sites are still giving outsourcing serious consideration. Experiences have been mixed, so here’s a quick 7-point guide to minimize potential disappointment when you are choosing your outsourcer or reviewing a current contract.
1. Set the scope correctly What should you outsource and what should you keep in-house? Outsource the activities for which you have a choice of outsourcers, so that it is relatively easy to switch if the relationship does not work.
2. Select outsourcers with the right skill set You need not outsource MVS operations to the same company that maintains your PCs. Neither should you feel compelled to outsource your Model 204, DB2 and Oracle systems to the same vendor. Anywhere you can define an interface between one activity and another is a place where you have a unit for outsourcing. The clear business advantages to using multiple vendors are that you can:
3. Check the outsourcer’s hardware and software environment Ensure that they have reasonably modern equipment for processors, DASD, cartridge drives, networking, and so on. Still more important, see how they run their software. The keys to success in the mainframe environment are control and automation. The outsourcer need not have the same software you have at your site as long as they can match functionality. You should check that their existing operation runs very smoothly and that they are able to match their software to your needs.
4. Meet with existing customers Although you cannot expect a large outsourcing contract to be totally without problems, a commitment to good communications between you and the outsourcer should ensure that you both are fairly satisfied with the arrangement. Talk to customers who have been with the vendor for a few years for their impressions of the overall service.
5. Retain your flexibility in the contract In an attempt to get the absolutely lowest headline price, you might restrict yourself too severely in what you can do under the contract, and leave yourself no scope for making changes. Vendors are wise to this game—some are prepared to take a loss on the initial contract knowing that they can make a killing as soon as your requirements change. Pay a little more for the initial contract and build in some flexibility.
6. Retain in-house skills to manage the outsourcer Be very careful of handing over your organization’s unique skills in applications or system management to an outsourcer. If the outsourcing relationship fails, it will not be easy to get those skills back again. Also, remember you have no control over the outsourcer’s ability to recruit or retain key staff. You can outsource work, but you can never outsource ultimate responsibility. You therefore need to retain sufficient knowledge in-house to ensure that you can get the best value from your outsourcer.
7. Seek advice from people who have done it before CCA is happy to give you impartial advice. We’ve had a lot of experience at this, and we’ve spoken to many customers about their successes and failures. As a major provider of outsourcing services ourselves, we can also discuss how we could partner with you to run your Model 204 systems.
Education Schedule May—June 2000
The scheduled location for the following Model 204 courses is Framingham, Massachusetts. For more information call the Framingham office at 508-270-6666.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
Contact CCA Webmaster Copyright 2008
