This format of the OPERAND clause describes operands that affect the way CA ACF2 for z/ VM processes other operands.
label OPERAND value {-}
[{,maximum-length}] {-}
[{,OCCURS=nnn}] {-}
[{,TRAN=routine}] {-}
{,TYPE=APREVADR|NONEXCL|NXTOPDEF|RANGE|SINGULAR|STOR}
To illustrate how the TYPE verb works, review the STCP model we ship with CA ACF2 for z/ VM. Here you can see a use for TYPE=APREVADR and TYPE=STORADDR. We use them in the STCP model as follows:
OPERAND HEXLOC,8,TRAN=STORADDR,TYPE=STORADDR
OPERAND HEXWORD,16,TRAN=HEX,TYPE=APREVADR
If you issue the STCP 20000 07000700 command, the 20000 is a storage address. CA ACF2 for z/ VM interprets the TYPE=STORADDR verb and saves the storage address so that, when CA ACF2 for z/ VM processes the data to be stored (HEXWORD), it updates the affected storage address.
When CA ACF2 for z/ VM processes the 07000700, the TYPE=APREVADR verb tells CA ACF2 for z/ VM to add that the number of bytes in this hexword to the previous storage address. After interpretation, as a result of this command, CA ACF2 for z/ VM stores 07000700 in locations 20000 through 20003. TYPE=STORADDR is only effective when you use it with TYPE=APREVADR, as shown in the above example.
To illustrate how to use the TYPE=NONEXCL and TYPE=NXTOPDEF, review the following excerpts from the SPOOL model.
CHAR GROUP=KEYWORD
OPERAND CHARS,2
OPERAND NAME,4,TRAN=ANY
OPERAND GROUP=MORECHAR
GROUP END
MORECHAR GROUP TYPE=KEYWORD,OCCURS=3
OPERAND CHARS,2,TYPE=NXTOPDEF
OPERAND NAME,4,TRAN=ANY,TYPE=NONEXCL
GROUP END
If you issue the SPOOL PRT CHARS nam1 CHARS nam2 nam3 FORM STD command, CA ACF2 for z/ VM processes the command as:
Fills in the CHARS and NAME operand clauses in the CHAR GROUP clause.
Fills in the first occurrence of the CHARS and NAME operand clauses in the MORECHAR GROUP clause.
Compared against the second occurrence of the CHARS operand clause and gets a nomatch condition. Because you specified the TYPE=NXTOPDEF (next operand's default), CA ACF2 for z/ VM saves the location of this clause. The nam3 is then compared to the NAME operand clause. Because you specified TYPE=NONEXCL (nonexclusive) verb, and it was not preceded by the keyword CHARS, CA ACF2 for z/ VM examines the rest of the format to see if nam3 fits anywhere else. Because it does not, nam3 is plugged into the NAME clause and, because there is an outstanding NXTOPDEF, replaces chars in the NAME clause.
When processed, it does not match to CHARS and does not fit the NAME operand clause because it matched another operand elsewhere in the format.
TYPE=NONEXCL is only effective when used with TYPE=NXTOPDEF, as shown in the above example. However, you can use TYPE=NXTOPDEF by itself.
The TYPE=RANGE verb says that this operand clause can accept an operand that is a range and contains both a low and high number. The DETACH model contains an example of this: OPERAND RCUU,7,TRAN=RCUU,TYPE=RANGE. You can only specify TYPE=RANGE with the TRAN=RCUU, TRAN=VCUU, TRAN=LDEVXA, and TRAN=LDEV routines. You do not have to specify TYPE=SINGULAR because it is the default setting for all operand clauses.
The OCCURS=nnn verb indicates you can specify this particular operand more than once. The IPL model shows how the OCCURS=nnn works in an OPERAND clause: OPERAND,P2,8,TRAN=ANY,OCCURS=31,OPTIONAL. In this example, you can specify up to 31 separate PARM operand values.
You can write only one rule operand to cover the entire operand clause. This is a permanent restriction. However, if this does not suit your needs, break the syntax model down to be more finite:
OPERAND P2,8,TRAN=ANY,OPTIONAL
OPERAND P3,8,TRAN=ANY,OPTIONAL
.
.
.
OPERAND P32,8,TRAN=ANY,OPTIONAL
Operand clauses, like the one above, are for variable data that is usually application-specific. The TAG command contains a good example.
The tagtext in the command tells an application to do a specific function. For example, TAG DEV PRT CHICAGO tells the application to print on the device named Chicago. RSCS uses the tagtext to control routing of spool files. You define to RSCS all of the link IDs that RSCS can talk to. To control the IDs a user could send to, modify the syntax model, then write rules to cover it. For example, if you had nodes of New York, Chicago, Las Vegas, and San Diego in your network, you could make your own version of the model by adding the following format first in the TAG model:
OPERAND DEV,2
OPERAND VUR,7,TRAN=VUR,SPOOLOPT=(CON,PRT,PUN,RDR)
OPERAND LIST=((NEWYORK,8), -
(CHICAGO,7), -
(LASVEGAS,8), -
(SANDIEGO,8), -
)
FORMAT END
With the above format, you can easily write rules that apply to your needs. To limit Joe to only send to New York, Sue to Chicago, and Ann anywhere, you can write a rule as:
$KEY(TAG) MDLTYPE(-) DEV VUR NEWYORK UID(JOE) ALLOW DEV VUR CHICAGO UID(SUE) ALLOW DEV VUR - UID(ANN) ALLOW
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|