Differences between WebSphere Application Server on z/OS or OS/390 and Workstation platforms
 Technote (FAQ)
 
Problem
This is a summary of the basic differences exist between WebSphere® Application Server on z/OS® or OS/390® and the corresponding version on the workstation platforms.
 
 
Solution
COMMONALITY OF CODE
The z/OS and OS/390 versions of WebSphere Application Server incorporate updates from the workstation or distributed platforms about once every six months. The z/OS and OS/390 versions of the Application Server are usually compatible with the distributed versions. The following discussions cover the main differences.

EBCDIC FILES VERSUS ASCII FILES

On the distributed platforms, HTML files and JAVA™ Server Pages, are stored in ASCII format. On z/OS and OS/390 it depends on the JSP specification level. If running with level 0.91 and 1.0 files are stored in EBCDIC format. If running specification level 1.1 files served by the Application Server are stored in ASCII.

Files in the classpath deployedwebapp.<webapp-name>.classpath require an ASCII format.
For more information on using EBCDIC versus ASCII formats for WebSphere Application Server on z/OS or OS/390, see the latest documentation for the appropriate version of the Application Server at the following URL:

http://www.ibm.com/software/webservers/appserv/library_390.html

SESSION INVALIDATION

Currently the Application Servers on z/OS or OS/390 have implemented a stricter set of rules for the invalidation of sessions than the Application Servers on the distributed platforms.

Whether you use z/OS, OS/390, or a distributed platform, a session can become invalid in one of the following ways:
  • The session can automatically expire after a set amount of time.
  • You can use the invalidate( ) method on a specific request to invalidate a session that was previously obtained for this request through a getSession( ) method.

Because the Application Servers on the distributed platforms are more lenient, a session can become invalid on these platforms for the following reason:
  • You can invalidate a session on a request using a session ID that was not obtained through a getSession( ) method for that request. For example, you can invalidate one session on a request associated with another session.
If you create your application on a distributed platform using this technique, and then port this application to the z/OS or OS/30 operating system, you will not be able to invalidate the session. The Application Servers on the z/OS or OS/390 operating systems throw an

IllegalStateException.

A description of this technique used on the distributed platforms follows:
  1. You open a browser, access your Web site, and log into your application as username.
  2. The Application Server creates a session object and a session ID associated with this request if the application did a getSession( ) method. The session is called Session 1, the session ID is called S1, and the request is known as Request 1.
  3. While logged onto your application from the same browser, the user makes a new request. This request is known as Request 2. Given that the application did a get session for Request 2, the session ID returned by the Application Server is the same session ID created for Request 1.This session ID is S1.
  4. The Application Server associates the session ID of S1 with Request 2 because a cookie passes S1 to the Application Server, with the request object for Request 2.
  5. If you open another browser, access your Web site and log in as username, the Application Server creates a session object and a session ID associated with the second browser, given that the application did a getSession( ) method. This session is called Session 2, the session ID is called S2, and the request is known as Request 3. A new session object, Session 2, was created because Request 3 came from a new instance of the browser. The new browser instance did not have any cookie information. Therefore, no session ID was passed to the Application Server on Request 3.
  6. When you make additional requests with the second browser session, a cookie passes the session ID of S2 to the Application Server.

Customers have written applications that save the session ID reference for Session 1. When the customer makes Request 3, the application can then determine that jsmith associated with Session 1 and jsmith associated with Session 2 represent the same user. The application determines that Session 1 is older than Session 2. Because Session 1 is older, the application attempts to explicitly invalidate the session ID of S1 on Request 3 by using the invalidate method. However, S1 is associated with Session 1 and Request 3 is associated with Session 2.

The z/OS and OS/390 versions of the Application Server do not allow invalidation of the session ID of one session on a request from another session. Invalidate S1 by issuing a request that contains the S1 session ID established for Session 1. Otherwise, the Application Servers on the z/OS or OS/390 operating systems will throw an IllegalStateException. The Application Server on the distributed platforms do not throw this exception.
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server for z/OS
Operating system(s): z/OS
Software version: 4.0.1
Software edition:
Reference #: 1063445
IBM Group: Software Group
Modified date: Apr 1, 2004