CCAPrint Newsletter for Model 204 and System 1032 Users


Home			Downloads\|	\|	Feedback

CCAPRINT: A Newsletter for Model 204^® and System 1032^® Users

August 10, 2000

Model 204 - Using Remote Command Line: Part 3
System 1032 -Developing a trigger-based auditing system

Model 204
Using Remote Command Line: Part 3
by Mark LaRocca

Using RCL in a Web application

Previous RCL articles used a client-server program to illustrate a Model 204 command line interface. In this article, I present a sample Web-based application, called Model 204 User Interface, to demonstrate the use of RCL and WebGate.

Model 204 User Interface illustrates that User Language procedures supporting 3270 applications can be used directly with a minimal, if any, changes to drive state-of-the-art Internet access to Model 204 data for information retrieval and manipulation.

Accessing a Web-enabled application

You can download a copy of Model 204 User Interface at: www.cca-int.com/webdemo/webSample.exe

Of course, to run this application you need to install WebGate. For information on how to do this contact CCA.

Put the downloaded pages on your NT Web server and youíre ready to go. Itís as simple as that.

Model 204 User Interface does the following:
Populates drop down boxes using WebGate tags.
Issues RCL (or SQL) requests.

Formats data using WebGate tags and VBScript.

In this article, we are concentrating on the RCL aspects of this application, only noting the SQL and VBScript. Now letís see how it works.

Model 204 User Interface in action

First, to display the homepage, enter the URL: http://localhost/M204ui/User_Main.htm

The home page is two separate horizontal frames. The lower frame displays the output, User_Output.htx, and the upper frame accepts input, User_Input.htx. In Figure 1, the selections in the User_Input.htx area are completed as follows:

From the Data Services drop down list that contains all the WebGate Data Services available from the Web server, AUTOINS_RCL was chosen. Each Data Service describes an ODBC connection to an Online.
RCL was selected from the RCL/SQL drop down box.
VIEW command was entered in blank text box.

Figure 1: Model 204 User Interface home page

Examining source code

Letís look at some of the code for User_Input.htx which begins with a default error page:

<wdbgo_fail=/M204UI/generror.htx>

<html>

<head>

<title>Model 204 User Interface</title>

</head>

<tr>

<font face="Times New Roman" size="5"><i><b>Model 204 User Interface</b></i></font>

</td>

<td align="left" width="25%">&nbsp</td>

<td align="left" width="35%">

<font face="Times New Roman" size="-1">

