source | info | hyperlink & description |
---|---|---|
Rule |
![]() |
/neon/sampdata/mvsmfram.htm |
This page has been served by a generic rule which handles the
mapping of URLs to individual members of an MVS PDS(E) dataset.
The frameset, individual frames, and images which comprise this
page are each members within a PDS(E) dataset installed with
the server.
The rule deliberately omits the PDS(E) member name from the definition. This causes /*FILE to parse the URL and use the last portion of the URL as a member name. Therefore, when you call for the URL, /neon/sampdata/mvsmfram.htm, the server actually retrieves member, MVSMFRAM, in the PDS(E) dataset which is allocated to the DD name, SAMPDATA.
|
||
Rule
Data |
![]() |
/neon/asmfa100/asmfa101.htm |
The text file called for by invoking this URL contains HTML
extension statements which generate the HTML output dynamically.
The text file will generate 1 of 4 possible HTML pages depending
on information transmitted by HTTP cookies.
GLVSTATE. stem variables are used to set or interrogate the value of the HTTP cookie used to remember the application state.
|
||
Rule |
![]() |
/neon/checkssl |
Displays a static page, but rquires the use of an SSL connection
before execution is allowed (see SSL(YES) on the rule definition).
If the original request arrives on a clear-text session, the
request is redirected to an SSL (HTTPS) connection.
|
||
Rule(REXX)
Rule(PLI) Code(PLI) |
![]() |
/neon/demotokn (REXX)
/neon/plitoken (PLI) |
These sample rules execute either
a compiled PL/I program or a REXX-language WWW rule.
Both demostrate the use of the
Server-side Token facility to save and restore state information
across HTTP transaction boundaries.
|
||
Rule |
![]() |
/neon/demo01 |
This Shadow/REXX procedure generates a table showing the server
runtime variables created when each in-bound HTTP request is
parsed. These variables are available to all web transaction
procedures and are derived from the HTTP request headers and
query variables.
An input form at the top of the sample page can be submitted to show how HTML form query variables are parsed and made available, by name, to transaction procedures.
|
||
Rule(BIN)
Data(BIN) Rule(TEXT) Data(TEXT) |
![]() |
/neon/getfile.bin
(Binary Retrieval) /neon/getfile.txt (Text Retrieval) |
Two generic rules which allow the download of virtually any MVS
dataset or PDS(E) member. The first rule causes the file to be
sent as a raw, untranslated binary stream. The second rule causes
the file to be sent as a stream of text records which have been
translated from EBCDIC to ASCII.
Note that both rules require that a valid MVS userid and password be supplied on the request. Access to the requested MVS dataset is performed under the supplied userid's authorization. When SSL support has been configured in the server, the use of an SSL connection is required. This protects both the MVS userid and password used for the request and the data which is transmitted back to the client.
|
||
Rule |
![]() |
/neon/htxdttm |
Illustrates the use HTML Extensions within an inline data file (the
file data is part of the WWW rule). Shows the results of various
Date and Time built-in function requests.
|
||
Rule |
![]() |
/neon/infosamp |
Displays the runtime values which can be interrogated using the
SWSINFO built-in function and illustrates techniques for formatting
the results using Shadow/REXX.
|
||
Rule
Code |
![]() |
/neon/opsmvs/dal |
Executes the Computer Associates' OPS/MVS II command
executive to display a list of active jobs on the system.
The results are formatted as HTML and returned to the
browser.
Note that you must have a licensed copy of Computer Associates' OPS/MVS II installed on your MVS system in order to execute this sample application successfully. This sample illustrates how you can invoke other REXX interpretors (not supplied by NEON Systems, Inc.) to build specialized web-enabled applications.
|
||
Rule |
![]() |
/neon/refresh |
Executes a REXX procedure which causes the sample data PDS(E)
in-storage directory to be refreshed.
|
||
Rule |
![]() |
/neon/sql |
Illustrates the use of Shadow/REXXTOOLs ADDRESS SQL host command
enviroment. ADDRESS SQL allows REXX-language procedures to select
and process rows from a DB2 table.
This sample is written as a Shadow/REXX procedure and requires the Shadow/REXXTOOLs add-on feature for proper options.
|
||
Rule |
![]() |
/neon/sqlexec |
A rule using EXECSQL to perform a DB2 query and automatically
format the result set as an HTML table.
|
||
Rule
Data |
![]() |
/neon/sqlexec2 |
A rule using EXECSQL to perform a DB2 query and automatically
format the result set as an HTML table. The query is front-ended
with an input form allowing the query to customized.
|
||
Rule
Data |
![]() |
/neon/sqlexec3 |
The sample rule contains an /*EXECSQL widget which performs
a generalized DB2 query and formats the result set for display
at the browser.
|
||
Rule
Data |
![]() |
/neon/sqlexec4 |
The sample rule contains an /*EXECSQL widget which performs
a generalized DB2 query and formats the result set for display
at the browser using HTML Extension Merge processing.
|
||
Rule
Data Data (XSL) |
![]() |
/neon/sqlxml1 |
Illustrates how you can use an /*EXECSQL widget in combination
with an HTML Extension skeleton to generate XML formatted output.
The DB2 query data is formatted into XML, and an XSL style sheet
is used to provide this view of the data.
You will need to use a recent version of Microsoft Internet Explorer to properly view this sample.
|
||
Rule
Data Data (XSL) |
![]() |
/neon/sqlxml2 |
Illustrates how you can use an /*EXECSQL widget in combination
with an HTML Extension skeleton to generate XML formatted output.
The DB2 query data is formatted into XML, and an XSL style sheet
is used to provide this view of the data.
You will need to use a recent version of Microsoft Internet Explorer to properly view this sample.
|
||
Rule
Data |
![]() |
/neon/swhproxy |
Demonstrates the use of a REXX-langguage HTTP client-side proxy
application. The client-side proxy routine is executed within an
out-board TSO server address space to retrieve an item from a
remote web server. The response is then written back to your
web browser by Shadow OS/390 Web Server.
This sample application requires that the TSO out-board server facility be configured.
|
||
Rule
Rule Code |
![]() |
/neon/rpcdb21a |
This is a sample DB2 program that reads the Q.staff table
supplied by QMF. By specifing a valid JOBID only the rows
where the job matches the parameter entered will be
returned.
|
||
Rule
Code |
![]() |
/neon/rpcims1 |
This is a sample IMS program that uses CBLTDLI to access the
IMS Parts database and return a list of parts in the IMS
database. The IMS Parts database is part of the IVP install
of IMS.
|
||
Rule
Code |
![]() |
/neon/rpcims2 |
This is a sample program that uses the Transaction Server
for IMS feature of the Shadow Web Server which uses
IMS/APPC. This particular sample executes the existing IMS
transaction PART, to return information on part no. 3007228.
|
||
Rule
Code |
![]() |
/neon/rpcims3a |
This is a sample program that combines both features of
Shadow Web Server's IMS support. This sample will first call
a program that uses CBLTDLI to return a list of parts in the
IMS PARTS database. An input field is provided where a user
can specify any part number to gain additional information
for. Once the submit button is pressed, the parameter is
sent to another program. This program uses the Transaction
Server for IMS feature to execute the IMS PARTs transaction
using the supplied parameter as input to the transaction.
|
||
Rule
Code |
![]() |
/neon/rpccics1 |
This is a sample program that uses the Transaction Server
for CICS. It executes the sample rpc SWCOCIEC which does a
dynamic program link to a sample CICS program named DFH$AXCS
that reads the CICS sample vsam file, FILEA.
|