Downloading and installing Rocket M204 products

How can the above object files be downloaded?

The object files can be downloaded by clicking on the link for the object file with the right mouse button. This will (on most browsers) bring up a pop-up menu that will have an option Save Link As, Save target As, Save As, or something similar. Select this option, and then set the appropriate target directory (and name if desired) for the file. The object file will then be downloaded to the indicated location.

Alternatively, click the left mouse button on the link for an object file. This will result in the browser prompting the user whether the file should be saved, where it should be saved, and under what name. Some browsers prompt for this information before the object file is actually downloaded; others prompt for it after. Obviously, those that prompt after will present a considerable delay before the prompt. Opera actually prompts as soon as it receives the file header but continues downloading while waiting for the user response.

Object files are customized for a particular site, simplifying the installation process. Because of this, there may be a noticeable delay in processing a download request. In addition, the downloaded object files can range in size from hundreds of kilobytes to perhaps 10 megabytes.

If an e-mail transfer is selected, the object deck will be e-mailed to the indicated e-mail address as an attachment. The attachment should be saved to a local file and then uploaded to the mainframe exactly as if it had been downloaded directly. Receiving the object deck via e-mail might take a little longer than downloading it directly, but it allows you to schedule a set of object to be sent to a different person in your organization.

How can the object files be uploaded to the mainframe?

Once the object files are downloaded to the workstation they must be uploaded to the z/OS, VM, or VSE system on the IBM mainframe. Any file transfer mechanism can be used including FTP and IND$FILE, but regardless of the transfer mechanism some rules must be observed.

First, the object files contain binary data and hence must be transferred as binary. That is, no translation from ASCII to EBCDIC must occur as a result of the upload.

Second, the format and LRECL of the file must be specified during the upload. This is because most workstation systems (including Windows, Mac OS and Unix) do not have a concept of file formats and LRECL's. This information would be lost if it were not specified during the upload. The format of the uploaded file must be F under VM systems and FB under z/OS and VSE systems. The LRECL must be 80 on all systems and under z/OS and VSE the blocksize can be any multiple of 80 though 3120 is a common blocksize for object libraries.

When using FTP, the characteristics (RECFM, LRECL, and BLOCKSIZE) of the uploaded file can be set with the SITE and LOCSITE FTP commands. The SITE command should be used if the FTP client is on the workstation and the server is on the mainframe. In this case the SITE command might have to be sent as a "quote" to the mainframe. How this is done depends on your workstation's FTP client. The LOCSITE command should be used if the FTP client is on the mainframe and the server is on the workstation.

Model 204 object library

The Model 204 installation process entails creating a library (in z/OS, a Partitioned Data Set, or PDS), which is then used in subsequent steps to link the various Model 204 load modules. The file which you have uploaded to the mainframe, typically as a sequential dataset (DSORG=PS in z/OS), is used as the INP= parameter to the following JCL PROC for a z/OS installation:

//NEWOBJLB PROC TRK='320,50',BLK=6400
//*
//* Usage: //BLD EXEC NEWOBJLB,LIB=objectLibDsn,INP=inputStreamDsn
//*
//* Important note: The output object library (LIB=) is first deleted
//*
//* This proc creates an object library, using the input stream which
//* was downloaded from the Rocket Model 204 web site.  After the
//* download, it must be un-zipped, and then FTP'd (BINARY, 80 byte
//* fixed length records) to a z/OS dataset.
//*
//* The FTP'd z/OS dataset is specified by the INP= parameter
//*
//* Note: If you thought you might want to, it's best not to try
//*       to over-ride SYSIN with a DD *, because the input stream
//*       contains JCL.
//*
//DEL      EXEC PGM=IEFBR14
//DEL      DD DSN=&LIB,DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,1)
//*
//BLDOBJLB EXEC PGM=IEBUPDTE,PARM=NEW
//SYSPRINT DD SYSOUT=A   << Note: this output will contain on the order
//*                         of 160K lines or more
//SYSUT2   DD DISP=(NEW,CATLG),SPACE=(TRK,(&TRK,60),RLSE),
//            UNIT=SYSDA,DCB=(DSORG=PO,LRECL=80,RECFM=FB,BLKSIZE=&BLK),
//            DSN=&LIB
//SYSIN    DD DISP=SHR,DSN=&INP
//*
//         PEND

For example, if you downloaded the input stream and then FTP'd it into M204.V75.DOWNLOAD.OBJ, and the object library dataset is to be M204.V75.OBJLIB:

