Model 204
USE OF AND ACCESS
TO PRODUCTS AND FEATURES ARE IN ACCORDANCE WITH THE TERMS AND CONDITIONS
OF THE USER’S SOFTWARE LICENSE. THE PRESENTATION OF MATERIAL HEREIN
DOES NOT, IN ANY MANNER, MODIFY SUCH TERMS AND CONDITIONS.
XDM
CRAM - Setting OS Subsystem Name via Parameter
By James Damon
If you use Cross Region Data Mover (XDM) CRAM then you are familiar with
defining an OS Subsystem Name (SSN) as part of the XDM CRAM installation
process. An SSN is a unique, four character name defined to the operating
system via the SYS1.PARMLIB member IEFSSNxx. This name, along with a channel
name, is used by BATCH2, IFAM2, SQL and TSO or CICS threads to connect to
the desired target Online using XDM CRAM.
Prior
to V6R1.0, the SSN was supplied via IGCLM244, the CRAM interface module
that is loaded at run time both by the Online and by each application attempting
to connect to that Online. The SSN is assembled into IGCLM244 as part of
the CRAM installation process. To improve the flexibility of acquiring this
SSN during Online initialization or CRAM application startup, V6R1.0 provides
the capability of overriding the name specified in IGCLM244 via a run-time
parameter.
XDM
Initialization
Before you start any Onlines that use XDM CRAM, you must submit the M204XDM
job. This job handles all communications between Onlines and CRAM applications
that connect to those Onlines. The JCL for this job is shown in Figure 1.
Figure
1. JCL for the XDM job – to connect Online and CRAM applications
//M204XDM EXEC PGM=M204XDM,PARM='MYV6'
//DD DSN=your.V6R1.0.loadlib,DISP=SHR
|
|
Prior to V6R1.0, all
Model 204 Onlines and CRAM applications that will use this XDM job for communicating
with each other must have loaded a copy of IGCLM244 that was assembled with
the parameter SUBSYS=MYV6.
Note:
Only one XDM job is required per Model 204 release. In other words, this
XDM job can support multiple V6R1.0 Onlines--say production, development,
and QA--all using the same OS Subsystem Name of MYV6. However, the CRAM
channel names (CRIOCHNL, CRFSCHNL, and IFAMCHNL) in each of those Onlines
must be unique since those parameters identify the target Online for a CRAM
connection request.
ONLINE
Initialization
When an Online Model
204 initializes, XDM CRAM is also initialized if XMEMOPT includes the X’80’
setting and there are IODEV=11,13, 23, or 29 threads defined. If this is
the case, CRAM loads IGCLM244 from a load library that is either in the
system link list or in a load library defined by the STEPLIB DD statement.
The value of the SSN is extracted from IGCLM244 and is used to initialize
CRAM.
However, in V6R1.0
the SSN value read from IGCLM244 can be overridden with a new CCAIN parameter,
XDMSSN. The initialization process is illustrated in Figure 2.
Figure
2. VIEW BQLEN output
The Online in Figure
2 initialized the CRAM interface using the SSN supplied by the XDMSSN parameter
(MYV6), overriding the value assembled in IGCLM244 (V6QA). At this point,
any BATCH2, IFAM2, SQL, TSO, or CICS user attempting to connect to this
Online must use the correct channel name and must also load a copy of IGCLM244
that was assembled with the SUBSYS=MYV6 parameter to make the connection.
In V6R1.0, however, BATCH2, IFAM2, SQL, TSO or CICS users can override the
SSN supplied by IGCLM244 via a parameter.
Figure 3.
Passing ssn:channelname via PARM field for a BATCH2 job
//BATCH2 EXEC PGM=BATCH2,PARM='MYV6:V610CRIO,OMC=64,URCTYPE=B'
|
|
The channel name for
an IODEV=29 connection, in this case V610CRIO, has always been required.
In V6R1.0, the SSN may now be prefixed to the channel name using the syntax:
ssn:channelname.
A
Production Environment
Figure 4 is a schematic
of what a production environment might look like. Each box represents a
job submitted to the operating system with the XDM job required to be the
first. M204PROD and M204DEV are two Model 204 Onlines which are submitted
next. After the Onlines are up, the applications on the left can connect
to either one, depending on the channel name used in the PARM field of the
EXEC statement. Each job visits the XDM job to get an address which ultimately
allows the job to connect to the correct Online.
Note: All client
applicatons shown, plus the XDM job, plus the Onlines must all be at the
same release level using the same release of M204XSVC and IGCLM244. For
this feature, the release level of all components must be V6R1.0
Figure 4.
Typical Production Environment
In
Summary
If you are looking for more flexibility in the way you run XDM CRAM applications,
consider using the dynamic OS Subsystem Name support in V6R1.0. This feature
takes the guesswork out of trying to determine what SSN your IGCLM244 load
module was assembled with during installation. That information may not
be readily available but as long as you know the SSN in the Online your
CRAM application is trying to connect to, you do not need to know anything
about the IGCLM244 that Online initialized with. The same is true for the
IGCLM244 that is being loaded by your CRAM application, since you can override
whatever SSN value it was assembled with via the PARM field on the EXEC
statement.
System 1032 Forms Feature,
Part 4
By Tym Stegner
In
the first three installments of this series, we created a simple form
application, STORES_LIB. Using the FORMGEN utility, we demonstrated the
methodology and ease of adapting a System 1032 Forms application. We removed
a field, added two new fields, and rearranged the layout of the form.
We then dealt with the processes and tools available to manipulate System
1032 forms. In the previous installment, we modified the procedures that
process the application to remove the deleted DIVISION_ID field.
In this final installment
we will add the new fields, LATITUDE and LONGITUDE, to the processing
procedures. Our last task is to recompile the library and test the application.
Adding
New Fields
The first place we
must add and modify for the new fields is the group variable defined at
the top of the library. The elements in this variable must be in the same
order as the elements defined within the revised form definition. This
is important because of how the variable is used.
During ADD operations,
there is a feature that sets default values for the form fields to be
entered in subsequent ADD operations. The group variable is the repository
of the default values and it is assigned using a GROUP LET command. As
the variable and the form share a definition of a group field, the form
values can be assigned to the variable by specifying the group name in
the LET statement, and all elements are moved correctly, without specifying
each element individually.
Therefore, we must
reorder the group variable to match the revised order of fields we made
in the previous form definition, when we rearranged the fields on the
form to modify the visitation order. The old variable definition was:
Variable STORES_CRITERIA Group of
STORE_NAME Text 25
STORE_ID Integer
DIVISION_ID Integer
CITY Text 15
STATE Text 15
COUNTRY Text 15
STORE_BUDGET Decimal Precision 12
GROSS_TO_DATE Decimal Precision 12
End_Group
|
|
The new variable
definition also comments out the DIVISION_ID attribute and adds LATITUDE
and LONGITUDE attributes:
In each of these
three procedures, we must add the new attributes and form references to
each command.
Using the MOVE_STORES_REC
procedure as an example, the following is the definition of the procedure:
Procedure MOVE_STORES_REC No_Source Comment -
"Move a record from dataset STORES to form STORES_FORM";
Let STORES_FORM.STORE_NAME = STORES.STORE_NAME, -
STORES_FORM.STORE_ID = STORES.STORE_ID, -
-! STORES_FORM.DIVISION_ID = STORES.DIVISION_ID, -
STORES_FORM.CITY = STORES.CITY, -
STORES_FORM.STATE = STORES.STATE, -
STORES_FORM.COUNTRY = STORES.COUNTRY, -
STORES_FORM.STORE_BUDGET = STORES.STORE_BUDGET, -
STORES_FORM.GROSS_TO_DATE = STORES.GROSS_TO_DATE;
End_Procedure;
|
|
System
1032 is not picky about the order in which the attributes are referenced,
thus, the revised procedure definition is:
Procedure MOVE_STORES_REC No_Source Comment -
"Move a record from dataset STORES to form STORES_FORM";
Let STORES_FORM.STORE_NAME = STORES.STORE_NAME, -
STORES_FORM.STORE_ID = STORES.STORE_ID, -
-! STORES_FORM.DIVISION_ID = STORES.DIVISION_ID, -
STORES_FORM.CITY = STORES.CITY, -
STORES_FORM.STATE = STORES.STATE, -
STORES_FORM.COUNTRY = STORES.COUNTRY, -
STORES_FORM.STORE_BUDGET = STORES.STORE_BUDGET, -
STORES_FORM.GROSS_TO_DATE = STORES.GROSS_TO_DATE,
STORES_FORM.LATITUDE = STORES.LATITUDE,-
STORES_FORM.LONGITUDE = STORES.LONGITUDE;
End_Procedure;
|
|
A similar modification
is made to the ADD and CHANGE commands in the other two procedures.
As described in the
previous installment, the FIND_STORES procedure uses an IF command block
per form field to update text variables with query terms. The variables,
FCMD and SCMD, are defined as text varying and contain a built-up FIND
and SEARCH command, respectively, based on the non-missing field values
processed by the FIND_STORES procedure.
