Model 204 Customer Survey
Panning for Golden Nuggets
By Chris Ramsdale
Please return the Model 204 Customer Survey 2002 by August 31, 2002, so we can share your thoughts and ideas with everyone at Insight/204, which is being held in Boston September 17-20. You are very welcome to attend Insight/204. To see what else will be discussed and happening at Insight/204, link to http://www.cca-int.com/iresources/usergroups/insight/main.html and start making arrangements to join us.
Insight 204 CCA's Insight 204 to Highlight Model 204 Version 5.1 and Beyond
By Marie Kelly
With a new version of Model 204 recently released, and a critical product planning cycle underway, there simply couldn't be a better time for the second Insight 204 Symposium than this September. For three days, customers from all over the world will gather in Boston with key CCA staff and partners to learn how to exploit the new features and performance enhancements in Version 5.1, and to discuss what is required in future versions of Model 204.
"Everyone at CCA is very excited about this year's Symposium," explains CEO Rick Ryan, "because not only do we have a lot to tell the customers about Version 5.1, there is also a lot we want to hear from our customers -- about what they need from Model 204 in the future."
What's New With Model 204?
This year's symposium focuses heavily on helping customers understand the ins and outs of the new features. Along with Model 204 Version 5.1, CCA also announced new releases of other products, including CCA Analytics Version 2.1, Connect« Version 5.1, and JDBC for Model 204. To explore each of these new releases, the following sessions are currently scheduled for Insight 204.
v Model 204 Version 5.1: Packed with Performance
v Streamlining Restart Recovery
v New Version 5.1 User Language Features and Functions
v External Call Facility (ECF): Invoking External Procedures from User Language
v NonStop/204: Perpetual Processing and Thread Synchronization
v Connect* Version 5.1: Faster, Better, and Multi-Threaded
v JDBC for Model 204: Model 204 Goes Java
v CCA Analytics Version 2.1: Improved Business Intelligence for Model 204
v MQ/204: Integrating Model 204 with the Enterprise
v The Jim Damon Version 5.1 Performance Report
v Advanced Model 204 Version 5.1 Topics for System and File Managers
v Model 204 Version 5.1 Installation Refresher
v Advanced Model 204 Version 5.1 Topics for Programmers
v Connecting with the Power: Exploring Connect« and JDBC for Model 204
Forward Thinking
In addition to the new releases, a portion of this year's conference will be devoted to the future of Model 204 and helping CCA staff better understand customers' needs in subsequent releases. The 2002 Product Planning cycle is currently underway, and the results of the survey will provide an excellent platform for discussing market directions, customer needs, and the future of Model 204. After presenting the results, this year's symposium will feature several roundtable discussions designed to further explore certain development areas and solicit customer feedback early in the development cycle.
If you have not yet registered for Insight 204, make a point to do it today! Once again, registration is FREE, because we want to ensure that all active Model 204 customers have easy access to the information that can help them get the most out of their Model 204 investment.
Model 204 CCASTAT: Sharing the Model 204 Password Table
By James Damon
Large organizations with numerous Model 204 logon IDs and file passwords have a daunting task maintaining those IDs and passwords. That task would be even more challenging if the same logon IDs and file passwords had to be maintained in multiple places. Fortunately, under Model 204, that security information can be centralized in a single, shared copy of the Model 204 file password table--CCASTAT.
What is CCASTAT
CCASTAT is the DDNAME associated with a small, sequential dataset which is the encrypted password table used by native Model 204 algorithms to provide login and file level security. The table consists of two types of entries, each 26 bytes in length (assuming terminal security is not used):
At 26-bytes per entry, roughly 2000 user ID and file entries could be stored on a single, 3390 DASD track.
Since CCASTAT is a sequential dataset (DSORG=PS), no special backup utility is required. It can be backed up with any operating system utility that can copy a sequential dataset--IEBGENER, FDR, DFDSS, DITTO, and so on.
CCASTAT can also be backed up using the COPY STREAM command in a Model 204 ONLINE or BATCH204 job:
This facility can be used to copy any sequential dataset and is particularly useful in VM/CMS environments where sequential dataset support is nonexistent.
How CCASTAT operates
During Model 204 initialization, the entire CCASTAT dataset is read into memory as indicated by the message:
For performance reasons, the dataset remains in memory for the duration of the run. Therefore, processing every user login or OPEN FILE command can be performed by accessing the in-memory copy, which greatly enhances the speed of those operations.
Sharing CCASTAT between multiple Model 204 jobs
When the LOGCTL command is issued, the in-memory copy of CCASTAT is refreshed by rereading the current version from disk. This ensures that any changes made to the dataset, which may be shared by other ONLINE or BATCH204 jobs, are reflected in the current job's copy. When the LOGCTL dialog completes, the updated in-memory copy is rewritten to disk. This process is repeated whenever any Model 204 job issues the LOGCTL command and provides support for sharing CCASTAT between multiple Model 204 jobs.
Figure 1 illustrates this process:
Figure 1. A CCASTAT refresh cycle between Onlines PROD and TEST
The last update by the TEST Online added the USERID=BILBO to CCASTAT. However, this new ID cannot be seen by the PROD Online until it performs another update to CCASTAT.
Note: Updates made to CCASTAT--new user IDs, new file passwords or changes to existing entries--cannot be seen by other, already-running Model 204 jobs unless they too perform some type of update. Dummy updates may be required when you know that updates to CCASTAT are being made in one Model 204 job that are required to be known in another, already-running Model 204 job.
Summary
When using native Model 204 security features, sharing the CCASTAT dataset between all Model 204 jobs is essential for maintaining central control of all user IDs and file passwords. This allows an organization to define and maintain Model 204 user IDs and file passwords in one and only one place and helps reduce the effort of providing system, file, field, record, and procedure-level security.
Customers who currently use external security packages, such as ACF2, RACF or TOPSECRET, for system-level security may choose to install the corresponding Model 204 Security Interface and further centralize the maintenance of user logon IDs under that interface. However, in those cases CCASTAT is still required for file passwords. More information about these security interfaces can be obtained by contacting CCA Customer Support or your sales representative.
System 1032 Compaq Secure Web Server
By Tym Stegner
One thing we took away from our trip to the OpenVMS Partner's Roundtable, which I described in On the Road with OpenVMS, was a determination to try out the Compaq Secure Web Server (CSWS), an OpenVMS Web server supplied by HP/Compaq. This Web server is an OpenVMS port of the well-known Apache Web server. We were inspired by the directness of running on OpenVMS, without any additional hardware, and the easy access to other OpenVMS features.
Installing CSWS
Information about the requirements and prerequisites for installing CSWS are available on this OpenVMS Web site:
www.openvms.compaq.com/openvms/products/ips/apache/csws.html
Although the software is available as part of the OpenVMS V7.3 update, the most current version is available from the Web site. You can also download the installation documentation from this site.
First, Patches
As prerequisites I needed to install four OpenVMS patch kits before installing CSWS, so I downloaded all these kits as well as the CSWS kit. These kits are compressed files. Once they are on your system, give the RUN command for each patch file to extract the Polycenter Software Installation (PCSI) file.
I had never actually used the PRODUCT command before, and I found it to be easy to use. Following the general directions for patching, I backed up an image of my system disk, which is recommended to ensure you can fall back to an operating system, should anything go awry in the patching or installation process. Then, I applied each patch file in turn. And finally I rebooted the system to integrate the fixes.
Next, CSWS
As everything appeared to work after this reboot, I installed CSWS itself--again, no problems. After installation, you must execute the configuration file to set up command files, logins, and directory areas for the actual operation of the Web server. When this is done, you are directed to start the Web sever via a startup command file.
Note: This same command file is also to be executed at system startup.
Using a verification Web page that is included, I pointed my trusty browser (Netscape) at the indicated URL: Huzzah! The Web page displayed correctly! I was now operating a true OpenVMS-based Web server!
CSWS Capabilities
The installation includes on-line documentation on the maintenance of the Web server itself, as well as programming and security information. Post-installation configuration of the CSWS environment is apparently very much like non-OpenVMS configuration, allowing for the difference in the file system environments. Another verification feature is found in the CGI-BIN directory: a demonstration command procedure. A welcome feature of CSWS is the ability to do CGI programming directly in DCL. This demonstration COM file listed all the CGI environment variables, which are just DCL symbols.
Testing the System 1032 Interaction
As a further test of the environment, I whipped together a simple System 1032 report command file, as follows:
$! TEST-S1032.COM $! $ write sys$output f$fao("!AS!/","Content-type: text/plain") $ write sys$output f$fao("!AS!/!/","Test of S1032/CSWS") $! $ run s1032_image:s1032 open db movies in s1032_demo read find film beg "THE L" print film by lof repeat exit $! $ write sys$output f$fao("!/!AS!/","End S1032/CSWS Test") $! $ exit
Two items to note in particular:
I loaded the test file URL and received the following output:
Test of S1032/CSWS
Generated on GNAT at 26-JUN-2002 13:44:15.57.
Computer Corporation of America System 1032 Version V9.80-0
Copyright 2002, Computer Corporation of America
4 datasets opened in MOVIES
Current dataset is now FILMS, current database is MOVIES
Length of Film
---------
Film Title
-----------------------------------
End S1032/CSWS Test
Happy Implications
What does this mean? With a single minor modification to any existing System 1032 command file, the output of the command file can be served to the Web.
It means that by using CSWS, System 1032 sites can immediately begin to serve data.
I also noted a demonstration executable in the CGI-BIN directory--similar to the DCL test procedure. This suggests that 3GL-based System 1032 programs could also be used to create server content by following the previous caveats.
Content-type MIME Type
A brief follow-up to the Content-Type MIME type in the COM file. I had no HTML output present within my sample System 1032 report procedure. Therefore, the text/plain value was appropriate for this output--treating all text as if it was within <PRE> tags.
Should you choose to include HTML tags in your generated output, the proper value for the Content-type MIME type would be text/html. In a similar fashion, if you are going to generate more exotic pages, you must specify the Content-type MIME type value correctly.
Passing Parameters
Many System 1032 report procedures take their input as command line parameters, which can be made to work with CSWS in two ways:
http://gnat.cca-int.com/cgi-bin/test-s1032?p1=AAAA&p2=ZZZZ
In both cases the command procedure must have a slight modification to unpack the QUERY_STRING global symbol into the actual parameter information, and to arrange for passing this information into the System 1032 environment, if it is not already doing so.
The format of the query string information is as follows:
Name=Value[&Name=Value...]
This style of string lends itself to relatively easy manipulation at the DCL level, by using the F$ELEMENT lexical function to parse the parameters from the string. While this could be made very generic, let us assume that parameter names are just Pn. Therefore, code to parse a query string of two parameters might work as follows:
$ show symbol QUERY_STRING QUERY_STRING = "P1=AAAA&P2=ZZZZ" $ P2 = f$element(1,"&",QUERY_STRING) $ P2 = f$element(1,"=",P2) $ P1 = f$element(0,"&",QUERY_STRING) $ P1 = f$element(1,"=",P1) $ show symbol P1 P1 = "AAAA" $ show symbol P2 P2 = "ZZZZ"
The F$ELEMENT function is zero-based, so to locate the second element I used the number 1. To get the first element, I used the number 0. In a similar fashion, the F$ELEMENT function is used again with a different delimiter to extract the value portion of the name=value sub-string.
Note: Depending upon your CSWS configuration settings, the CSWS global symbols may all be prefixed with the string WWW_.
While by no means exhaustive of the capabilities inherent in CSWS and System 1032 interaction, we can see many possibilities for data serving using this Web server. CSWS lets us leverage the use of our existing OpenVMS and System 1032 systems, providing value with little or no additional costs, and without need to use other programming languages beyond System 1032 and DCL.
The System 1032 development team plans to investigate creating a module for CSWS to allow direct System 1032 interaction with the Web server, similar to the existing JAVA and PERL modules, which are extensions to core Apache features that enable specialized functionality.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
Contact CCA Webmaster Copyright 2008