//BLDOBJLB EXEC NEWOBJLB,
//            INP=M204.V75.DOWNLOAD,
//            LIB=M204.V75.OBJLIB

The space allocation and block size are PROC parameters, but their defaults will work. You can, of course, use any dataset name you want for the object library after INP= — note that in our documentation, we refer to the object library as ROKOB204.

Other object files

For products other than Model 204, the downloaded file is a single object file. Under z/OS, you can upload an object file either as a member of a Partitioned Data Set (PDS) or as an individual sequential file. A PDS is recommended as a good way to collect all your Rocket M204 object file uploads in one dataset, using the member name to show the product and version.

Should maintenance be applied to the uploaded object files?

When Rocket M204 products are downloaded, they will contain all of the current maintenance as well as all applicable authorization keys. Thus no additional additional installation steps steps are required to install maintenance or authorization keys. Subsequent fixes can be applied by downloading ZAPs and applying them, or by downloading a replacement object file and re-linking the appropriate load modules.

How should the Model 204 load modules be linked under z/OS?

The Model 204 object library you created contains object files, JCL, and link-edit control statements so that you can link the Model 204 load modules. (This library, of course, has the DSNAME you chose — but in our documentation, we refer to the object library as ROKOB204).

One of the members of ROKOB204 is a text file named README, which includes a list of the Model 204 load modules, and, individual instructions for linking them.

For example, to link the ONLINE load module, there is a member named JZLONLN. This basic JCL has simple instructions for using it. One of the comments in the JCL is a link which you may follow for more detailed instructions.

What are the Sirius Mods?

The Sirius Mods is a collection of functions and enhancements to the core Model 204 load module. These enhancements are either products in and of themselves, or they are prerequisites for products which are written in User Language. A site is authorized to download all of the Sirus Mods if it is licensed for any of the products that require these enhancements. Your authorization key will then enable the appropriate set of products.

Products that require the Sirius Mods are:

• Fast/Backup
• Fast/Reload
• Fast/Unload User Language Interface
• Janus Network Security
• Janus Open Server
• Janus Open Client
• Janus SOAP
• Janus Specialty Data Store
• Janus TCP/IP Base
• Janus Web Server
• Japanese Functions
• SirDBA
• SirFact
• SirFile
• Sirius Performance Enhancements
• Sirius Performance Enhancements V2
• SirLib
• SirMon
• SirPro
• SirSafe
• SirScan
• SirTune
• SirXref
• Sir2000 Field Migration Facility
• Sir2000 User Language Tools
• Trusted Login Facility

You can determine which of these products your site is authorized for by examining <a href="https://m204.rocketsoftware.com/dlist">your customer profile</a>. After the Sirius Mods are installed, you can verify product authorizations by issuing the SIRIUS command in an Online running a load module that includes the Sirius&npsp;Mods.

How should the Sirius Mods object file be linked under z/OS?

The Sirius Mods object file should be linked ahead of the Model 204 object modules from Rocket. Under z/OS, an object deck can be re-linked with a load module. In theory, this load module can already contain the Sirius Mods. While this is generally OK if linking over the same release of the Sirius Mods, it is almost certainly a bad idea otherwise. As such, it is a good idea to keep a load module without the Sirius Mods available for rebuilding a load module with the Sirius Mods. The non-Sirius Mods load module should have all Rocket ZAPs applied, or these ZAPs should be applied after the re-link with the Sirius Mods object file.

Should Rocket provide replacement object files as part of their maintenance, these object files must never be linked ahead of the Sirius Mods object file. This also means that replacement Rocket object files cannot simply be linked ahead of a load module containing the Sirius Mods without also linking the Sirius Mods object file ahead of the replacement object files from Rocket.

Both of the next two examples assume you uploaded the object file into library SIRIUS.LIB with a member name of SIR80074. If you uploaded to a non-library dataset (that is, a sequential dataset, not a Partitioned Data Set), then you should omit the parentheses and member name after INCLUDE LIB.

The following JCL is an example of how you would link the Sirius Mods object file with a standard Model 204 load module called ONLINE in library M204.V7R4.LOADLIB. The module is linked into library SIRIUS.LOAD.

<xmp> //JOB whatever //LINK EXEC PGM=IEWL,REGION=0M, // PARM='LIST,LET,MAP,SIZE=(2048K,512K),RMODE=ANY,AC=1' //SYSPRINT DD SYSOUT=* //M204LOAD DD DSN=M204.V7R4.LOADLIB,DISP=SHR //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(2,1)) //LIB DD DSN=SIRIUS.LIB,DISP=SHR //SYSLMOD DD DSN=SIRIUS.LOAD,DISP=SHR //SYSLIN DD *

