Testing on my customer's system confirms my thoughts that -with the WebPac/1 extension- a CGI can live in an SFS directory without being listed in CGI FILELIST. The classic way: (DEMOENV CGI lives in SFSD:HTTPD.WEBSHARE.KRIS and is listed in CGI FILELIST on SFSD:HTTPD.WEBSHARE.KRIS) http://vmct/kris/cgi/demoenv The alternative: DEMOENVX CGI is *not* listed in the CGI FILELIST, but this works too: http://vmct/kris/demoenvx.cgi The PACKAGE CHANGES file list this: o CGIs in SFS Changes made to: WEBSRVSP REXX WEBSRVHT REXX
Rick, you write "you should code it and contribute it." I would be pleased to contribute my changes to Webshare (based on the Webpac/1 level): -support SFSdir names longer than 8 chars -support multi-part HTML (or server push) -BFS support Hardcoded convention: when the URL starts with "BFS" or "BFSBIN" we extract files from BFS: for BFS: /../VMBFS:SFSD:HTTPDBFS/ for BFSBIN: /../VMBFS:SFSD:HTTPDBFS/bin/ BFSBIN files are supposed to be stored in ASCII, for others it depends on the filetype (as for CMS files) e.g. .GIF=bin I created BFS support to make imbedding existing HTML document sets (with long and/or mixed case fileids; spanning subdirectories) a piece of cake. The not-so-nice thing is that the updates are directly applied to the REXX execs (i.e. take one extension and not the others would be difficult and Webpac/1 is a hard pre-req). How to proceed if there is interest? 2008/2/20, Richard Troth <[EMAIL PROTECTED]>: > Webshare ... wow ... that goes back a way! > > When using FILELISTs, you can code magical things like "*CGI". For lack of > a better term, let's call that a trigger filetype. But when running purely > from SFS, Webshare internally creates FILELIST streams, so the only > filetypes you get are a real filetypes (undoctored LISTFILE output), not a > trigger filetype. > > Recollection is fuzzy, but I believe you can have CGIs and SFS hierarchy > handled by the same HTTPD v-machine, you just cannot have CGIs living in an > SFS-defined-only kind of space. For CGIs to be executed instead of served > out (like plain files), they must reside on an ACCESSed disk or in an > ACCESSed SFS directory and be listed in a hand-crafted FILELIST. > > If you can think of a way around this, you should code it and contribute it. > :-) > > > > > On Feb 19, 2008 6:04 AM, Berry van Sleeuwen > <[EMAIL PROTECTED]> wrote: > > > Hello list, > > > > I have been playing a bit with the Webshare package from Rick Troth. It > > > > has been succesfull so far but now I ran into a problem running CGI > > scripts. > > > > My webserver machine, HTTPD, is an SFS only machine. (IPL CMS PARM > > FILEPOOL VMSBSFS) > > > > I started with all files in the root of the HTTPD machine. This works as > > > > it should, filelists are ok and also the CGI processing is working fine. > > > > HTBIN FILELIST is available, the CGI files in there are listed as *CGI to > > > > enable execution of the script, and cgi-bin points to HTBIN so I can run > > > > CGI like /cgi-bin/CMSHELP. I can get the CMSHELP in my webbrowser. No > > problem there. > > > > Now I have setup the server to use the .webshare directory and moved the > > > > webfiles into .webshare and subdirectories (like .webshare.vminfo > > and .webshare.htbin). This way we do not have to use the FILELIST files > > > > anymore. It makes adding files and directories much easier. I can access > > > > the regular webpages (home.html, vminfo.html etc). But a CGI is not > > executed. I've tried several ways but so far I was not able to get the CG > > I > > to run. I guess some configuration has to be set to be able to run CGI in > > > > an SFS based structure the same way as it does in a single disk > > configuration. How can I get the webserver to run an CGI exec instead of > > > > sending me the file itself? > > > > TIA. > > > > Kind regards, Berry. > > > > > > -- > -- R; <>< > > -- Kris Buelens, IBM Belgium, VM customer support
