When you enter a web site URL like:
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.
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.