Reason:
This message exists to provide error information about a failed move. The dbid field is replaced with the DBID. The area is replaced with the area name. The variable-info contains one of many potential values. Details of each follows:
Reason:
This message variable indicates that a move was requested by either a move command or a paused move in process where the area is being opened and when no task area is found available to start the move. If the command is being issued, when there is a task area available it has to be redone. If the move is restarted from a previously paused move, then it cannot be restarted now. The restart is driven again the next time the area is closed and opened. Use the ONLINE_AREA_MOVE command to detect a restart and the move is active and needs to be restarted.
Reason:
This message variable indicates that the specific move command provided an option but it was not properly a value allowed.
Reason:
This message variable indicates that the move command is directed to an area in a database that is defined as VIRTUAL.
Reason:
This message variable indicates that the move command is directed to an area in a database that is defined as ACCESS NOOPT in the MUF startup. Or, the area move is being restarted from a previously paused condition but this MUF has the ACCESS NOOPT specified. In this second case, the move I/O directory is set in place with the two data sets but no additional movement of blocks from the old to the new occurs.
Reason:
This message variable indicates that the move command is requested in a MUF that is part of a MUFPLEX with more than one MUF enabled. As a command, it is rejected. Or, the restart of a move for an opening area has discovered the move requirement. In this second case, the move I/O directory is set in place with the two data sets but no additional movement of blocks from the old to the new occurs. If the other MUF is disabled and this becomes a single enabled MUF, then a close and reopen of the area or the use of a new move command tries to restart the move again.
Reason:
This message variable indicates that the move command is directed in a MUF executing with X_CXX_ALLOW_SHARING YES set. This is a rarely used option and is discouraged. With it in place, no area may be subject to being moved or a previously started and paused move set to be restarted.
Reason:
This message variable indicates that the move command is directed in a MUF executing with an EOJ requested. In this state, a new move task may not start and an existing area move may not be restarted. If the MUF is set as EOJOFF to remove the EOJ requested, then a new move may be started or a paused move restarted with a new move command. A close and reopen of the area also attempts to restart a paused move.
Reason:
This message variable indicates that the move command is directed to an area that has been subject to a move in this MUF and that move was completed but the area has not yet been closed by either a base close or an area close. In this situation, the move is considered active with the I/O director in place. A new move is not possible without the full completion of the prior move including the area to close by the CLOSE command when there are no open users of tables in the base (area). The CASE 2-5 internal close/reopen with users active, does not count for the close allowing the removal of theI/O director.
Reason:
This message variable indicates that the move command is directed to an area that has a current move that is active.
Reason:
This message variable indicates that the area name to move is for a system area that is not allowed to move: CXX, LXX, FXX.
Reason:
This message variable indicates that the area to move was attempted to be opened but that open failed with a return code, provided as the error(error).
Reason:
This message variable indicates that the area to move was attempted to be opened and the base was opened but the area was not found.
Reason:
This message variable indicates that the move command being started encountered an error reading the CXX. The specific error is provided with the error(error) information.
Reason:
This message variable indicates that the move command being started is for a base and area that has no current PREINIT area available. The current areas that have been subject to PREINIT are available in the CXX report using REPORT AREA=CXX,TYPE=P.
Reason:
This message variable indicates that the area subject to PREINIT was initialized with a different block size than the existing area. Since the move is a direct block for block copy, the block size must be the same.
Reason:
This message variable indicates that the new PREINIT area to move to was attempted to be opened but that open failed with a return code, provided as the error(error).
Reason:
This message variable indicates that the new PREINIT area has a data set name too long to allow the suffix of '.OLD' to be added when CASE5 has been selected.
Reason:
This message variable indicates that the move process is unable to get an internal lock to single thread dynamic extends of the area. This should not occur.
Reason:
This message variable indicates that the new PREINIT area has been read and it is not appropriate for the move to occur. That means that it does not currently contain a control block as a data area for a data area move or index area for an index area move. Or, it has been initialized for the wrong data base or area name. Or, the control block is not currently set as a PREINIT area.
Reason:
This message variable indicates that the new PREINIT area has been opened and found to be fewer tracks that the 'old' from area and that a dynamic extend or extends were not successful. Before a move can start, the PREINIT area must be the same size as the same number of tracks as the old area or more tracks. The new PREINIT area has to be initialized again with more tracks or set to allow dynamic extend to extend to more tracks.
Reason:
This message variable indicates that the move had another error trying to start. The specific error is provided with the error(error) information.
Reason:
This message variable indicates that the move had an error deleting the PREINIT area from the CXX. This should not occur.
Reason:
This message variable indicates that the move had an error using the GSETP command to read blocks from the old area.
Reason:
This message variable indicates that the move was subject to the REQABORT function as it was in the test delay driven by command: X_ONLINE_MOVE_DELAY_SEC n.
Reason:
This message variable indicates that the move was interrupted and stopped (paused) because the area was closed.
Reason:
This message variable indicates that an error occurred during the test delay driven by command: X_ONLINE_MOVE_DELAY_SEC n
Reason:
This message variable indicates that the move had an error using the internal GETUP command to read blocks from the old area.
Reason:
This message variable indicates that the move had an error during the CLOSE with disposition (CASE2-CASE5). The move did complete but I/O remains blocked because of the error.
Reason:
This message variable indicates that the move had an error during the REOPEN with disposition. The move did complete but I/O remains blocked because of the error.
Reason:
This message variable indicates that the move had an error moving an index block.
Reason:
This message variable indicates that the move is being requested for an area that has a DD statement present and requesting a CASE3, CASE4, or CASE5 that cannot be supported with the permanent DD statement. The CASE requirements need the ability to close and de-allocate the DD statement as part of the scratch and/or rename process. The move is rejected.
Action:
None. This is for informational purposes only.
Reason:
This informational message provides the following variable information:
Reflects that the block movement is done and the two datasets were updated to reflect all blocks have been moved. After the old rename/delete process is successfully completed, the next process uses an IO gate to:
Once complete, the area is reopened in MUF with just the new (target) dataset being used, the IO gate is removed, and I/O activity resumes. The amount of time that the IO gate is active is likely to be sub-second and is not likely to be detectable.
Messages, if activated, show how this close and remove occur as the actions take place.
Reflects that the block movement is done and the two datasets are updated to reflect all blocks have been moved. The old (source) dataset has been renamed or scratched. The new (target) dataset has been renamed to the original (source) name. The future executions of DBMUFPR or DBUTLTY will only open the original name pointing to the new dataset. All I/O requirements are directed to the new dataset. While the move is complete, the area is still open to this MUF execution as a moved area. Therefore, this status remains until the MUF is terminated or the moved area is subject to a CLOSE.
Note: The only reason to perform a database or area CLOSE to complete the OAM process is to allow a new OAM process of the same area to start. One case is where 24-bit storage is limited to free the 24-bit storage that is used for the old source dataset information. For most cases, waiting until the next recycle of MUF to clear this old information and reset this status would be sufficient.
Reflects that a task area has been allocated to perform the area move and it is just starting.
Reflects that the area move was stopped for one of several reasons and is now being restarted.
Reflects that the additional editing required during the prepare process has completed successfully. Any dynamic extend needed for the new target area to be as large as the move source area has also completed.
Reflects that the OAM has completed the move of all blocks and is in the process of first renaming the old (source) dataset or, later the new (target) dataset. Each of the volumes that the area is cataloged on (old or new) is printed. It is important for MUF to correct all dataset extents on all volumes.
The ‘FROM 1’ reflects that the VOLSER values provided start from the first one. The line provides the first 6 VOLSER values. If more exist, then the message repeats for the VOLSER values ‘FROM 7’. This process continues up to the maximum of 59. This example has 4 VOLSER values.
This message is paired after the previous message with VOLUMES. The value of SCRATCH and the dataset name are to provide the old (source) dataset name. It is the only one that can be set to DELETE causing the SCRATCH. If the SCRATCH is successful, the process continues with the UNCATALOG process. Otherwise, error messages occur and the OAM delay/re-initiation process is invoked.
This message is paired after the previous message with SCRATCH. The value of UNCATALOG and the dataset name are to provide the old (source) dataset name. If the UNCATALOG is successful, the process continues with the UNCATALOG process. Otherwise, error messages occur and the OAM delay/re-initiation process is invoked.
This message is paired after the previous messages. The value RENAME FROM provides the dataset name that is being renamed.
This message is paired after the previous messages. The value RENAME TO provides the dataset name that the FROM is being renamed to. Both are for the VOLSER list in a previous message.
Action:
None.
Reason:
This informational message can occur for the following reasons:
The message format varies after the initial occurrence of ‘BLOCK 1 of’. The message uses TRACK ‘n’ OF ‘n’ for datasets that are bigger than 9,999 tracks. The message uses CYLINDER ‘n’ OF ‘n’ for datasets that are bigger than 9,999 cylinders.
Action:
None.
Reason:
This informational message occurs in support of the STATUS_OAM console (only) MUF command. The variable-info may contain one of the following:
The area blocks have been all moved and the data set subject to either the scratch and rename or the rename and rename. All is complete except that the area has not been subject to a CLOSE since the move and so a new move is not allowed.
The area blocks have been all moved and the data set is waiting for the ability to start the scratch and rename or the rename and rename process.
The area blocks have all moved and the data set is waiting for the scratch and rename process to complete. The data set name (DSN) was not available exclusively when that last attempt was made.
The move is in process with a task area assigned and it is currently in the process of stopping. It might have moved all blocks or might be stopping because the area is in the process of being closed.
The move is in process with a task area assigned and it is preparing to move or doing the move.
The area has been started before and so is partially moved but is not currently being moved as there is no task area assigned to continue the move.
The move is in the process of starting.
Action:
None.
Reason:
This message alerts you to the existence of a program that calls an entry point other than DBNTRY (that is, CBLDBMS or DATACOM). We recommend the use of the DBNTRY entry point. In the message text:
Action:
None. This message is for information only. If you are willing, we recommend that you change to using the DBNTRY entry point. While using DBNTRY is not currently required, many features are not available when not using the DBNTRY entry point. If you have no plans to change to using DBNTRY and do not anticipate requiring the features available only by using DBNTRY, you can ignore this message. Or, you can disable it by using the MESSAGE command. This message occurs once for each unique DBID, table name combination per MUF execution.
A specific error condition replaces the ‘xxx’. Values can be any of the following:
Reason:
The table is in an area that is loaded with URI=NO specified.
Action:
None. The table cannot be altered 24x7.
Reason:
Attempting to run DDUPDATE with 1000 ALTER to a MUF with a Directory CXX that was not set to allow table alters using the 24x7 process.
Action:
You have chosen to not allow a table alter in a 24x7 manner. Therefore, without permission, it is blocked as undesirable. You can choose to allow a future table alter in a 24x7 manner by using DBUTLTY function CXXMAINT with OPTION=ALTER,OPTION2=Y_ALLOW_TA24.
Reason:
Attempting to alter a table in a base that is set as VIRTUAL in the MUF.
Action:
None. Not allowed.
Reason:
Attempting to alter a table in a base set with ACCESS NOOPT during MUF startup.
Action:
None. Not allowed.
Reason:
The MUF is part of a MUFPLEX with two currently enabled or a single MUF with the second in a failed state that needs restarting. This error does not include the case of a Shadow MUF not enabled or an active MUF with a Shadow MUF.
Action:
None. Not allowed.
Reason:
The CXX is being shared or set to be shared with another MUF that was started or is now set with 'X_CXX_ALLOW_SHARING yes'.
Action:
None. Not allowed.
Reason:
The table was attempted to be opened but the open failed.
Action:
The ‘rc (rc)’ is the open error that occurred. Before a Table Alter 24x7 can be requested, it must be resolved.
Reason:
The TA24 process must lock and unlock the base containing the table and it could not be done.
Action:
None. Should not occur.
Reason:
After the open the table could not be found.
Action:
None. Should not occur.
Reason:
The table name that is presented is an ‘any’ parent.
Action:
None. Not allowed.
Reason:
The table ID or occurrence information does not match between Datadictionary and the Directory CXX.
Action:
None. That information can only be updated using a 1000 CATALOG with the base closed. The area is set in history status and must be backed up and loaded which could be a long outage if the ID changed.
Reason:
The table is variable or being changed to variable.
Action:
None. Not allowed.
Reason:
The change is to a compression routine starting with DB.
Action:
None. Not allowed.
Reason:
In processing the data control block to validate and activate TA24, an error occurred.
Action:
Address the return code.
Reason:
An error occurred trying to allocate a task area to start the TA24 row updates.
Action:
Address the error
Reason:
No task area was found available to start the TA24 row update process.
Action:
None. It tries again next time base is closed and opened. If you want it started sooner, when a task becomes available then do the –UPD with 1000 ALTER again. It sees the transition active without a task and tries to allocate it then.
Reason:
The TA24 process requires some space in the data control block and none is available. The lack of space is not normally a problem. It would be more likely if the area has a small block size or many tables.
Action:
None. There is no workaround to no space. A larger block size would help which would need an outage to catalog with a larger block size and then a BACKUP and then INIT and LOAD.
Reason:
The table has user compression and is in an area that is loaded with a release older than supported through TA24. Releases 9.0 and later are valid.
Action:
None. This table cannot be altered.
Reason:
An unexpected internal error condition occurred.
Action:
Contact CA Support.
Reason:
A DBUTLTY function BACKUP is requested with the RECID=YES option. This combination is not allowed with an area contains a table that is in the middle of a transition from one compression option to another. A successful RECID=YES backup is not possible during a transition.
Action:
Rerun the option when no table is being transitioned. Other forms of BACKUP and EXTRACT are available.
Reason:
During a physical BACKUP or EXTRACT a new TA24 was started. Do not start a new TA24 during a BACKUP or EXTRACT.
Action:
The BACKUP/EXTRACT fails and must rerun.
Reason:
During a REORG, the area contains one or more tables that are actively being transitioned from one form of compression to another. The REORG function does not execute in this condition.
Action:
Execute the function once the transition is complete and no new one has started.
Reason:
During the TA24 row update task, it was set to REQABORT to be stopped.
Action:
None., The process terminates as requested. The TA24 process restarts next time the base is closed and opened. You can restart the TA24 task without a close/open by doing another DDUPDATE –UPD with 1000 ALTER for the table.
Reason:
During the TA24 row update task, it noted that an EOJ was requested. It stops processing and closes.
Action:
None, it was done to allow the MUF to EOJ.
Reason:
During the TA24 row update task, it noted a return code in its processing to read and update the table. The ‘command’ is a Datacom command such as GETIT and the rc (rc) is a return code.
Action:
Research and address the error. The TA24 process starts again the next time that the base is closed and opened. You can restart the TA24 task without a close/open by doing another DDUPDATE –UPD with 1000 ALTER for the table.
Reason:
During the TA24 row update task, it noted that the base was set to CLOSE AND STOPS PROCESSING AND DOES A CLOSE.
Action:
None. It terminates as requested. The TA24 process restarts the next time that the base is closed and opened. You can restart the TA24 task without a close/open by doing another DDUPDATE –UPD with 1000 ALTER for the table.
Reason:
For QA testing. You should not see this error. This option causes the TA24 task to start no work but instead close and end to leave the table in an active TA24 status.
Action:
None
Reason:
Shows progress for the Alter Table 24x7 process. The message appears when processing the first row, after the last row, and approximately every 2 minutes during the process. Variables are:
Action:
None. This message is informational. It is intended to help estimate when the process might complete.
The 1397 is an example DBID and contains the number from 1 through 5000.
The F02 is an example table name and contains the specific table name.
The ‘xxx’ can be one of these values:
Reason:
This message occurs if the table subject to an active TA24 has no current task to update the rows from the old values to the new. The base could be closed, the task was subject to REQABORT, no task was available at the time it was needed, an error occurred in the task, and so on.
Reason:
This message occurs if a current task is running for this particular table. It can be identified by having a Job name of ‘***TA24 ‘.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|