CCAPrint Newsletter for Model 204 and System 1032 Users

Introducing the Special Attributes
In the November 2009 article, we examined the system defined system-level attributes: $ID, $NREC, and $RECNO. In this article, we’ll go on to the other system-level attributes available to the dataset designer, the special attributes. The special attributes are system updated attributes that track user names, record numbers, or dates. You can adjust the date/time granularity by applying a date/time precision quality.

Tracking with the Special Attributes
The user or dataset designer need only include named attributes having the following data types to store such information. These data are automatically updated by System 1032 itself when you or an application issue the updating command. The special attributes data types available are:

The Integer OF Identification (IOI, or IntofID) attribute is similar to the $ID system attribute, but with an additional capability. The $ID value of a record is renumbered when records are deleted or their sort order is changed by a dataset rebuilding operation, because the value of $ID is based on the physical order of the data records stored in the dataset. However, although an IOI attribute is also incremented automatically as $ID is, you can preserve its values across a dataset rebuild by including the IOI attribute in the RD used to dump and load the dataset in question. It is also possible to seed an IOI value to specify a particular magnitude of automatically updated numbers.

Using Special Attributes
You can use these special attributes as you would use any other date/time or text attribute, with the limitation that the user cannot change their values nor add data directly into those attributes. For example:

Another special attributes example
As previously described, the major use of special attribute data types is tracking information about when and who updated records. The following example looks at one year’s worth of dinner review reports submitted. The requisite attributes are as follows:

We will first use DATE_ENTERED to locate the records of interest, then create two reports: the first, a breakdown of who submitted the dinner review for the time period; the second, who last updated or closed the review.

$COUNT provides an automatic record count of the number of records within a sort group. Thus, with no other attribute or data involvement, we can use these special attributes to see the top dining review submitters and updaters for the year 2000.

In Summary
This article reviews the system updated special attribute data types. Using these attributes can add value to your datasets by automatically recording who updated what records and when. Also, by specifying which special attribute is used, you can keep an eye on which sort of action took place. Most sites use one or more of these attributes for tracking purposes. Another use might include providing hooks for record level security.

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.

Clearing CRAM XDM Subsystem Control Blocks with CRAMCLR
By Mark LaRocca

mark The M204XDM job is the cross region data mover that provides services to all Model 204 Onlines and BATCH2 jobs that use the XDM version of CRAM.

Every now and then an operator may cancel the M204XDM job. Although CCA recommends that the M204XDM job be flagged as non-swappable and non-cancelable, an operator may override this and XDM does not terminate gracefully. When this situation arises, resubmitting the CRAM XDM job will probably result in the following error:

This happens because CRAM XDM is installed using an z/OS subsystem name. For purposes of our example, let�s call it CR01. Normally, the M204XDM job waits on a reply and the operator can respond EOJ or EOJ,FORCE to bring down the job gracefully. When the job is simply canceled, XDM cannot cleanup control blocks in storage for its z/OS subsystem name. Of course, this means that when the job is brought back up, CRAM XDM believes that this subsystem name is in use. What to do? There are three options:

Obtaining CRAMCLR
In this article, I demonstrate how to use CRAMCLR to clear the CRAM subsystem and recover from such a scenario. But first, let me provide the installation instructions.

		In Model 204 V7R1.0, the CRAMCLR JCL, object and load module, are all included in the installation libraries. However, a special zap from CCA support is required to activate the load module.
		For Model 204 V6R1.0, Early Warning 269: Free Inaccessible CRAM-XDM Components – CRAMCLR, is available providing the CRAMCLR JCL and CRAMCLR object. You must link it as a CRAMCLR module, put it into a load library, and activate it with the special zap provided by CCA customer support.

Why the special zap restriction? This is a simple precaution to protect our customers from accidentally running this job and clearing subsystem storage. Imagine an active M204XDM job handling multiple Onlines suddenly losing its stored information. Obviously, this is not a good thing. So, I remind you to take care when running CRAMCLR.

Using CRAMCLR
Now, on to my main point: how do you use CRAMCLR? Basically, there are two scenarios for which you may need CRAMCLR JCL.

1. The M204XDM job ended abnormally with the M204XDM.007 message and cannot be brought up.

2. CRAM batch jobs, such as BATCH2, end with the M204XDM.007 message.

Scenario 1
The M204XDM job is down and fails to come up after issuing the M204XDM.007 message. In this scenario, you must clear the CRAM subsystem name storage. Our example uses subsystem CR01.