INCLUDE LIB(SIR80074)
INCLUDE M204LOAD(ONLINE)
ENTRY MAINTASK
NAME ONLINE(R)

/* </xmp>

The following JCL is an example of how you would link the Sirius Mods object file with a standard Model 204 load module called ONLINE in library M204.V7R4.LOADLIB, along with replacement object decks for EVNU and SBFM, which were provided with Rocket maintenance and are in library M204.V7R4.FIXOBJ. The module is linked into library SIRIUS.LOAD.

<xmp> //JOB whatever //LINK EXEC PGM=IEWL,REGION=0M, // PARM='LIST,LET,MAP,SIZE=(2048K,512K),RMODE=ANY,AC=1' //SYSPRINT DD SYSOUT=* //M204LOAD DD DSN=M204.V7R4.LOADLIB,DISP=SHR //M204FIX DD DSN=M204.V7R4.FIXOBJ,DISP=SHR //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(2,1)) //LIB DD DSN=SIRIUS.LIB,DISP=SHR //SYSLMOD DD DSN=SIRIUS.LOAD,DISP=SHR //SYSLIN DD *

INCLUDE LIB(SIR80074)
INCLUDE M204FIX(EVFM,SBFM)
INCLUDE M204LOAD(ONLINE)
ENTRY MAINTASK
NAME ONLINE(R)

/* </xmp>

How should the Sirius Mods object file be linked under CMS?

The Sirius Mods object file should be linked ahead of the Model 204 object modules from Rocket. This means, first, that the object file's filetype must conform to CMS conventions for object files. The simplest way to ensure this is to use a filetype of TEXT for the object file under CMS.

To link with the Rocket-supplied M204GEN utility, the Model 204 load list must be modified to include the Sirius Mods object file. This can be done by simply inserting a line with an "&1 &2" followed by the filename of the Sirius Mods object file before the name of any other object file in the load list. The following is an example of the first few lines of an updated load list, where the Sirius Mods object file is called "SIR80074 TEXT".

<xmp>

• LOAD LIST FOR M204ONLN MODULE
• (&START IN MLNK)

&1 &2 SIR80074
&1 &2 MLNK
&1 &2 ACF2CMS
&1 &2 ANXV
&1 &2 APSY
&1 &2 APSZ
&1 &2 ARTH
. . . . .

</xmp>

Because the Sirius Mods dynamically adds hooks to the load module, Sirius recommends against using shared segments with the Sirius Mods. If this is considered essential, contact Sirius Software technical support for help in building a load module with the Sirius Mods and shared segments.

An exec called LOADCONV is also available to automatically convert the loadlist, it can be <a href="download/loadconv.rex">downloaded here</a>. Note that LOADCONV requires that the filename of the Sirius Mods object file be "SIROBJ" followed by the Model 204 release to which it applies, as in "SIROBJ74".

If the M204GEN exec is being used, M204CCA PARMS needs to be edited. First, in the M204GEN/DEFAULTS section, the ldrtbls value might need to be increased:

<xmp> M204GEN: DEFAULTS:

 ldrtbls = 50

</xmp>

Also, the load module start needs to include the Sirius Mods so in the ONLINE/ONLN section the line

<xmp>

  start.mod   = MLNK$

</xmp>

needs to be changed to

<xmp>

  start.mod   = SLNK$

</xmp>

If you want to be able to generate a load module both with and without the Sirius Mods, you could copy the whole ONLINE section in M204CCA PARMS and call it something else, for example, SIRIUS, and change start.mod in that section. Then, when you want to generate a load module with the Sirius Mods in it you'd simply type

<xmp> M204GEN SIRIUS </xmp>

How should the Sirius Mods object file be linked under VSE?

The Sirius Mods object file should be linked ahead of the Model 204 object files from Rocket. The example below shows an excerpt of the standard Rocket link JCL for an ONLINE. To linkedit the online with the Sirius Mods, you must insert the include statement for the object module immediately after the PHASE statement. In this example, the Sirius Mods object is named SIR80074. If the Sirius Mods object module is in a separate library, the JCL should be modified to include that library in the SEARCH= paramter of the LIBDEF OBJ statement. If you include any other object modules, they also must appear after the Sirius Mods object.

<xmp> ...

// LIBDEF PHASE,CATALOG=M204LIB.V7R4
// LIBDEF OBJ,SEARCH=M204LIB.V7R4
// OPTION CATAL
 PHASE ONLINE,* REPLACE=YES
 INCLUDE SIR80074
 INCLUDE LKONLN
 INCLUDE
 ENTRY MAINTASK
/*
// EXEC LNKEDT
/*
/&

... </xmp>

How should the Fast/Unload object file be linked?

The following z/OS JCL is an example of how one would link the Fast/Unload object file. The module is linked into library SIRIUS.LOAD. This example assumes you <a href='#objup'>uploaded</a> the object file into library SIRIUS.LIB with a member name of FUN400. If you uploaded to a non-library dataset (that is, a sequential dataset, not a Partitioned Data Set), then you should omit the parentheses and member name after INCLUDE LIB.

<xmp> //JOB whatever //LINK EXEC PGM=IEWL,REGION=0M, // PARM='RENT,LIST,MAP,NCAL,SIZE=(2048K,512K),AMODE=31,RMODE=24,AC=1' //SYSPRINT DD SYSOUT=* //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(2,1)) //LIB DD DSN=SIRIUS.LIB,DISP=SHR //SYSLMOD DD DSN=SIRIUS.LOAD,DISP=SHR //SYSLIN DD *

INCLUDE LIB(FUN400)
ENTRY FUNLOAD
NAME FUNLOAD(R)

/* </xmp>

Under CMS, the Fast/Unload object file should be given a filetype of "TEXT". The following commands can then be issued either directly or in an EXEC to build a FUNLOAD load module. In this example, it is assumed that the Fast/Unload object file has a filename of FUN400.

<xmp> LOAD FUN400 (FULLMAP NODUP ORIGIN 30000 AMODE 31 RESET FUNLOAD RLDSAVE GENMOD FUNLOAD (FROM FUNL </xmp>

Why were there three object files for SirTune?

Beginning with Version 7.0 of the Sirius Mods, all SirTune functionality has been merged into the Sirius Mods and so the standalone SirTune load modules are obsolete.

Prior to Version 7.0 of the Sirius Mods, however, SirTune consisted of three components. The first component was called the SirTune Data Collector or simply SirTune. This load module runs in the same address space as the <nobr>Model 204</nobr> load module and collects data to be analyzed later.

The second component is called the SirTune Report Generator. This load module is run independently of <nobr>Model 204</nobr> and summarizes the data collected by SirTune into a report.

The third component is used only under CMS and is called the SirTune Data Logger. It communicates with SirTune via IUCV and asynchronously logs SirTune data on a separate virtual machine. It is used to get around some of the difficulties of doing asynchronous I/O under CMS.

In general, it is a good idea to be using the same versions of all three SirTune components though Sirius makes every effort to allow a newer SirTune Report Generator to produce reports from sample datasets created by older releases of SirTune.

How should the SirTune object file be linked?

The following z/OS JCL is an example of how one would link the SirTune object file. The module is linked into library SIRIUS.LOAD. This example assumes you <a href='#objup'>uploaded</a> the object file into library SIRIUS.LIB with a member name of TUNE104. If you uploaded to a non-library dataset (that is, a sequential dataset, not a Partitioned Data Set), then you should omit the parentheses and member name after INCLUDE LIB.

<xmp> //JOB whatever //LINK EXEC PGM=IEWL,REGION=0M, // PARM='RENT,LIST,MAP,NCAL,SIZE=(2048K,512K),AMODE=31,RMODE=24,AC=1' //SYSPRINT DD SYSOUT=* //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(2,1)) //LIB DD DSN=SIRIUS.LIB,DISP=SHR //SYSLMOD DD DSN=SIRIUS.LOAD,DISP=SHR //SYSLIN DD *

INCLUDE LIB(TUNE104)
ENTRY COLLECT
NAME SIRTUNE(R)

/* </xmp>

Under CMS, the SirTune object file should be given a filetype of "TEXT". The following commands can then be issued either directly or in an EXEC to build a SIRTUNE load module. In this example, it is assumed that the SirTune object file has a filename of TUNE104.

<xmp> LOAD TUNE104 (FULLMAP NODUP ORIGIN 400000 AMODE 31 RESET COLLECT GENMOD SIRTUNE (FROM COLL </xmp>

How should the SirTune Report Generator object file be linked?

The following z/OS JCL is an example of how one would link the SirTune Report Generator object file. The module is linked into library SIRIUS.LOAD. This example assumes you <a href='#objup'>uploaded</a> the object file into library SIRIUS.LIB with a member name of TUNR104. If you uploaded to a non-library dataset (that is, a sequential dataset, not a Partitioned Data Set), then you should omit the parentheses and member name after INCLUDE LIB.

<xmp> //JOB whatever //LINK EXEC PGM=IEWL,REGION=0M, // PARM='RENT,LIST,MAP,NCAL,SIZE=(2048K,512K),AMODE=31,RMODE=24,AC=1' //SYSPRINT DD SYSOUT=* //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(2,1)) //LIB DD DSN=SIRIUS.LIB,DISP=SHR //SYSLMOD DD DSN=SIRIUS.LOAD,DISP=SHR //SYSLIN DD *

INCLUDE LIB(TUNR104)
ENTRY ANALYZE
NAME SIRTUNER(R)

/* </xmp>

Under CMS, the SirTune Report Renerator object file should be given a filetype of "TEXT". The following commands can then be issued either directly or in an EXEC to build a SIRTUNER load module. In this example, it is assumed that the SirTune Report Generator object file has a filename of TUNR103.

<xmp> LOAD TUNR103 (FULLMAP NODUP ORIGIN 30000 AMODE 31 RESET ANALYZE GENMOD SIRTUNER (FROM ANAL </xmp>

How should the SirTune Data Logger object file be linked?

The SirTune data Logger is not used under z/OS.

Under CMS, the SirTune Data Logger object file should be given a filetype of "TEXT". The following commands can then be issued either directly or in an EXEC to build a SIRTUNED load module. In this example, it is assumed that the SirTune Data Logger object file has a filename of TUND104.

<xmp> LOAD TUND104 (FULLMAP NODUP ORIGIN 30000 AMODE 24 RESET OUTCMS GENMOD SIRTUNED (FROM OUTC </xmp>

How should the RockZap object file be linked?

The following z/OS JCL is an example of how one would link the RockZap object file. The module is linked into library SIRIUS.LOAD. This example assumes you <a href='#objup'>uploaded</a> the object file into library SIRIUS.LIB with a member name of ZAP106. If you uploaded to a non-library dataset (that is, a sequential dataset, not a Partitioned Data Set), then you should omit the parentheses and member name after INCLUDE LIB.

<xmp> //JOB whatever //LINK EXEC PGM=IEWL,REGION=0M, // PARM='RENT,LIST,MAP,NCAL,SIZE=(2048K,512K),AMODE=31,RMODE=24,AC=0' //SYSPRINT DD SYSOUT=* //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(2,1)) //LIB DD DSN=SIRIUS.LIB,DISP=SHR //SYSLMOD DD DSN=SIRIUS.LOAD,DISP=SHR //SYSLIN DD *

INCLUDE LIB(ZAP106)
ENTRY SIRZAP
NAME SIRZAP(R)

/* </xmp>

Under CMS, the SirZap object file should be given a filetype of "TEXT". The following commands can then be issued either directly or in an EXEC to build a SIRZAP load module. In this example, it is assumed that the SirZap object file has a filename of ZAP106.

<xmp> LOAD ZAP106 (FULLMAP NODUP ORIGIN 20000 AMODE 31 RESET SIRZAP GENMOD SIRZAP (FROM APPL </xmp>

How should the SirAud object file be linked?

The following z/OS JCL is an example of how one would link the SirAud object file. The module is linked into library SIRIUS.LOAD. This example assumes you <a href='#objup'>uploaded</a> the object file into library SIRIUS.LIB with a member name of AUD102. If you uploaded to a non-library dataset (that is, a sequential dataset, not a Partitioned Data Set), then you should omit the parentheses and member name after INCLUDE LIB.

<xmp> //JOB whatever //LINK EXEC PGM=IEWL,REGION=0M, // PARM='RENT,LIST,MAP,NCAL,SIZE=(2048K,512K),AMODE=31,RMODE=24,AC=0' //SYSPRINT DD SYSOUT=* //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(2,1)) //LIB DD DSN=SIRIUS.LIB,DISP=SHR //SYSLMOD DD DSN=SIRIUS.LOAD,DISP=SHR //SYSLIN DD *

INCLUDE LIB(AUD102)
ENTRY JMAIN
NAME SIRAUD(R)

/* </xmp>

Under CMS, the SirAud object file should be given a filetype of "TEXT". The following commands can then be issued either directly or in an EXEC to build a SIRAUD load module. In this example, it is assumed that the SirAud object file has a filename of AUD102.

<xmp> LOAD AUD102 (FULLMAP NODUP ORIGIN 30000 AMODE 31 RESET JMAIN GENMOD SIRAUD (FROM JCONF </xmp>

How should the Fast/Cram object files be installed?

Most of the documentation for Fast/Cram installation can be found in the <a href="https://m204.rocketsoftware.com/maint/download/CRAMR.PDF"> Fast/Cram Installation Guide</a>. That manual is currently not updated to reflect web downloads, so a few things must be kept in mind. The first is that the first four characters of the download file indicate the module being downloaded, and they correspond to a specific member in SIRIUS.LOAD, as described in the Fast/Cram Installation Guide. The correspondences between the first four characters in the downloaded object files and the members in SIRIUS.LOAD are:

FCRM	FASTSVC
FCRI	IGCLM244
FCRR	FASTREP
FCRS	SNAPFAST

The following example JCL would create SIRIUS.LOAD load modules as described in the Fast/Cram Installation Guide. This example assumes you uploaded the object files into library SIRIUS.LIB with member names of FCR*27. If you uploaded to non-library datasets (that is, sequential datasets, not Partitioned Data Sets), then you will need a separate DD statement for each object file as well as appropriate INCLUDE statements for them, omitting the parentheses and member names.

Note: The Fast/CRAM modules must be linked using the RENT option.

<xmp> //JOB whatever //LINK EXEC PGM=IEWL,REGION=0M, // PARM='RENT,LIST,MAP,NCAL,SIZE=(2048K,512K),AMODE=31,RMODE=24,AC=1' //SYSPRINT DD SYSOUT=* //SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(2,1)) //LIB DD DSN=SIRIUS.LIB,DISP=SHR //SYSLMOD DD DSN=SIRIUS.LOAD,DISP=SHR //SYSLIN DD *

INCLUDE LIB(FCRM27)
ENTRY FASTSVC
NAME FASTSVC(R)
INCLUDE LIB(FCRI27)
ENTRY FASTRLD
NAME IGCLM244(R)
INCLUDE LIB(FCRR27)
ENTRY FASTREP
NAME FASTREP(R)
INCLUDE LIB(FCRS27)
ENTRY SNAPFAST
NAME SNAPFAST(R)

/* </xmp>

Unfortunately, the customization job is currently Fast/Cram release specific. The following job is a sample customization job for Fast/Cram V2.7:

<xmp> //FASTCUST JOB ,'Fast/CRAM',CLASS=A,MSGCLASS=A //* //* Customize FASTCRAM Version 2.7 //* //* Install FASTCRAM in SYS1.LPALIB, //* as a Type 3 or type 4 SVC, using an SVC //* number of 250 and a subsystem name of SIRI. //* //ZAPS EXEC PGM=SIRZAP,PARM=NOVER //SYSPRINT DD SYSOUT=* //SYSLIB DD DISP=SHR,DSN=SIRIUS.LOAD //SYSIN DD *

• *********************************************************************
• ZAP THE SVC NUMBER INTO FASTRLD. *
• *********************************************************************

NAME FASTRLD  FASTRLD
VER  0184 0A0D
REP  0184 0AFA      * NEW SVC=250

• *********************************************************************
• ZAP THE SUBSYSTEM NAME AND SVC NUMBER INTO FASTSVC. *
• *********************************************************************

NAME FASTSVC  FASTSVC
VER  1678 00007FFF
VER  167C C6C1E2E3  * CURRENT SUBSYSTEM=FAST
REP  167C E2C9D9C9  * NEW SUBSYSTEM=SIRI
VER  1688 0A0D
REP  1688 0AFA      * NEW SVC=250

/* </xmp>

No matter which subsystem name you choose, this subsystem name must be defined in IEFSSNxx in SYS1.PARMLIB. It is strongly recommended that subsystem name "M204" not be used because that subsystem name is used for <nobr>Model 204's</nobr> standard CRAM implementations. The subsystem can also be defined dynamically with the SETSSI command:

<xmp> SETSSI ADD,SUBNAME=FAST </xmp>

If you are downloading a release for which no sample customization job is listed here, or if you need more help with the installation, contact Rocket M204 support at +1.800.755.4222, or e-mail us at <a href="mailto:m204support@rocketsoftware.com">m204support@rocketsoftware.com</a>.

Where can more documentation be found?

The primary source of documentation for Rocket M204 products is this wiki.