gtps4m2b | System Generation |
Before SIP stage I can be executed, perform the tasks as outlined in the following paragraphs, depending on your system needs. Special attention should be given to Creating Program Tables and Creating a Site System Allocator.
During stage I execution, a job card will be constructed for each stage II job. This is done by accessing a member (SPJOB) of the ACP.SIPGEN.RELvv data set. This member must be modified according to your needs by adding such items as accounting information or other special functions.
If the output of stage I is going to tape, an output tape must be initialized, labeled and defined in the stage I JCL SYSPUNCH data definition (see example in Sample SIP Stage I Input).
If the LISTAPE parameter of the GENSIP macro is coded (for tape output of multiple assembler), output tapes must be initialized and labeled to conform to the values of the LISTAPE parameter of the GENSIP macro. You may specify volume serial numbers or scratch for each tape. These tapes should be standard label tapes.
ICKDSF allocates and initializes a whole disk storage volume. Once the disk pack is scratched, data sets are allocated on it for the various TPF required files. Special attention should be given to the allocated block size of the FACE table to be generated. The following JCL describes the necessary steps.
//INITDISK EXEC PGM=ICKDSF //SYSPRINT DD SYSOUT=A //SYSIN DD * INIT UNITADDRESS(xxxx) VTOC(0,1,10) - VOLID(yyyy) NOVERIFY where xxxx = the channel and unit address of the volume to be initialized. yyyy = volume serial label of the disk volume
//INITDISK EXEC PGM=ICKDSF //SYSPRINT DD SYSOUT=A //CUU DD DSN=SIPFILES,DISP=OLD,UNIT=xxxx, VOL=SER=yyyy //SYSIN DD * INIT DDNAME(CUU),VTOC(0,1,10) VOLID(zzzz) - NOVERIFY where xxxx = device unit number which the volume is mounted on yyyy = volume serial of the volume to be initialized zzzz = volume serial label of the disk volume
//SCRATCH EXEC PGM=IEHPROGM //DD0 DD UNIT=xxxx,VOL=SER=yyyy,DISP=OLD //SYSIN DD * SCRATCH VTOC,VOL=xxxx=yyyy,PURGE /* where xxxx = device unit number which the volume is mounted on yyyy = volume serial of the volume to be scratched
Notes:
BLKSIZE * 512 >= the size of the largest FACE Table
So, determine the size of the largest FACE table potentially to be used and divide by 512. The resulting number is the smallest BLKSIZE that can be used.
Figure 27. JCL for Allocating TPF Data Sets
//ALLOC EXEC PGM=IEFBR14 //DD1 DD DSN=ACP.OBJ.RELxx.yyyy, // SPACE=(TRK,(850,20)), // DISP=(,CATLG),DCB=(RECFM=FB,LRECL=80,BLKSIZE=400), // UNIT=uuuu, // VOL=SER=zzzzzz //DD2 DD DSN=ACP.LINK.RELxx.yyyy, // SPACE=(TRK,(400,20)), // DISP=(,CATLG),DCB=(RECFM=U,LRECL=80,BLKSIZE=1200), // UNIT=uuuu, // VOL=SER=zzzzzz //DD3 DD DSN=ACP.SYMACRO.RELxx.yyyy, // SPACE=(TRK,(200,20)), // DISP=(,CATLG),DCB=(RECFM=FB,LRECL=80,BLKSIZE=1680), // UNIT=uuuu, // VOL=SER=zzzzzz //DD4 DD DSN=ACP.SYSRCE.RELxx.yyyy, // SPACE=(TRK,(150,20)), // DISP=(,CATLG),DCB=(RECFM=FB,LRECL=80,BLKSIZE=1680), // UNIT=uuuu, // VOL=SER=zzzzzz //DD5 DD DSN=ACP.SALTBL.RELxx.yyyy, // SPACE=(TRK,(20,20)), // DISP=(,CATLG),DCB=(RECFM=FB,LRECL=12,BLKSIZE=3504), // UNIT=uuuu, // VOL=SER=zzzzzz //DD6 DD DSN=TPFxx.ANTS.yyyy, // SPACE=(TRK,(20,20)), // DISP=(,CATLG),DCB=(RECFM=FB,LRECL=80,BLKSIZE=1680), // UNIT=uuuu, // VOL=SER=zzzzzz //DD7 DD DSN=ACP.CLIB.RELxx.yyyy, // SPACE=(TRK,(850,20)), // DISP=(,CATLG),DCB=(RECFM=FB,LRECL=80,BLKSIZE=400), // UNIT=uuuu, // VOL=SER=zzzzzz //DD8 DD DSN=ACP.STUB.RELxx.yyyy, // SPACE=(TRK,(850,20)), // DISP=(,CATLG),DCB=(RECFM=FB,LRECL=80,BLKSIZE=400), // UNIT=uuuu, // VOL=SER=zzzzzz //DD9 DD DSN=ACP.IMPORTS.RELxx.yyyy, // SPACE=(TRK,(75,15,25)), // DISP=(,CATLG),DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200), // UNIT=uuuu, // VOL=SER=zzzzzz |
Figure 28. JCL for Allocating TPFDF Data Sets
//ALLOC EXEC PGM=IEFBR14 //DD1 DD DSN=BDF.V1R1M3.BDFOBJ1.yyyy // SPACE=(TRK,(400,20)), // DISP=(,CATLG),DCB=(RECFM=FB,LRECL=80,BLKSIZE=400), // UNIT=uuuu, // VOL=SER=zzzzzz //DD2 DD DSN=BDF.V1R1M3.BDFLNK1 // SPACE=(TRK,(400,20)), // DISP=(,CATLG),DCB=(RECFM=U,LRECL=80,BLKSIZE=1200), // UNIT=uuuu, // VOL=SER=zzzzzz |
During stage I execution, SIP accesses member SPPGML of ACP.SIPGEN.RELvv to determine which programs and versions must be assembled. This member already exists and contains all released programs including most of those created by SIP skeletons.
The program tables created by SIP using SPPGML are divided into separate groups:
In addition to the program name, each entry may contain a version number, if applicable.
The CP table contains names and, where applicable, version numbers of all the CSECTs that comprise the control program. Each item in this table identifies a member which may consist of one or more copy cards for a specific CSECT. A copy card is an assembly control statement that contains a segment name. During program assembly, these statements will cause the appropriate segment to be assembled according to the sequence in which they appear. Copy cards are used when a CSECT is too large or complex to be called individually.
The user may not modify the CP table except to change a CSECT's version number when it is being replaced by a user-modified CSECT. In such cases, the user CSECT must be installed to the ACP.SRCE.CP.RELvv library for that release before executing SIP stage II.
The DLL load module table contains all the load module names for DLLs with their associated version numbers. An entry exists in the ACP.LINK.RELvv data set for each load module name. For each entry in the DLL list that IBM ships, there will be a build script entry in the ACP.CSRCE.RT.RELvv data set.
The KP table contains all keypoints, with version numbers, that must be in the system. These keypoints (except for CTK1, CTK2, CTK3, CTK4, and CTK9) initially exist as SIP skeletons in data set ACP.SIPGEN.RELvv. A skeleton is an image of the actual unit enclosed in quotes in a punch statement and can have specific values substituted. These skeletons are converted to source code and assembled during SIP stage II. Refer to each skeleton macro listing commentary for specific information on a particular SIP skeleton.
All names in the KP table, except general file keypoints, are 4 characters plus a 2-character version number. General file keypoints (CTKA and CTKV) are identified by general file version number GF.
The KP table must not be modified because of SIP's use of skeletons to create keypoint source code. However, any user keypoints can be added to TPF by placing them into the UR table.
The OL table contains names and version numbers for all programs that will be executed in offline mode and are part of the released ACP.SRCE.OL.RELvv and ACP.CSRCE.OL.RELvv libraries. No changes can be made to the released OL table except to change program version numbers for user-modified programs or change the object code designation. In addition, the source code for all user-modified programs must be installed onto the ACP.SRCE.OL.RELvv and ACP.CSRCE.OL.RELvv libraries for that release before executing SIP stage II. Any user-developed offline programs must be assembled and link-edited without using SIP.
The real-time (RT) and real-time special (RTS) tables contain all system-controlled, ECB-dependent real-time program names with their associated version numbers, which are part of the released ACP.SRCE.RT.RELvv and ACP.CSRCE.RT.RELvv libraries. All program names are 6 characters long with the first 4 characters comprising the segment name, and the last 2 characters being the version number. Any user real-time program may be added to the user real-time (UR) table. User real-time programs will be processed in the same way as system real-time programs. If you want to replace a released program with your own version, just change the released version number to your own version number.
The entries for BAL programs that are called by DLMs are updated with STUB=YES, which means that the object name is added to the stub table (the ISB). During SIP stage II, a DLM stub is generated for each name in this list.
User programs will be accessed via GENSIP macro parameter USRCE, which identifies the user source library. The user source library must be a cataloged data set.
The C language real-time (CRT) and user real-time (CUR) tables contain all ECB-dependent C language real-time program names with their associated version numbers, which are part of the released ACP.CSRCE.RT.RELvv libraries. All program names are 6 characters long, with the first 4 characters comprising the segment name and the last 2 characters the version number. Any C language user real-time program may be added to the CUR table. C language user real-time programs will be processed in the same way as system C language real-time programs. If you want to replace a released program with your own version, just change the released version number to your own version number.
The entries for the TARGET(TPF) programs that are called by DLMs are updated with STUB=YES, which means that the object name is added to the stub table (the ISB). During SIP stage II, a DLM stub is generated for each name in this list.
User programs will be accessed via GENSIP macro parameter USRCE, which identifies the user source library. The user source library must be a cataloged data set.
The ISA table contains all ISO-C assembler function names with their associated version numbers. An entry exists in the ACP.SRCE.RT.RELvv data set for each ISO-C assembler function.
The ISC table contains all ISO-C source file names with their associated version numbers. An entry exists in the ACP.CSRCE.RT.RELvv data set for each ISO-C source file.
The ICL table contains all the load module names (both library and application) with their associated version numbers. An entry exists in the ACP.LINK.RELvv data set for each load module name. For each entry in the ICL table that IBM ships, there will be a build script entry in the ACP.CSRCE.RT.REL.vv data set. ICL entries for DLMs that are called by other DLMS have STUB=YES.
The CPP table contains all the C++ source file names with their associated version numbers. An entry exists in the ACP.CSRCE.RT.RELvv data set for each C++ source file.
The OCO table contains segments for which no source code is shipped. SIP will never attempt to assemble or compile a segment designated as OCO. Object code only programs are shipped as part of the TPF released ACP.OBJ.RELvv library. All program names are 6 characters long, with the first 4 characters comprising the segment name and the last 2 characters the version number. Any object code only program may be added to the OCO table.
Notes:
You may want to modify or add to any of the program tables, subject to the limitation specified for each table. If such a change is desired, update member SPPGML.
SPPGML consists of a series of SPPBLD macro calls. These macro calls consist of a list of program names, a library-type designator, a support function indicator, an indicator to define if the program is available in object code format, and a subsystem designator. The SPPGML macro is important in the SIP process because it provides the basis of selectability in the stage I assembly. A program module defined in SPPGML will be included or excluded from a user's system based on the options selected by the user in the stage I macros. The format of the SPPGML statement is as follows.
cc10 cc17 SPPBLD TYPE,PGM1,PGM2,......,PGMN,FUNC=yyy,OBJ=YES|NO,SS=ssname,OPT=n
Where:
Valid library types are:
An error message occurs if you code RENT=NO for type CPP.
An error message occurs if you code DLL=NO for type CPP.
Notes:
See GENSIP for more information about the GENSIP macro.
Any of the previous library types can be modified in the SPPGML macro by using the MVS utility, IEBUPDTE, or any corresponding 80-column card image editor.
SPIPML, released on library ACP.SIPGEN.RELvv, is a list of the program components required by a WTC user in addition to those in SPPGML. SPIPML lists all the real-time programs required by the IPARS application. (Offline programs are listed separately in member SPWTC.) The comments made previously concerning modifications to the member names and inclusion of user versions apply equally to member SPIPML.