Downloading and installing Rocket M204 products

This page provides Help for downloading from the "Object files" page that is accessed from the Rocket website Rocket M204 Customer Care page.

How can the object files be downloaded?

An object files can be downloaded by clicking on the "Download object file" link in the right-most column for the object file you want. 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 ten megabytes.

If you select an e-mail transfer, the object deck is e-mailed to the indicated e-mail address as an attachment. The attachment should be saved to a local file, then uploaded to the mainframe exactly as if it had been downloaded directly. Receiving the object deck via email might take a little longer than downloading it directly, but it allows you to schedule a set of objects 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:

• 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.
• 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 LRECLs. 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.

The next two subsections describe the mainframe data sets that should be used to contain the uploaded object file, for either Model 204 installation or other object files.

Model 204 object library

The Model 204 installation process entails creating an object library (in z/OS, a library is a Partitioned Data Set, or PDS) and a macro library, which are then used in subsequent steps for Model 204 installation. After getting the download for both the object and macro libraries, FTP (Binary F 80) them to the mainframe, then use the JCL that creates these libraries.

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 data set, 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 installation 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 Model 204 documentation, the object library is referred to as RKOBJLIB).

One of the members of RKOBJLIB is a text file named _README that includes a list of the Model 204 load modules and individual instructions for linking them.

For example, the jobstream to link the ONLINE load module is in a member named LKONLNJ. To link ONLINE, copy this member to your TSO library, edit it, and submit it. The jobstream has simple instructions indicating what changes to make. These instructions are complete, but more detail can be found by following the link in one of the comments in the JCL.

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 that are written in SOUL. 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 your customer profile. 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 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 alright 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.

//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) /*

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.

//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) /*

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 &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.

* 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 ...

Because the Sirius Mods dynamically adds hooks to the load module, using shared segments with the Sirius Mods is not recommended. If this is considered essential, contact Rocket 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 downloaded here. 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:

M204GEN: DEFAULTS: ldrtbls = 50

Also, the load module start needs to include the Sirius Mods. So change this line in the ONLINE/ONLN section:

start.mod = MLNK$

To:

start.mod = SLNK$

To be able to generate a load module both with and without the Sirius Mods:

1. Copy the whole ONLINE section in M204CCA PARMS and call it something else, for example, SIRIUS; then change start.mod in that section.
2. When you want to generate a load module with the Sirius Mods in it, specify:

   M204GEN SIRIUS

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= parameter of the LIBDEF OBJ statement.

If you include any other object modules, they also must appear after the Sirius Mods object.

... // 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 /* /& ...

How should the Fast/Unload object file be linked?

Under z/OS

The following z/OS JCL is an example of how one would link the Fast/Unload object file for versions of Model 204 and Fast/Unload prior to 7.7.

For version 7.7 and higher of Model 204 and Fast/Unload, no link job is necessary: Fast/Unload is integrated with the Model 204 Online load module (specified in the Online link job as an alias, like ALIAS FUNLOAD(FUNLPGM)).

The pre-7.7 module below is linked into library SIRIUS.LOAD. This example assumes you uploaded the object file into library SIRIUS.LIB with a member name of FUN400. If you uploaded to a non-library data set (that is, a sequential data set, not a Partitioned Data Set), then you should omit the parentheses and member name after INCLUDE LIB.

//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) /*

Note: If you see the following error message when linking Fast/Unload, you can safely ignore it. This message is erroneous:

IEW2651W 511C ESD AMODE 24 CONFLICTS WITH USER-SPECIFIED AMODE 31 FOR ENTRY POINT FUN400

Under CMS

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.