(Current Date:  ##wdbdate##    Time:   ##wdbtime##)

</font>

</td>

</tr>

</table>

<hr size="4">

<form method="POST" action="/cgi-bin/wecgi.exe/M204UI/user_output.htx" target=outarea>

<wdbreq_name=DSN>

<wdbdsn="RequestServer">

<wdbstatement="LIST HITS">

<wdbrowcount=99>

<wdboutput=FORMATTED>

<wdbaction=execute>













<table border="0">

<tr>

<td align="left" width="40%" nowrap>

Data Service :

<select name="WDBDSN" size="1">

<wdbformat_area=DSN>

<option>##DSN.1##</option>

</wdbformat_area>

<wdbaction=display>

</select>

</td>

RCL/SQL: <select name="UIMode" size="1">

</select>

</td>

</tr>

</table>

</p>

</form>

</body>

</html>

User_Output.htx

Enter a VIEW command and press Submit to cause the Web server to execute the output page, User_Output.htx, and pass it to WebGate to interpret and execute. Figure 2 illustrates typical results.

Figure 2: VIEW command results displayed in User_output area

The following code we examine displays the RCL command results on the output page.

<! Following code interprets input and returns results within a text area box -->

<wdb_if source=CCAUISubmit CHECK=VAL_EQ PARAM="Submit">

<wdb_if source=UIMode CHECK=VAL_EQ PARAM="RCL">

</WDB_IF>

</form>

</body>

</html>

Conclusion

You can see from the previous code that RCL data is very easy to format, simply enter one command, <WDBACTION=SELECT>, to tell WebGate to place the data here, exactly as Model 204 formatted it. That was a quick explanation of a quite powerful application, a Model 204 command line interface that can be executed from any Web browser. Donít forget, you can download these code pages and try them yourself.

Coming articles

I have only mentioned that SQL can also be executed in Model 204 User Interface. In a future article we will explain the fancy formatting which can be done in VBScript.

System 1032
Developing a trigger-based auditing system
by Tym Stegner

Recently I worked on a project to integrate various System 1032-based data sources at CCA. I did this project wholly within PL1032ópartly to exercise System1032 features such as triggers and partly to bypass the 3GL overhead of converting all data types to text for comparison purposes.

The following HISTORY dataset defines the audit records:

Dataset HISTORY Comment "System-wide add/change audit data"

Atr HSTDSN or DATASET_AUDITED Text 13 title "Audited DS"

Atr HSTREC or RECORD_ID Integer fmt i5 title "Rec#"

Atr HSTATR or ATTRIBUTE_NAME Text 6 title "Attr"

Atr HSTYPE or UPDATE_TYPE Text 1 title "Typ"

Atr HSTOLD or OLD_VALUE Text 50 fmt s45(a) title "Old Value"

Atr HSTWA or WHO_CREATED User of Entry title "WhoCRE"

Atr HSTDA or WHEN_CREATED Date_Time of Entry title "WhenCRE"

End_Dataset

Depending on the type of update, the following infomation is required in an audit record, as well as the dataset name, the $ID of the record, who updated the record, and when.

For an ADD operation, the UPDATE_TYPE is set to the value "A"

For a CHANGE operation, the UPDATE_TYPE is set to the value "C". The values of ATTRIBUTE_NAME and OLD_VALUE are stored, as the new value is now present in the audited dataset record.

The auditing process for this project specifies that when a record is:

Added to a system table, create an audit record tracking the ADD action.
Changed (limited to single record mode), store the preimage of the record, then compare the attribute values after the change, and create an audit record for each changed attribute value.

These rules are encoded in an AUDIT trigger procedure that is placed into each of the audited datasets that comprise the upgraded system. A template of the AUDIT procedure follows:

Variable v<dsc> Group of ! ds global variable; list of updateable attributes

x<atr> <type>...

End_Group

Procedure AUDIT Trigger ADD CHANGE BEFORE AFTER COMMAND; ! trigger subroutine

var ix,xTiming,xCommand integer

var dx text varying

let xTiming = $trig_timing(0),

xCommand = $trig_cmd(0)

If xTiming eq 0 Then !xTiming=before

If xCommand eq 1 Then !xCommand=add

Let v<dsc> = Missing

Else !xCommand=change

If $SRMODE or $NREC eq 1 Then !valid selection?

Let v<dsc>.x<atr> = <atr>, !assign old values

...

Else !invalid selection

Let $STATUS = $CANCEL_CMD !cancel CHANGE command

End_If !end-valid

End_If !end-xCommand

Else !xTiming=after

Let dx = $CURRENT_DATASET, !store context data

ix = $ID

If xCommand eq 1 Then !xCommand=add

If $NREC eq 1 Then !valid selection?

Call HSTADD(dx,ix)

End_If !end-valid

Else !xCommand=change

If $SRMODE or $NREC eq 1 Then !valid selection?

call HSTM??(dx,ix,"<atr>",v<dsc>.x<atr>,<atr>) !Data type-specific

... ! call for each updatable attribute

End_If !end-valid

End_If !end-xCommand

End_If !end-xTiming

End_Procedure

The AUDIT procedure requires a global variable to store the old values of a CHANGE operation; it is declared before the procedure definition. I chose to use a Group variable, as this allows a simple LET statement initialize the variable for pre-CHANGE imaging.

The trigger system functions determine what command is executed against the dataset, and when the trigger is fired: before or after the command. As the trigger is defined only for the ADD and CHANGE commands, it checks for only one command value, letting an ELSE clause handle the alternate value.

In a Before-Change command block, the AUDIT procedure checks for a single record selection set, and assigns the old attribute values into the Group variable. If the selection set is not in single record mode, the trigger procedure aborts the CHANGE command.

In an After-Add command block, a call to a utility procedure adds the new recordís existance into the HISTORY dataset.

In an After-Change command block, a data type-specific procedure compares the old and new values. For nonmatching values, a record is added to the HISTORY dataset. The data-type-to-data-type comparison not only avoids translating every value to text for the comparison, it also handles missing values on either the old or new value side. After the comparison, if the values differ, the audited value is converted to text for the add to the HISTORY table.

Sample data type-specific procedure

Procedure HSTMTX(- !Text n and Text Varying

pDSNAME : text varying,

pRECORD : integer,

pATRNAM : text 6,

pVALOLD : text varying,

pVALNEW : text varying )

var nx text varying init "!@#$%^&*()" !missing comparison value

if $cvtmiss(pVALOLD,nx) ne $cvtmiss(pVALNEW,nx) then

Add To HISTORY -

DATASET_AUDITED pDSNAME,

RECORD_ID pRECORD,

ATTRIBUTE_NAME pATRNAM,

UPDATE_TYPE "C",

OLD_VALUE $trim(pVALOLD);

end_if

End_Procedure

In the case of logical data, the comparison algorithm is extended to include the possiblity of MISSING as a third value, rather than just as a replacement of the missing value itself. This is required because there is no possible alternate value to use for comparison when the logical values are missing.

For some sample dataset implementations of this auditing procedure, the HISTORY.DMD, and comparison procedures, visit FOX.CCA-INT.COM via anonymous FTP; and check the CCAPRINT subdirectory.


Home DownloadsownFeedback