Run the following CRAMCLR JCL

//JOBLIB DD DSN=CRAM.AUTH.LOADLIB,DISP=SHR
//XDMNC EXEC PGM=CRAMCLR,PARM=’CR01’
//SYSPRINT DD SYSOUT=A
/*

If there are Onlines or other jobs using this subsystem name, this job will end without clearing the subsystem storage, and display informational messages indicating that other users may still be attached to this M204XDM job. After confirming that this subsystem name is correct, you can force it to clear as follows:

//JOBLIB DD DSN=CRAM.AUTH.LOADLIB,DISP=SHR
//XDMNC EXEC PGM=CRAMCLR,PARM=’CR01=FORCE’
//SYSPRINT DD SYSOUT=A
/*

Please take care that the name, CR01, is correct.

After successfully running CRAMCLR, bring up the M204XDM job.

Scenario 2
A CRAM batch job, such as BATCH2, ends with the M204XDM.007 message.

This might have been caused by an Online terminating abnormally as its CRAM XDM channels were not cleared properly.

When the Online is brought up again, it may have trouble opening a CRAM channel.

Or, if it comes up successfully, a batch job using one of its CRAM channels may encounter the M204XDM.007 message. In this case, the CRAM XDM region is up and running, the Onlines connected to this XDM region are fine, and it is only the CRAM XDM channel that needs to be cleared.

For BATCH2 this channel is identified in the BATCH2 JCL on the EXEC card by PARM=’criochannelname’, and in the Online CCAIN as CRIOCHNL=criochannelname.

For our example, let’s use PSMLCRIO as the CRAM channel name. Below is the JCL to clear any particular CRAM XDM channel.

//JOBLIB DD DSN=CRAM.AUTH.LOADLIB,DISP=SHR
//XDMNC EXEC PGM=CRAMCLR,PARM=’CR01,PSMLCRIO’
//SYSPRINT DD SYSOUT=A
/*

After executing this JCL, re-run the batch job. Running the CRAMCLR JCL easily clears Scenario 2.

CRAM XDM should not encounter this problem, since the M204XDM job is meant to run 24/7 and should never be brought down at all. Furthermore, if you need to bring it down, simply do so in a graceful manner: reply EOJ to the region’s outstanding reply.

In Summary
I hope that this information has cleared up (pun intended) any questions about clearing CRAM XDM subsystem names with the CRAMCLR utility.


	System 1032: System-level Special Attributes	Printer-friendly version
	Model 204: Clearing CRAM Subsystem Control Blocks with CRAMCLR	Printer-friendly version

Date Of Entry	Date_Time Of Entry	User Of Entry
Date Of Change	Date_Time Of Change	User Of Change
Date Of Delete	Date_Time Of Delete	User Of Delete
Integer Of Identification

		The User-Of attributes store the VMS username of the process involved.
		The Of-Entry attributes cover the commands that create records within a dataset, including ADD, LOAD, APPEND and the API commands DM_ADD_REC and DM_ADD_SET.
		The Of-Change attributes cover record updates done using the CHANGE command or the API record update commands, including DM_CHANGE_REC, DM_CHANGE_SET, and the attribute transfer commands.
		The Of-Delete attributes cover records that are removed by DELETE command processing. Note that use of the UNDELETE command does not reset the values for Of-Delete attributes.

	1.	IPL z/OS This clears all subsystem storage, which is easy enough, but perhaps a bit drastic.
	2.	Re-assemble IGCLM244 with a new subsystem name, CR02, using the CRAMINS installation JCL. Install the new IGCLM244 in the CRAM LOADLIB. When you bring up the M204XDM job, IGCLM244 is loaded and will be pointing to this new subsystem. This is a better solution than option 1. Note that if a spare subsystem name is not available, you may need to add the new subsystem name to the operating system via the member IEFSSNxx in SYS1.PARMLIB. This may also require an IPL for the operating system to pick up the new SSN. Check with your systems programmer to see if an IPL is necessary.
	3.	Run Model 204’s CRAMCLR, the CRAM Clear JCL The CRAMCLR JCL cleans up the subsystem control blocks and the M204XDM job can be brought up without a problem. This solution is even better than option 2.

CCAPRINT: A Newsletter for Model 204^® and System 1032^® Users	December 22, 2009

	1.	The M204XDM job ended abnormally with the M204XDM.007 message and cannot be brought up.
	2.	CRAM batch jobs, such as BATCH2, end with the M204XDM.007 message.