ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
