Using ASP to communicate to a mainframe

by Bob Dombroski

In this example I will expand upon the filesystemobject along with session and application variables to commuicate with a terminal emulator to process mainframe transactions.

In this example I will expand upon the filesystem object along with session and application variables to commuicate with a terminal emulator to process mainframe transactions.

I refer to two different transactions in this article, the first is what I call the secure transaction. This type of transaction has the security built within the transaction itself. This could mean a password or identifer is embedded in the transaction. The second type I refer to as a unsecure transaction. This type of transaction assumes a secured system protects the transaction. Both these terms are completely made up by me...if they resemble real documentes terms it is completely by coincedence. Another term I made up is port_files. What I mean by this is that files are used to port information between 2 applications.

Example : The XYZ insurance company has an office. Before an agent can process transactions he must he must successfully  sign into the system at the office. Once signed in he can process transactions. This is what I call unsecure transaction. Lets say the insurance company also has an internet site where its customers can log in and view their upcoming premiums. In the web site they build a transaction where the password the web surfer entered is actually part of the transaction. The first step in processing the transaction is to verify the supplied password is correct for the suppllied account number, if it is not then the transaction fails.

Okay now you know my interpretation of secure and unsecure transactions so lets move on.

The secure transaction

The first page: Premium_View.htm

We set up a web page that will  collect the account and user information for the premium view transaction. This is just a  post form that passes the variables to the port_file.asp page which does all the work.

Page 2: Port_file.asp

This page gathers up the information passed to it and creates a port_file transaction. The transaction I create contains a numeric value(represents which transaction) the policy number and the password. There is a bit of security built in this method. We could just as easily create the full transaction within the ASP page, but by having the terminal emulator build the transaction  we can limit the transactions to just those the emulator is coded for. Once we create the port_file transaction we must find the next available port_file.  If the transaction has heavy traffic this could be difficult if we just try to see if a file exists. With timing issues you could get a false on the file exists, but by the time you actually open the file another web user could have written that port_file. To get around this I use an application variable called port_nbr_open which is just a string = "0000000000". This example allows up to 10 ports open, you could increase or decrease this number if needed. Using the application lock method I can stop all other users from updating the string until the current user is done. Once locked I find the first "0" and change it to a "1", then unlock the application. All other attempts to find an open port number will see this port number is taken.

Once we have an open port_file we write the transaction to the file and close it.   Then the ASP page waits for a reply port_file for that port number. Once received it can reply with the information contained in the port_file and delete the port_file response. It also must unlock that port_number from the application variable.

Enough for the talk lets go to the code! Sorry there is no working example of this one.

This article was originally published on Oct 27, 1998
Page 1 of 4

Thanks for your registration, follow us on our social networks to keep up-to-date