Internal Developing Model 204 from WSL

Internal use only. This page is intentionally not linked from the main page or any category. Do not link it from customer-facing pages.

Creating Model 204 authorization keys (internal)

Model 204 products are licensed per CPU. An authorization key (also called an authorization zap or AUTH zap) is generated on demand by the Rocket maintenance subsystem (the maint procedures) and identifies the CPU serial number(s), the start and end dates, the products, and, for thread-based products, the maximum thread count.

Keys are not created by hand. They are built by the maintenance subsystem when an authorized user requests one, either from the web or by e-mail.

Before you start

• You need a maintenance-site login (userid) with access to the customer. Access is checked against the customer nickname; a user who is not authorized for the nickname receives a "401 Unauthorized" response.
• The customer must already exist in the maintenance database (customer record, type C) with its licensed products. To add a new customer, use the Add a Customer / Provide CPU IDs page (cust1).
• You need the customer's CPU ID(s).

Step 1: Get the CPU ID from the customer

The authorization code uses only the 8-hex-digit CPU serial number. The surrounding bytes are ignored: the leading FF/00 flag, the following LPAR byte (for example 04), and the trailing four digits. The LPAR is not inspected by the authorization code.

System	Command	Example response	Value to use
z/VM	CP Q CPUID (from the virtual machine that will run the products)	CPUID = FF04686420030000	68642003 (FF flag, 04 LPAR, serial, 0000)
z/OS (MVS, OS/390)	D M=CPU (operator or SDSF console with command authority)	SERIAL column: 0468642003	68642003 (the leading 04 LPAR prefix may be omitted)
z/VSE	SIR command	AR 0015 CPUID VM = 00379B7891758000 VSE = FF379B7891758000	9B789175 (use either the VM or VSE value; 37 is the LPAR)

The maintenance site accepts 8 or 10 hex digits. A 10-digit value (LPAR byte plus serial, as z/OS shows it) is compared to existing customers using its rightmost 8 digits, so entering the 8-digit serial is simplest.

Step 2: Find or add the customer

1. Sign on to the maintenance site.
2. To check whether a CPU already belongs to a customer, use Add a Customer / Provide CPU IDs and enter the CPU ID. If it matches an existing customer, you are redirected to that customer's page (dlist?nickname=...); otherwise you can add a new customer.
3. Confirm the customer record: nickname, company, operating system, distributor, and the CPU list. Mark test or inactive customers with Inactive or Test Client?.

Step 3: Request the key

1. From the customer's page (dlist), choose Download authorization keys (authlist?nickname=nickname).
2. Select the key to build:
   • All Authorized Products (prefix ALL), which is the normal choice, or
   • a single product, if the customer needs only that one.
3. Enter the TCP/IP address (tcpaddr) or e-mail address that should receive the key. Email links send the key to the address on the customer record.
4. Click the download or e-mail link.

Behind the scenes, the web procedure (MAINTP_DOWNLOAD, action GETAUTH) submits a background request of the form:

AUTH <i>procname</i> <i>prefix</i>AUTH <i>nickname</i> FOR <i>userid</i> [DR <i>cpu</i>[,<i>cpu</i>...]] [DRSTART <i>yyyymmdd</i>]

The background job builds a temporary procedure named AUTHuserid.time, and the web procedure waits (up to about 100 seconds) for it, then sends it back. The temporary procedures are deleted on the next request by the same user.

Disaster Recovery (DR) keys

A DR key adds temporary authorization for additional CPUs, on top of the CPUs already licensed.

• Enter one or more CPU IDs (8 to 10 hex digits each, separated by commas or blanks) and a start date.
• The start date must be valid, not more than 30 days in the past, and not more than one year in the future. The key is valid for the DR window starting on that date.
• Each customer has a DR zap limit (DRLIMIT) and a running count (DRCOUNT). If the count would exceed the limit, the request is rejected with "DR ZAP limit ... has been reached, contact Rocket support." To grant more, raise Maximum number of DR zaps allowed on the customer page.
• The customer page records the start date and CPUs of the most recent DR zap.

Troubleshooting

Message	Meaning / action
Unauthorized - User x / Customer x is not authorized	The userid has no access to that customer nickname. Fix the userid's access.
CPU ID (...) must be between 8 and 10 hex digits	Bad DR CPU ID. Re-enter it.
Disaster Recovery test start date is invalid / too old / too far in the future	Correct the DR start date.
DR ZAP limit ... has been reached	See Disaster Recovery above.
Not found - No authorization zaps called ...	The key procedure is missing for that product prefix.
Internal server error - can't build authorization zap	The background build did not finish or returned a result smaller than 500 bytes. Check the maintenance daemon and retry; otherwise escalate.

Source reference

Repository gitm204/maint:

• MAINTP_OBJLIST: the Download authorization keys page (authlist)
• MAINTP_DOWNLOAD: request validation, DR checks, and the AUTH background request (authSend)
• MAINTP_CUST1: customer maintenance, CPU entry and matching, DR limit fields
• MAINTN_START: routing of the authlist image