|
The following describes how to customize MSO for your site. |
In this section: |
The MSO configuration file is a sequential data set that is allocated to ddname FOCMSO in the MSO job. It should have LRECL=80 and RECFM=F or RECFM=FB. A sample configuration file is supplied in MSO.DATA(FOCMSO). For further details see The MSO Configuration File.
To install MSO, the configuration file must contain at least the following entries:
EXTSEC
LU2_NAME
SERVICE
PROGRAM
NUMBER_READY
MAXIMUM
Specify EXTSEC = YES if external security is being used.
Specify LU2_NAME if MSO is being accessed from VTAM. If not, then omit this record.
We recommend initial values for NUMBER_READY and MAXIMUM of 1 and 8, respectively.
Create the MSO JCL for your site. A sample is in MSO.DATA(MSO), as shown below.
//*** Your JOB card
//MSO EXEC PGM=SSCTL,REGION=32M
//STEPLIB DD DSN=prefix.FOCLIB.LOAD,DISP=SHR
//ERRORS DD DSN=prefix.ERRORS.DATA,DISP=SHR
//FOCMSO DD DSN=prefix.MSO.MSOCONFG,DISP=SHR
//MSOPRINT DD SYSOUT=*,DCB=(LRECL=133,BLKSIZE=133,RECFM=FA)
//MSOPROF DD DSN=prefix.MSO.MSOPROF,DISP=SHR
//MSGET DD DSN=prefix.MSO.MSGET,DISP=SHR
//MSPUT DD DSN=prefix.MSO.MSPUT,DISP=SHR
//FOCCONS DD DSN=prefix.MSO.MSOCONS,DISP=SHR
//STDOUT DD SYSOUT=*,DCB=(LRECL=133,BLKSIZE=133,RECFM=F)
MSO can be run as either a started task or a batch job, depending on your operational requirements.
Started tasks may only be started by MVS operators, and generally have their JCL stored in libraries that may only be updated by authorized personnel.
Batch jobs may be started by MVS operators or by anybody with access to the JCL, and can be stored in libraries that are easier to update.
Once MSO is running, there is no difference in MSO's behavior between running as a started task or as a batch job. It is important, however, that MSO not have any special security authorization if it is running as a started task; such authorization will interfere with MSO's user-level security.
The following ddnames are mandatory, and should be allocated as discussed here:
|
STEPLIB |
Is mandatory unless FOCLIB.LOAD is accessible via JOBLIB or the link list. If FOCLIB.LOAD is APF-authorized, then all libraries in the concatenation must also be APF-authorized. If Internal APF Authorization is not being used, then ddnames FOCLIB and USERLIB should not be allocated; all load libraries should be allocated in STEPLIB. With Internal APF Authorization, non-authorized libraries, such as FUSELIB.LOAD, may be allocated to USERLIB. |
|
ERRORS |
Points to the ERRORS.DATA library. This must be from the same FOCUS release as FOCLIB.LOAD. If any data adapters are being used, their error message libraries must either be concatenated to, or copied into, ERRORS.DATA. |
|
FOCMSO |
Contains the MSO configuration file, as described in The MSO Configuration File. This file may be a sequential file, an in-stream (SYSIN) data set, or a PDS member. |
|
MSOPRINT |
Points to the MSO log file. The file must be allocated with LRECL=133 and RECFM=FA or FBA. It is recommended that MSOPRINT be allocated to SYSOUT. |
|
MSOPROF |
Contains the profiles for MSO users, to be executed upon logon to MSO. While this library must be allocated, it is not required that it contain any profiles. |
The following ddnames are optional, and should be allocated as needed:
|
MSGET MSPUT |
Point to the inter-address-space communications data sets used by MSO. These are mandatory if access to MSO is being made from CICS and/or TSO or if MSOKILL is used. If all MSO access is from VTAM, then these may be omitted. |
|
FOCCONS |
Contains the configuration file for the MSO Console. It must be allocated if MSO Console is installed. This file may be a sequential file, an in-stream (SYSIN) data set, or a PDS member. |
|
STDOUT |
Is used by the MSO Console for trace information. If MSO Console is installed, and communications traces are needed, it must be allocated. |
|
IBISNAP |
Is used by the IBI Snapshot Facility. If allocated, it overrides the default allocation of SYSOUT=A and/or the default SYSOUT class specified in the MSO configuration file. In addition, allocating this in the MSO JCL causes all snapshots to be written to the same allocation, whereas the default behavior would cause a separate JES allocation for each snapshot. It is recommended that you omit IBISNAP from the JCL, and instead select a held SYSOUT class via the IBISNAP configuration parameter. For further information see The MSO Configuration File. |
|
USERLIB |
When Internal APF Authorization is active, load libraries that are not APF authorized may be allocated to USERLIB. |
In general, any files that are read-only for all users may be allocated in the MSO JCL, and any that must be written by one or more MSO users (except IBISNAP) must not be allocated in the MSO JCL.
Files that are read-only and are being used by most or all MSO users should be allocated in the MSO JCL. However, allocations that are done in the MSO JCL may not be freed or changed by a user, so this may only be done for allocations that are completely static.
If VSAM files are allocated in the MSO JCL, you must ensure that SZERO=YES is specified in the MSO configuration file.
If you are using Internal APF Authorization (i.e., if APFAUTH=INTERNAL is specified in the MSO configuration file), then you must allocate ddname USERLIB in the MSO JCL.
The ddnames SYSIN, SYSPRINT, OFFLINE, and FOCSORT should not be allocated in the MSO JCL. If they are allocated, they will be ignored -- they must be allocated by the individual FOCUS subtasks, if needed.
Create the MSOKILL JCL if required. The MSOKILL job is an alternate method of bringing down MSO without requiring access to an MVS Console or the MSO Console facility.
Sample JCL for MSOKILL is available in MSO.DATA(MSOKILL). Make sure that the communications data sets MSGET and MSPUT are the same data sets as in the MSO JCL.
If MSOKILL will not be used, MSO must be brought down using the STOP or MODIFY operator commands (see MSO Operator Commands), or the STOP or SHUTDOWN commands in the MSO Console (see The MSO Console).
| Information Builders |