Accessing Resources

When you enter a web site URL like:

http://www.mysite.com/somelocation/pages/index.html

The part (/somelocation/pages/index.html) following the domain name is the location of the resource on the site that you want to access. Within a simple site, such resources are typically static and represents the path to the file name (index.html in this case) under the servers root document location. Thus in this example there would be a file structure that looked like this:

server_root (dir)
     |
     + ----> somelocation  (dir)
                 |
                 +-----> pages (dir)
                           |
                           +-----> index.html (file)

Obviously this requires that the environment running the web server supports long file and directory names. On z/OS this would require that the server’s resources be stored within the Unix System Services (USS) file system. Whilst that is perfectly acceptable it does add additional setup requirements to give the server access to the USS file system and so, in the interests of simplicity (I’m a great fan of simple) let’s look at what it takes to do this using native z/OS files.

Unless you are using a specialized environment to build your web server (like CICS), the simplest file type to use are PDS (or PDSE) and sequential files. One simple way to use sequential files for each resource is to use each level of the resource path as a data set qualifier.  For example if the server’s ‘root’ is ‘SYS1.MYSERVER’ then you might have a sequential file called SYS1.MYSERVER.SOMELOC.PAGES.INDEX.HTML. Obviously this means that you cannot use long names (greater than eight characters) as the path and resource names and that the resultant file name itself including the ‘root’ part cannot be longer than 44 characters in order to conform to z/OS data set naming conventions. The problem with this method is that you are very quickly going to need a LOT of files, even for a simple site.

A simple alternative is to use partitioned data sets, one per resource ‘type’, for example one for html files, one for javascript files, one for jpeg images etc. Each member contains the resource itself such as a web page. For example the index.html page would be in the ‘index’ member of the html PDS. The downside to this implementation is that it really limits you to a single path. In other words, everything is under the ‘root’ location. Obviously you could extend it to some degree using a combination of the previous implementation to ‘extend’ the partitioned data set file names used to hold the resources but the sort of simple ‘site’ that this RYO server is aimed at providing probably does not need that sort of structure and if it does then maybe you need to re-access the decision to use a RYO server or native z/OS files instead of USS files.

So let’s say that a request arrives for a resource, say ‘heading.jpg’. How does the server locate it? Simple really. Break the resource name down into the name part (‘heading’) and the resource type (‘jpg’) then located the PDS holding jpeg files, locate the member (‘heading’ in this case) and return it to the client with the appropriate mime type. You might still need to be able to handle long resource names though. Why? Because some tool kits, for example the jQuery UI tool kit, make use of long names for items such as image files. Since your images are store in members with eight character names you need some way to ‘map’ the long names used by the tool kit to the member names unless you want to edit the tool kit every time you update it.

The simplest way I have found to do this is to use an ‘index’ member in each resource PDS. The index member simply contains a number of lines. Each line contains the ‘long’ resource name and the associated member name that contains the actual resource. If the requested resource name is eight characters long or less then the server first attempts to read it as a member. If the name is not found or the name is longer than eight characters, the server reads the index member and searches for the named resource. If found it then reads the associated member and returns that to the client with the appropriate mime type set. If the resource cannot be found the server returns a 404 (not found) response.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: