Loading with the SIRPUT utility

The SIRPIPE and SIRPUT utilities can be used to load a mainframe file into a Model 204 procedure, solving some of the problems inherent with the types of files that may be stored as procedures for Janus Web Server.

Overview of SIRPIPE

SIRPIPE is a program which copies an input stream to an output stream. It is typically used for preparation of input to the BATCH2 program, which provides an input stream to a Model 204 Online program. SIRPIPE consists of a single stand-alone load module.

SIRPIPE uses multi-buffered BSAM input for the input stream. This allows overlap of BSAM input and other processing. In addition, this allows SIRPIPE to take advantage of chained scheduling under MVS.

SIRPIPE has special provisions to provide an output stream that is well-suited for input to BATCH2, particularly when used for loading streams into Model 204 procedures. SIRPIPE also has special provisions for storing binary files, usually graphic images, for use with Janus Web Server.

SIRPIPE overcomes some limitations due to the Model 204 and/or MVS or CMS environments.

SIRPIPE will run under both MVS and CMS.

Running SIRPIPE consists of defining the input and output datasets and directing the operating system to invoke the SIRPIPE program. Invocation is shown below for each operating system; dataset definition is shown below in an operating-system independent form. For examples of dataset definitions specific to the operating system, see "SIRPIPE example for MVS" and "SIRPIPE example for CMS".

Invoking PGM=SIRPIPE in MVS

This is the skeleton JCL used to invoke SIRPIPE in MVS:

//PIPESTEP EXEC PGM=SIRPIPE,PARM='CC=ccval' //STEPLIB DD DISP=SHR,DSN=... Sirius load library //SYSUDUMP DD SYSOUT=* //... DD ...

See:

• "DD names/FILEDEF statements"
• "SIRPIPE program parameters"
• "SIRPIPE example for MVS".

Invoking SIRPIPE module in CMS

This is a skeleton REXX program used to invoke SIRPIPE in CMS:

/* Invoke SIRPIPE */ 'FILEDEF ... 'M204CMS SIRPIPE (CC ccval'

Note that there is no equal sign between CC and ccval; the Model 204 CMS Interface (M204CMS) inserts an equal sign between them before the SIRPIPE module receives control.

See:

• "DD names/FILEDEF statements"
• "SIRPIPE program parameters"
• "SIRPIPE example for CMS".

SIRPIPE program parameters

CC=	This is the continuation column value, which defines the handling of long input records in the PIPEIN DD, and the default CC value inherited on TEXT inclusion directives. See "Text mode" for a description of the CC parameter.

DD names/FILEDEF statements

All input and output datasets must be defined and available to SIRPIPE via either the FILEDEF statement in the CMS environment or the DD statement in the MVS environment. In the description of SIRPIPE, the term DD is used to refer to the both the DD statement under MVS and the FILEDEF statement under CMS.

DCB parameters are not required on any input nor output DD statements. SIRPIPE supports unlike dataset concatenation for all input datasets. Following are the restrictions on DCB parameters for SIRPIPE datasets.

PIPEIN	PIPEIN is that dataset that is the primary input to SIRPIPE. Every record is either copied directly to PIPEOUT or interpreted as a SIRPIPE directive as explained in "SIRPIPE transformations and directives". The restrictions on SIRPIPE's DCB parameters also apply to any dataset opened as a result of an inclusion directive. RECFM Must be V[B] or F[B]. LRECL Must be 32,760 or less. MVS does not allow records longer than 32,760 bytes; although CMS allows records longer than this, SIRPIPE will fail with an OPEN ERROR 4 if records are longer then 32,760. If you have an image file which was transferred to CMS using FTP, and the file has records longer than 32,760, perhaps you used type ASCII in the FTP. Image files should be transferred with FTP as BINARY to get correct image information; this should also ensure that the file does not have any records longer than 32,760.
PIPEOUT	PIPEOUT is the primary output from SIRPIPE, containing records exactly as they occurred in PIPEIN and transformed records from datasets processed as a result of SIRPIPE inclusion directives. RECFM Default is VB; it may also be V or F[B]. BUFNO Set to 1; any other specification is ignored. LRECL Default is the maximum of the following: PIPEIN LRECL (minus 4 if it is RECFM V) 67 (to allow for BINARY or BASE64 inclusion) Value of CC from program parameters. If the PIPEOUT RECFM is V[B], 4 is added to the largest number chosen from the above list to set the default PIPEOUT LRECL. LRECL must be at least: 67 (to allow for BINARY or BASE64 inclusion) Value of CC from program parameters BLKSIZE Default is: LRECL if RECFM is F LRECL+4 if RECFM is V Calculated from the track size (if known) or 32760 (otherwise) to be either the largest multiple LRECL less than or equal to that value, if RECFM=FB or exactly that value, if RECFM=VB BLKSIZE must be a multiple of LRECL, if RECFM=FB or at least 4 greater than LRECL, if RECFM=VB.
PIPRINT	PIPRINT is the dataset that receives SIRPIPE messages and warnings. BUFNO Set to 1; any other specification is ignored. RECFM Default is VBA it can be specified as be V[A] or F[B][A]. If specified without the 'A' (ASA carriage control), the 'A' will be added. LRECL Default is 137, or 141 if RECFM is V[B] BLKSIZE Default is: LRECL if RECFM is F LRECL+4 if RECFM is V the largest multiple LRECL less than or equal to 4100, if RECFM=FB 4100, if RECFM=VB

SIRPIPE transformations and directives

SIRPIPE transforms the input stream (DD SIRPIPE) according to the mode in effect at the beginning of each input record. The mode can be changed by a special record in the input stream, called a directive. In all modes, if PIPEOUT is RECFM F[B], trailing blanks are added to the input record if it is shorter than the PIPEOUT LRECL.

Text mode

The purpose of this mode is to compensate for the fixed length input processing of Model 204, as set by the Model 204 INCCC parameter, and to strip trailing blanks. In this mode, trailing blanks are stripped from each input record. The record is then copied unchanged to the output stream, unless the input record contains non-blank characters at or past position CC (if CC is greater than 0). Records with non-blank characters at or past this are split into pieces of length CC-1 followed by a non-blank character.

The CC parameter must be less than or equal to the PIPEOUT LRECL (minus 4 for variable length output).

See "Text (HTML) considerations" for considerations when using SIRPIPE for creating text objects.

Binary mode

The purpose of this mode is to compensate for a number of Model 204 input constraints:

1. Fixed-length input processing
2. Special meaning of certain input lines, such as *LOWER, *ANCEL, and END PROCEDURE
3. The loss of trailing blanks on some input lines
4. The handling of procedure line end characters
5. The possibility that errors in the beginning of the BATCH2 stream (for example, an incorrect file password) causes procedure input lines to be processed as Model 204 commands. This can result in large numbers of error messages at the audit trail, or possibly invoking commands unintentionally.

In addition, the record boundaries in the input stream are discarded; that is, all input records read in this mode are treated as a continuous stream of input bytes.

In this mode, the input stream is split into fixed-length pieces, and each piece is prefixed by "* " and suffixed by "*".

Note that procedures stored with BINARY in SIRPIPE may not be written correctly by the output of the DISPLAY PROCEDURE command (due to LINEND characters within the procedure). If you use DISPLAY to dump your procedures, BASE64 should be used with SIRPIPE.

Base64 mode

The purpose of this mode is to compensate for the Model 204 input constraints described for Binary mode, and also to transform the procedure to entirely readable characters. This may be worthwhile in some environments to prevent a DISPLAY PROCEDURE command (which is really of little value on, for example, an image file) from causing 3270 terminal output errors, or to allow dumping a procedure with a USE OUTPUT command followed by DISPLAY PROCEDURE.

In this mode, the input stream is transformed, six bits at a time, into mixed-case alphanumeric characters or slash (/) or plus (+) and split into fixed-length pieces; each piece is prefixed by "* " and suffixed by "*".

Inclusion directive: #< ddname

One of the following records (starting in column 1) may occur in the input stream while in text mode:

#< ddname TEXT [cc] *< ddname BINARY [type] *< ddname BASE64 [type]

If such a record occurs, the current input dataset is suspended, and the input dataset referenced by the DD statement with name ddname is used for the input stream. (The uppercase translation of ddname is used; that is, you can specify either uppercase or lowercase.) At the end of this input dataset, the suspended dataset is resumed in text mode.

TEXT	Indicates that the new dataset is processed in text mode.
BINARY	Indicates that the new dataset is processed in binary mode; input data bytes form a sequence with record boundaries ignored. The output is broken up into pieces.
BASE64	Indicates that the new dataset is processed in Base64 mode; input data bytes form a sequence with record boundaries ignored. Each 6 bits of the input is translated into an alphanumeric character or slash (/) or plus (+). The output is broken up into pieces. Note that the SIRPIPE Base64 mode does not add trailing equal sign (=) characters, which are sometimes used to pad the output to a multiple of 4 characters.

If the mode keyword is omitted, TEXT mode is used.

After the mode keyword the following options may be used:

type	In the BINARY and BASE64 inclusion directives, type can be any character string (ended by a blank) that will be placed into an output header line for "Content-type". The maximum length of type is 51 characters; if longer, it will be truncated. There is no default type; if missing, a header line for "Content-type" is not produced.
cc	In the TEXT inclusion directive, cc can be an integer from 0 to the output LRECL. If it is 0, input lines must not be longer than the output LRECL. If it is between 1 and the output LRECL, input lines are broken into pieces of length cc-1 with a non-blank character added. The default value of cc is 0.

Text (HTML) considerations

Using the Janus Web Server, a procedure can be sent as a BINARY, BASE64, or TEXT type object. The BINARY and BASE64 types use structuring within the procedure to recreate the data which was stored using SIRPIPE. BINARY and BASE64 types are also handled by SIRPIPE so that they can always be part of a BATCH2 procedure definition stream.

It is recommended that, whenever possible, you use BINARY or BASE64 types. Note that this is possible with HTML types, and in some cases it is necessary for HTML types. The only disadvantage is that you lose the Janus Web Server substitution facility for non-TEXT types.

The situations which are not valid for TEXT types being used for BATCH2 procedure definition streams are the following:

• Lines longer than 255 bytes; this is the limit for Model 204 procedures.
• Lines which begin with *DEVICE, *UPPER, *LOWER, or *CANCEL (in either uppercase or lowercase, for some of these).
• Lines which contain only the words END PROCEDURE, or which contain the words END PROCEDURE followed by the name of the procedure being defined.
• Lines which contain the LINEND character.

LINEND considerations

TEXT type objects are stored as normal Model 204 procedures and when retrieved the procedure is separated into lines using the LINEND value of the procedure. The LINEND value of the procedure is set to the value of the LINEND user parameter when the procedure is created with the PROCEDURE command. (The COPY PROC command copies the LINEND value of the input procedure to the output procedure.)

The default Model 204 value of LINEND is semicolon (C';' or X'5E'); this value is useful for typing a multi-line ad-hoc request (B;FR;PAI;END). However, there are many cases in using text types for Janus Web Server in which it is useful to have a semicolon as part of the text; for example, to insert a "less than" symbol in HTML, the characters '<' are used.

Therefore, when using SIRPIPE in TEXT mode it is recommended that the value of LINEND be set to a value which is unlikely to occur in the input. Sirius has found the value X'30' to be adequate; it happens to be the smallest value which is not an EBCDIC graphic nor a control character.

The value of LINEND will not affect Janus Web Server operations with objects sent as BINARY or BASE64.

If you have a procedure and want to change its LINEND value, you can use the fact that the GET command of the Model 204 editor changes the LINEND value of the procedure being edited to become the LINEND value of the procedure referenced on the GET command. Here is an example to illustrate this:

R LINEND X'5E' PROCEDURE FOO Begin Print 'Been there, done that' End END PROCEDURE FOO R LINEND X'30' PROCEDURE BAR END PROCEDURE BAR EDIT FOO GET BAR (move the cursor to the comma and change to semicolon) END INCLUDE FOO

SIRPIPE example for MVS

The following job steps invoke SIRPIPE and BATCH2 to load an image file to a Janus Web Server Model 204 Online region:

//SIRPIPE EXEC PGM=SIRPIPE //STEPLIB DD DISP=SHR,DSN=SIRIUS.V404.LOAD //SYSUDUMP DD SYSOUT=* //PIPRINT DD SYSOUT=* //PIPEOUT DD DISP=(,PASS),UNIT=SYSDA, // SPACE=(TRK,(10,10),RLSE),DSN=&&PIPEOUT //IMFILE DD DISP=SHR,DSN=WEB.IMAGES.GIF(SMILE) //PIPEIN DD * LOGON WEBADMIN ADMPASSWD OPEN DEVWEB DEVWEB *LOWER R SUB 0 R INCCC 72 R LINEND X'30' DELETE PROCEDURE JANWEB/IMAGES/SMILE.GIF PROCEDURE JANWEB/IMAGES/SMILE.GIF #< IMFILE BINARY IMAGE/GIF END PROCEDURE JANWEB/IMAGES/SMILE.GIF //BATCH2 EXEC PGM=BATCH2,PARM='M204PROD' //STEPLIB DD DISP=SHR,DSN=M204.V3R1.LOAD //SYSUDUMP DD SYSOUT=* //CCAOUT DD SYSOUT=* //CCAIN DD DISP=OLD,DSN=&&PIPEOUT

Note that the *LOWER command and the various R[ESET] commands are inserted here by hand, similar to the way they are inserted in the output file generated by the PIPEUP EXEC which is shown in "SIRPIPE example for CMS".

SIRPIPE example for CMS

PIPEUP EXEC

The following CMS exec can be used in conjunction with a PIPEUP NAMES file which resides either on the same minidisk as PIPEUP EXEC or on the A disk:

/* BHELP Load image file for Janus Web Usage: XEDIT PIPEUP NAMES EXEC PIPEUP filenm filetp [*|filemd] [BINARY|BASE64|TEXT] [[PROC] procname] EHELP */ address command arg fn ft fm rest if arg(1) = '?' then call usage 0 parse source . . execname . execmode . address command 'STATE' execname 'NAMES A' if rc ^= 0 then 'STATE' execname 'NAMES' execmode if rc ^=0 then call usage rc, execname 'NAMES not on A nor', execmode 'disk' 'NAMEFIND :nick' execname ':online :file', ':filpswd :prefix :login :logpswd', ':lgctlcms :linend :dsn', '(STEM info. FILE' execname if rc ^= 0 then call usage rc, 'Unable to get info from', execname 'NAMES' online = info.1 procfile = info.2 filpswd = info.3 prefix = info.4 login = info.5 logpswd = info.6 lgctlcms = info.7 linend = info.8 dsn = info.9 'SET CMSTYPE HT' 'STATE' fn ft fm /* Did user give filemode? */ r = rc 'SET CMSTYPE RT' if r ^= 0 then do /* Is input file there? */ address command 'STATE' fn ft '*' if rc ^= 0 then call usage rc, 'Input file not found:', fn ft '*' rest = fm rest fm = '*' end proc = encode = 'BINARY' do while rest ^= parse var rest r rest t = translate(r) if find('BINARY BASE64 TEXT', t) > 0 then encode = t else if t = 'PROC' then parse var rest proc rest else do if proc ^= then call usage 1, 'Invalid arg:' r proc = r end end if proc = then proc = prefix || fn'.'ft 'ERASE PIPE IN A' p = 'EXECIO 1 DISKW PIPE IN A (STR' if login = '=' then login = p 'LOGON' login if lgctlcms = 'NP' then do if login = then logpswd = else if login = userid() then logpswd = end p logpswd if dsn ^= then p 'ALLOCATE' procfile 'WITH SCOPE=SYSTEM', 'DSN='dsn 'DIRECT OLD' p 'OPEN' procfile p filpswd p '*LOWER' p 'R SUB 0' p 'R INCCC 72' if linend ^= then p 'R LINEND' linend p 'DELETE PROCEDURE' proc /* Help avoid errors from proc-ending lines */ p 'RESET ERMX 0' p 'PROCEDURE' proc cont = 'IMAGE/'ft if ft = 'JPG' then cont = 'IMAGE/JPEG' if encode = 'TEXT' then cont = '72' p '#< IMFILE' encode cont p 'END PROCEDURE' 'FINIS * * *' call fd 'IMFILE DISK' fn ft '*' 'EXECIO 1 DISKW M204IFAM EXEC A 1', '(FINIS ST /**/push' online call fd 'PIPEIN DISK PIPE IN A' call fd 'PIPEOUT DISK PIPE OUT A' call fd 'PIPRINT DISK PIPE PRINT A' 'GLOBAL TXTLIB M204CMI' if rc ^= 0 then call usage rc, 'Error performing GLOBAL TXTLIB' 'M204CMS SIRPIPE (CC 72' if rc ^= 0 then call usage rc, 'Error performing SIRPIPE.' call fd 'CCAIN DISK PIPE OUT A' call fd 'CCAOUT DISK BATCH2 LISTING A' 'M204BAT2 LINE 34' exit rc /*--------*/ fd: procedure expose det parse arg dd rest 'FILEDEF' dd 'CLEAR' 'FILEDEF' dd rest if rc = 0 then return call usage rc, 'Error performing FILEDEF' dd rest /*--------*/ usage: parse arg r, m if m ^= then say m i=1 do while left(sourceline(i),7)^='/*BHELP' i=i+1 end i=i+1 do until left(sourceline(i),5)='EHELP' say sourceline(i) i=i+1 end exit r /*--------*/

PIPEUP NAMES

The following file can be used to establish various parameters for PIPEUP EXEC. A system-wide copy can be kept on the same minidisk as PIPEUP EXEC, while a user-tailored version can be kept on the A disk. Using = as the value of the login tag indicates that the CMS user ID is known to Model 204, and the LOGCTL NP CMS command is in effect. The value of X'30' for the LINEND parameter is useful in loading a text file that contains semicolons; see "Text (HTML) considerations".

* Control PIPEUP EXEC :nick.PIPEUP :online.M204WEB :prefix.JANWEB/IMAGES/ :file.WEB :filpswd.WEB :dsn.M204WEB.WEBPROC :login.= :lgctlcms.NP :logpswd. :linend.X'30'

SIRPIPE messages

The following messages are issued by SIRPIPE. Except where noted, SIRPIPE processing is terminated after any of these errors.

PIPE0001 SIRPIPE version version	This displays the version of SIRPIPE that is running. With this version, version is 4.04. SIRPIPE processing continues after this message. It does not indicate any error condition.
PIPE0002 Unable to open DDname.	This indicates that SIRPIPE was unable to open the indicated DDname. This is probably due to a missing PIPEIN, PIPEOUT, or PIPRINT DD, or to a mismatch between the name specified on an inclusion directive ("<# statement") and the actual DD.
PIPE0003 Invalid RECFM for DDname.	This indicates that the RECFM specified on the indicated DDname is not acceptable to SIRPIPE. If you do not need to control the RECFM, just omit it and let SIRPIPE calculate a default. See "DD names/FILEDEF statements".
PIPE0004 Invalid LRECL for DDname.	This indicates that the LRECL specified on the indicated DDname is smaller than that acceptable to SIRPIPE. If you do not need to control the LRECL, just omit it and let SIRPIPE calculate a default. SIRPIPE requires certain mimimum LRECL values for both PIPRINT and PIPEOUT. See "DD names/FILEDEF statements".
PIPE0005 ddNAME has incompatible BLKSIZE (blksize) and LRECL (lrecl).	This indicates that the LRECL and BLKSIZE specified on the indicated DDname violate the MVS or CMS rules. If you do not need to control these parameters, just omit them and let SIRPIPE calculate a default. SIRPIPE issues this message only for PIPEOUT. See "DD names/FILEDEF statements".
PIPE0006 Getmain request failed, RC=code. SIRPIPE terminated	This indicates that there was not sufficient storage for some SIRPIPE operation. Increase the amount of storage allocated to the region with the REGION parameter on the EXEC card under MVS or with the DEFINE STORAGE command under CP.
PIPE0007 Cancelling run because of OUTPUT error in record recnum.	This indicates that an input record was too long (in TEXT mode) to be copied to the PIPEOUT dataset. If the input record is correct, either increase the PIPEOUT LRECL, or use a non-zero CC so that the input record can be split into continuation lines.
PIPE0008 Too many buffers for DDname.	This indicates that the product of BUFNO and BLKSIZE (increased by a small value) exceeds the largest 4-byte integer (about 2 billion). Change BUFNO to a more reasonable value (BLKSIZE is not the cause of this). This is checked for the PIPEOUT and PIPRINT outputs.
PIPE0009 End of SIRPIPE.	This indicates that SIRPIPE has completed processing. It does not indicate any error condition.
PIPE0011 Invalid DD name: string.	This indicates that the string that occurred on an inclusion directive ("<# statement") does not follow the MVS or CMS rules for DD names. Probably, the name is longer than 8 characters.
PIPE0012 Invalid mode keyword: string.	This indicates that the string that occurred on an inclusion directive ("<# statement") is not a valid mode keyword. The valid mode keywords are BINARY, BASE64, and TEST.
PIPE0013 Terminated because of 'SYSTEM | USER' abcode Abend; PSW psw MAIN address.	This indicates that a severe error condition was detected. Call Sirius Software and report the problem.
PIPE0014 Initial parameter settings:	This indicates that the initial parameter values will be shown next on PIPRINT. Each parameter will be shown on a single line, with the parameter name, an equal sign ("="), and the parameter value. Currently, the only SIRPIPE parameter is CC. SIRPIPE processing continues after this message. It does not indicate any error condition.
PIPE0015 Invalid parameter name: string.	This indicates that an invalid parameter name (string) was specified on the invocation of SIRPIPE (for example, the PARM= field on the MVS EXEC statement). Currently, the only SIRPIPE parameter is CC.
PIPE0016 Invalid expression setting parameter param.	This indicates an error in the specification of a value specified for parameter param. on the invocation of SIRPIPE (for example, the PARM= field on the MVS EXEC statement). Currently, the only SIRPIPE parameter is CC, and it must be specified in the form: CC=n where n is a positive integer.
PIPE0017 Continuation Column value beyond PIPEOUT LRECL	This indicates that the value of the CC parameter is too large for the LRECL of the PIPEOUT dataset. CC cannot exceed the LRECL if PIPEOUT is RECFM=F[B]; it cannot exceed LRECL+4 if PIPEOUT is RECFM=V[B].

SIRPIPE return codes

SIRPIPE will terminate with one of the following return codes:

0	SIRPIPE successfully completed.
4	SIRPIPE encountered a potentially non-fatal error.
8	SIRPIPE encountered a probably fatal error.
12	An invalid PARM card value was encountered.
16	Insufficient storage.
40	SIRPIPE could not open the PIPRINT DD.
48	Insufficient storage to even initialize SIRPIPE.
128	SIRPIPE abend.

Installing SIRPIPE in MVS

SIRPIPE is distributed on a magnetic tape which also contains the all the other Sirius products you purchased. Since SIRPIPE is only distributed with Janus Web Server, SIRPIPE will be on the tape that includes the Sirius Mods. Please refer to the Sirius Mods Installation Guide, which explains how to unload the tape.

After loading the tape, SIRPIPE is ready to use. The first tape file contains two sample jobs for SIRPIPE. One job called LINKPIPE is a sample link job. This job can be used to re-link the SIRPIPE load module should this become necessary. It should not be necessary since you unloaded from the tape a library with a fully linked SIRPIPE load module. There is also a sample SIRPIPE job called PIPEUP. This is only provided to be used as a skeleton for your own SIRPIPE jobs.

Installing SIRPIPE in CMS

SIRPIPE is distributed on a magnetic tape. This magnetic tape always contains all the Sirius products you have purchased. Since SIRPIPE is only distributed with Janus Web Server, that tape will include the Sirius Mods Please refer to the Sirius Mods Installation Guide, which explains how to unload the tape.

The SIRPIPE files that will be loaded are:

• SIRPIPE MODULE
• SIRPIPE MAP
• SIRPIPE TEXT

SIRPUT overview

SIRPUT is a utility which allows you to load text or binary files to any Web server (like Janus Web Server) that supports HTTP PUT.

SIRPUT is written in C, and has been compiled for IBM VM and MVS systems. SIRPUT uses IBM TCP/IP socket calls, and requires IBM TCP/IP on the host computer, under OS/390, MVS, or VM operating systems. The IBM C/370 runtime library is also required.

Sirius provides the source code for SIRPUT in case custom modifications are necessary for your site.

Installing SIRPUT

SIRPUT is distributed with your Janus Web Server. The installation tape contains the SIRPUT object, and a load module. For MVS installation tapes, the object file is in SIRIUS.LIB, and the load module in SIRIUS.LOAD. For VM systems, both the object and the module are on the same tape file.

SIRPUT EXEC or command processor syntax

SIRPUT filename [( [options] ]

Where:

filename

A CMS or MVS filename.

options

One or more of the following: -h hostname The TCP/IP host name. Defaults to the current host. -p portnumber The TCP/IP port number. Defaults to 80. -r remotefile Character string with path and file name of the file to be stored on the web server (for example, /AUTOS/AMC/PACER.HTML). -v Print the Web server response at the terminal. -b Store the file without translation or record delimiters. -t Store the file as text with CR/LF delimited records.

Running SIRPUT under CMS

Use the SIRPUT EXEC under CMS to set up the environment for the SIRPUT module. For most installations, modifications will be unnecessary, but you may need to change the name of the C run-time library if you are not using the standard IBM name, IBMLIB.

Running SIRPUT under MVS

The SIRPUT load module resides in SIRIUS.LOAD. A REXX command procedure with the same name is in SIRIUS.LIB. This command procedure invokes SIRPUT from SIRIUS.LOAD. If you use a different load library at your site, you must update the SIRPUT REXX command procedure with this name.

SIRPUT requires access to the C runtime environment whether running in batch or in a TSO session.

Running SIRPUT in batch

The following job control can be used to invoke SIRPUT in batch. The jobstep return code is set to zero if successful, or the HTTP return code if it fails. This job control includes a steplib concatenation for SCEE.SCEERUN, which contains the C runtime modules, but this library is commonly in the OS/390 link list, therefore the statement is usually unnecessary.

//SIRPUT JOB (0),CLASS=A,MSGCLASS=A //SIRPUT EXEC PGM=SIRPUT,REGION=0M, // PARM='POKEMON.DITTO -t -r /ASH/DITTO.TXT' //STEPLIB DD DSN=SIRPUT.V100.LOAD,DISP=SHR // DD DSN=CEE.SCEERUN,DISP=SHR //SYSPRINT DD SYSOUT=* //

SIRPUT return codes

SIRPUT will terminate normally with a return code of 0, which means that SIRPUT created the object on the server. This is the equivalent of HTTP return code 201. All other return codes from 200-599 match the HTTP 1.0 specifications.

4	Required argument is missing
8	Error connecting to Web server
12	Invalid file name or file not found
200	OK
0 (201)	Created
202	Accepted
204	No Content
301	Moved Permanently
302	Moved Temporarily
304	Not Modified
400	Bad Request
401	Not Authorized (logon required)
403	Forbidden
404	Not Found
500	Internal Server Error
501	Not Implemented
502	Bad Gateway
503	Service Unavailable

JANWEB rules for SIRPUT

Before you can use SIRPUT with Janus Web Server, you must specify rules which define how PUT requests will be handled. You should restrict usage by IP address or by IP group, since SIRPUT cannot be used on an SSL port, and it does not accept authorization challenges.

The following example shows how one might tailor Janus Web Server rules for use with SIRPUT:

* * Any PUT requests will be loaded into file UPLOADS as * Model 204 procedures * JANUS WEB MYSERVER ON PUT /*.* OPEN FILE UPLOADS RECV *.* * * Only allow users at the following addresses to use SIRPUT * JANUS WEB DEFINEIPGROUP PUTTERS - 198.242.244.0-3 198.242.244.221 JANUS WEB MYSERVER ALLOW PUT *.* IPGROUP PUTTERS *

SIRPUT restrictions

SIRPUT does not support the redirecting of requests: it will not forward a PUT request to another server, regardless of its location. A REDIRECT request will result in an error and a SIRPUT return code of 301 or 302.

You cannot use an SSL port with SIRPUT. The WEBSERV port may have any valid port number, but may not use SSL. Using an SSL port with SIRPUT will probably result in a return code 8 from SIRPUT.

SIRPUT will not accept authorization challenges. This means that you cannot create (PUT) a URL that requires a login userid and password. Since SIRPUT does not support SSL, any userid and password would traverse the network unencrypted, usually not a desirable situation. Specify IPADDR or IPGROUP on your JANUS WEB ALLOW rules to restrict use of SIRPUT.