LOAD FUN400 (FULLMAP NODUP ORIGIN 30000 AMODE 31 RESET FUNLOAD RLDSAVE GENMOD FUNLOAD (FROM FUNL

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, 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 is called the SirTune Data Collector or simply SirTune. This load module runs in the same address space as the Model 204 load module, and it collects data to be analyzed later.
• The second component is called the SirTune Report Generator. This load module is run independently of Model 204, and it 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 it 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 Rocket makes every effort to allow a newer SirTune Report Generator to produce reports from sample data sets 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 uploaded the object file into library SIRIUS.LIB with a member name of TUNE104. If you uploaded to a non-library data set (that is, a sequential data set, not a Partitioned Data Set), then you should omit the parentheses and member name after INCLUDE LIB.

//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) /*

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.

LOAD TUNE104 (FULLMAP NODUP ORIGIN 400000 AMODE 31 RESET COLLECT GENMOD SIRTUNE (FROM COLL

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 uploaded the object file into library SIRIUS.LIB with a member name of TUNR104. If you uploaded to a non-library data set (that is, a sequential data set, not a Partitioned Data Set), then you should omit the parentheses and member name after INCLUDE LIB.

//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) /*

Under CMS, the SirTune Report Generator 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.

LOAD TUNR103 (FULLMAP NODUP ORIGIN 30000 AMODE 31 RESET ANALYZE GENMOD SIRTUNER (FROM ANAL

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.

LOAD TUND104 (FULLMAP NODUP ORIGIN 30000 AMODE 24 RESET OUTCMS GENMOD SIRTUNED (FROM OUTC

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 uploaded the object file into library SIRIUS.LIB with a member name of ZAP106. If you uploaded to a non-library data set (that is, a sequential data set, not a Partitioned Data Set), then you should omit the parentheses and member name after INCLUDE LIB.

//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 ROCKZAP(R) /*

Note: If you see the following error message when linking RockZap, you can safely ignore it. This message is erroneous:

IEW2651W 511C ESD AMODE 24 CONFLICTS WITH USER-SPECIFIED AMODE 31 FOR ENTRY POINT SIRZAP

Under CMS, the RockZap 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 ROCKZAP load module. In this example, it is assumed that the RockZap object file has a filename of ZAP106.

LOAD ZAP106 (FULLMAP NODUP ORIGIN 20000 AMODE 31 RESET SIRZAP GENMOD ROCKZAP (FROM APPL

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 uploaded the object file into library SIRIUS.LIB with a member name of AUD102. If you uploaded to a non-library data set (that is, a sequential data set, not a Partitioned Data Set), then you should omit the parentheses and member name after INCLUDE LIB.

//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) /*

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.

LOAD AUD102 (FULLMAP NODUP ORIGIN 30000 AMODE 31 RESET JMAIN GENMOD SIRAUD (FROM JCONF

How should the Fast/CRAM object files be installed?

Most of the documentation for Fast/CRAM installation can be found in the Fast/CRAM page, which is currently not updated to reflect web downloads, so a few things must be kept in mind:

• 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 SIRIUS.LOAD. 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 "SIRIUS.LOAD" section, referenced above. This example assumes you uploaded the object files into library SIRIUS.LIB with member names of FCR*27.

  If you uploaded to non-library data sets (that is, sequential data sets, not Partitioned Data Sets), then you 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, except for the SNAPFAST diagnostic utility, which is not reentrant.

  //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) /* //LINKU EXEC PGM=IEWL,REGION=0M, // PARM='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(FCRS27) ENTRY SNAPFAST NAME SNAPFAST(R) /* //

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

  //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 IGCLM244 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 /*

  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 the Model 204 standard CRAM implementations. The subsystem can also be defined dynamically with the SETSSI command:

  SETSSI ADD,SUBNAME=FAST

  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.

How to apply the CPUID zap

The CPUID zap can be applied to the Model 204 online load module using the IBM utility, IMASPZAP or the Rocket utility, ROCKZAP. However, if you download the object files for the online load module, the CPUID zap for your site will already have been applied and this job will be unnecessary. This is an example of what the CPUID zap job might look like using PGM=ROCKZAP. Alternatively, you could use the PGM=IMASPZAP to apply the zap using the IBM utility.

//CPUIDZAP JOB ,'CPUIDZAP',CLASS=A,MSGCLASS=A //ZAP EXEC PGM=ROCKZAP,PARM='MODULE=ONLINE' //SYSPRINT DD SYSOUT=* //STEPLIB DD DSN=DVM204.ROCKZAP.LOAD,DISP=SHR //SYSLIB DD DSN=your.M204.LOADLIB,DISP=SHR //SYSIN DD * * ********************************************************************* * * * Note: If applying with SIRZAP 1.04 or earlier, use NOVER parm. * * * * ********************************************************************* * * * Sirius mods versions 4.6 through 8.3 * * Zap produced 2021/07/07 18:39:36 * * * * Customer - Customer name * * Site - Site ID * * * * Product Start date End date MaxCon Cpus * * * * M204 04/02/2014 * A7572964 * * 06/23/2016 06/30/2022 C5B72964 * * 07/07/2021 * 27C78561 * * RACF 03/30/2016 * A6572964 * * 06/23/2016 06/30/2022 A5B72964 * * VT75 04/02/2014 * * A6572964 * * 06/23/2016 06/30/2022 * A5B72964 * * * * ********************************************************************* * Be sure to zap all load modules containing the * Sirius Mods, e.g., ONLINE, IFAM4, etc. NAME ONLINE SIRE2$ * !NOVERIFY Do not remove this statement REP 0FF4 0000,F0F6,0000,AD5E,0401,0640,D2C1,C9E2 REP 1004 C5D9,4040,B2E3,FC7A,9015,846A,BEA2,D558 REP 1014 D80C,0822,6CE4,5600,1E9F,6497,16CE,FFD0 REP 1024 A755,47BE,B9A3,9C3D,5AD1,BFB7,19A2,AB6A REP 1034 72C3,0059,DD4D,2096,E6F0,BD95,EF32,E261 REP 1044 6D8B,FA9A,AB4E,B782,1F48,5D43,324A,3051 REP 1054 4E25,D9AE,71EA,1F39,B0FD,5054,ED1D,5481 REP 1064 850E,1734,0BA7,E96A,D7BD,55C7,4BC1,CA6A REP 1074 A70C,D460,1287,1FD1,9186,A2C8,282F,8E42 REP 1084 2A92,A512,1088,C7B7,AD78,0E23,9638,4EE9 REP 1094 DA2C,956A,C3CD,2337,C875,11F2,94FB,0B8A REP 10A4 C599,A0E7,4962,99AA,1549,9F7C,E841,5D87 REP 10B4 CD3C,D63E,3319,0A05,C37B,0FB7,565B,27EF REP 10C4 7801,928F,D885,2FAC,70E4,9C5B,F4E2,D600 REP 10D4 0000,0000,0000,0000,0000,0000,0000,0000 * !Sirius checksum 0001,1821 Do not remove this statement

Where can more documentation be found?

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