m204wiki - User contributions [en]

M204.2980

2025-08-27T22:58:59Z

Ekern:

{{Template:M204.2980 skeleton}}
__NOTOC__

Model 204 attempted to read a Page from a Database file but determined the Page returned
was not the page requested for one of the following reasons:
* The Page's File Name is not correct
* The Page's Table Number is not correct
* The Page's Page number is not correct
* The DDNAME, starting seek address and offset are provided for debugging purposes.


Response:
Notify your system manager and contact Technical Support.

Have the Audit trail ready.


Version introduced:
7.9

{{Template:M204.2980 footer}}
[[Category: Pending messages]]

DUMPLIMD parameter

2025-08-04T20:44:46Z

Ekern:

{{Template:DUMPLIMD parameter subtitle}}

==Summary==
<dl>
<dt>Default value
<dd>3
<dt>Parameter type
<dd>System
<dt>Where set
<dd>System manager
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> 7.9
</dl>

==Description==
Limits the number of duplicate snaps or SVC dumps M204 can take. 
<var>Note:</var> While the default value is 3 to remain consistent with how the [[SNAPLIMD parameter]] operates, <var>DUMPLIMD</var> can be set to values greater than or equal to 0. 

[[Category:Parameters]]
[[Category:System parameters]]

DUMPLIMD parameter

2025-08-04T20:28:11Z

Ekern:

DUMPLIM parameter

2025-08-04T20:19:03Z

Ekern:

{{Template:DUMPLIM parameter subtitle}}

==Summary==
<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>System
<dt>Where set
<dd>System manager
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> 7.9
</dl>

==Description==
Limits the number of snaps or SVC dumps M204 can take.

[[Category:Parameters]]
[[Category:System parameters]]

DUMPLIM parameter

2025-08-04T20:16:57Z

Ekern:

{{Template:DUMPLIM parameter subtitle}}

==Summary==
<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>System
<dt>Where set
<dd>System manager
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> 7.9
</dl>

==Description==
Limits the number of M204 snaps or SVC dumps can take.

[[Category:Parameters]]
[[Category:System parameters]]

DUMPLIM parameter

2025-08-04T20:16:36Z

Ekern:

{{Template:DUMPLIM parameter subtitle}}

==Summary==
<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>System
<dt>Where set
<dd>System manager
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> version 7.9
</dl>

==Description==
Limits the number of M204 snaps or SVC dumps can take.

[[Category:Parameters]]
[[Category:System parameters]]

M204.2991

2025-06-03T20:16:27Z

Ekern:

{{Template:M204.2991 skeleton}}
__NOTOC__

M204.2991: Unable to take CPPAGTHR initiated checkpoint: 'in extended quiesce'.


Response:
Although the [[CPPAGTHR parameter]] limit has been exceeded, no checkpoint can be taken since Model204 is within an extended quiesce. The checkpoint may be taken whenever the extended quiesce is terminated.

Version introduced:
7.9

{{Template:M204.2991 footer}}
[[Category: Pending messages]]

M204.2991

2025-06-03T20:16:19Z

Ekern:

{{Template:M204.2991 skeleton}}
__NOTOC__

M204.2991: Unable to take CPPAGTHR initiated checkpoint: 'n extended quiesce'.


Response:
Although the [[CPPAGTHR parameter]] limit has been exceeded, no checkpoint can be taken since Model204 is within an extended quiesce. The checkpoint may be taken whenever the extended quiesce is terminated.

Version introduced:
7.9

{{Template:M204.2991 footer}}
[[Category: Pending messages]]

M204.2992

2025-06-03T19:25:05Z

Ekern:

{{Template:M204.2992 skeleton}}
__NOTOC__

M204.2992: The number of pre-image pages has exceeded [[CPPAGTHR parameter]].


Response:
An immediate checkpoint is taken. No further action is necessary.

Version introduced:
7.9

{{Template:M204.2992 footer}}
[[Category: Pending messages]]

M204.2991

2025-06-03T19:24:46Z

Ekern:

{{Template:M204.2991 skeleton}}
__NOTOC__

M204.2991: the only token is in extended quiesce.


Response:
Although the [[CPPAGTHR parameter]] limit has been exceeded, no checkpoint can be taken since Model204 is within an extended quiesce. The checkpoint may be taken whenever the extended quiesce is terminated.

Version introduced:
7.9

{{Template:M204.2991 footer}}
[[Category: Pending messages]]

M204.2991

2025-06-03T19:22:14Z

Ekern:

{{Template:M204.2991 skeleton}}
__NOTOC__

M204.2991: the only token is in extended quiesce.


Response:
Although the [[CPPAGTHR|CPPAGTHR parameter]] limit has been exceeded, no checkpoint can be taken since Model204 is within an extended quiesce. The checkpoint may be taken whenever the extended quiesce is terminated.

Version introduced:
7.9

{{Template:M204.2991 footer}}
[[Category: Pending messages]]

M204.2992

2025-06-03T19:20:32Z

Ekern:

{{Template:M204.2992 skeleton}}
__NOTOC__

M204.2992: The number of pre-image pages has exceeded CPPAGTHR.


Response:
An immediate checkpoint is taken. No further action is necessary.

Version introduced:
7.9

{{Template:M204.2992 footer}}
[[Category: Pending messages]]

M204.2991

2025-06-03T14:33:10Z

Ekern:

{{Template:M204.2991 skeleton}}
__NOTOC__

>** Replace this with an explanation of the message, such as the conditions causing it **<


Response:
>** Replace this with a description of the action the customer should take **<

Version introduced:
7.9

{{Template:M204.2991 footer}}
[[Category: Pending messages]]

CPPAGTHR parameter

2025-06-03T13:45:43Z

Ekern:

{{Template:CPPAGTHR parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>System
<dt>Where set
<dd>System manager
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> version 7.9
</dl>

==Description==
CheckPoint PAGe THReshold.
The new fullword CPPAGTHR parameter can be set to force a checkpoint
when the number of pages written to the current stream hits the
threshold.

If the threshold is small and it's hit while the checkpoint PST is
writing out subtran checkpoint data, the threshold is ignored. If
the checkpoint fails (must be non-subtran) it is not retried. 

If the parameter is reset below the number of pages written to the
current checkpoint stream, a checkpoint is immediately forced.

The default for CPPAGTHR is 0, meaning that it is not in use.

[[Category:Parameters]]
[[Category:System parameters]]

CPPAGTHR parameter

2025-06-02T21:17:51Z

Ekern:

{{Template:CPPAGTHR parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd>? ?
<dt>Parameter type
<dd>System
<dt>Where set
<dd>System manager
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> version 7.9
</dl>

==Description==
CheckPoint PAGe THReshold.
The new fullword CPPAGTHR parameter can be set to force a checkpoint
when the number of pages written to the current stream hits the
threshold.

If the threshold is small and it's hit while the checkpoint PST is
writing out subtran checkpoint data, the threshold is ignored. If
the checkpoint fails (must be non-subtran) it is not retried. 

If the parameter is reset below the number of pages written to the
current checkpoint stream, a checkpoint is immediately forced.

[[Category:Parameters]]
[[Category:System parameters]]

D$ONEOF parameter

2025-05-15T21:38:44Z

Ekern: /* Summary */

==Summary==
<dl>
<dt>Default value
<dd>;
<dt>Parameter type
<dd>User
<dt>Where set
<dd>Any user
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> version 6.1
<dt>Example
<dd>b
<dd>%x is float
<dd>%x = $ONEOF('MALE','MALE;FEMALE')
<dd>print %x
<dd>end

<dd>%x is 1 in this case
</dl>

[[Category:Parameters]]
[[Category:User parameters]]

D$ONEOF parameter

2025-05-15T21:30:57Z

Ekern:

==Summary==
<dl>
<dt>Default value
<dd>;
<dt>Parameter type
<dd>User
<dt>Where set
<dd>Any user
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> version 6.1
<dt>Example
<dd>$ONEOF('MALE',MALE;FEMALE)
</dl>

[[Category:Parameters]]
[[Category:User parameters]]

D$ONEOF parameter

2025-05-13T23:55:36Z

Ekern: /* Summary */

{{Template:D$ONEOF parameter subtitle}}

This page is [[under construction]].
==Summary==
<dl>
<dt>Default value
<dd>1 (if argument 1 is one of the strings delimited in argument 2). Argument 3 is the delimiter character-- defaults to ';'). Otherwise, returns 0.
<dt>Parameter type
<dd>User
<dt>Where set
<dd>Any user
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> version 7.8
<dt>Example
<dd>$ONEOF('MALE',MALE/FEMALE','/')
<dd>is same as:
<dd>$ONEOF('MALE','MALE;FEMALE') WHICH EQUALS 1
</dl>

==Description==
? ?

[[Category:Parameters]]
[[Category:User parameters]]

M204.0353

2025-04-08T14:44:38Z

Ekern:

{{Template:M204.0353 skeleton}}

This message is sent to a user's terminal and the audit trail for a successful login or logout. The fields for the message are: 
<ul>
<LI><var class="term">uuuuuuuuuu</var> is the user's user ID. </LI>

<LI><var class="term">aaaaaaaaaa</var> is the user's account. </LI>

<LI><var class="term">llllll</var> is <code>LOGIN</code> when the user is logging in, and is <code>LOGOUT</code> when the user is logging out. </LI>

<LI><var class="term">yy mmm dd</var> is the current Gregorian date (for example, <code>11 MAR 29</code>). </LI>

<LI><var class="term">hh.mm</var> is the current time in hours and minutes. </LI>
</ul>
{{Template:M204.0353 footer}}

M204.0523

2025-04-01T20:00:20Z

Ekern:

== M204.0523 ==



{|
|-
|RETCODE ||
|-
|RETCODE ||
|-
|CLASS ||
|-
|AUDITOR ||
|-
|COUNT ||
|}

{{Template:M204.0523 skeleton}}


{{Template:M204.0523 footer}}

M204.0515

2025-04-01T20:00:04Z

Ekern:

== M204.0515 ==



{|
|-
|RETCODE ||
|-
|RETCODE ||
|-
|CLASS ||
|-
|AUDITOR ||
|-
|COUNT ||
|}

{{Template:M204.0515 skeleton}}


{{Template:M204.0515 footer}}

M204.0514

2025-04-01T19:59:49Z

Ekern:

== M204.0514 ==



{|
|-
|RETCODE ||
|-
|RETCODE ||
|-
|CLASS ||
|-
|AUDITOR ||
|-
|COUNT ||
|}

{{Template:M204.0514 skeleton}}


{{Template:M204.0514 footer}}

M204.0512

2025-04-01T19:59:34Z

Ekern:

== M204.0512 ==



{|
|-
|RETCODE ||
|-
|RETCODE ||
|-
|CLASS ||
|-
|AUDITOR ||
|-
|COUNT ||
|}

{{Template:M204.0512 skeleton}}


{{Template:M204.0512 footer}}

M204.0511

2025-04-01T19:58:06Z

Ekern:

== M204.0511 ==



{|
|-
|RETCODE ||
|-
|RETCODE ||
|-
|CLASS ||
|-
|AUDITOR ||
|-
|COUNT ||
|}

{{Template:M204.0511 skeleton}}


{{Template:M204.0511 footer}}

M204.0511

2025-04-01T19:57:38Z

Ekern:

== M204.0511 ==



{|
|-
|RETCODE ||
|-
|RETCODE ||
|-
|CLASS ||
|-
|AUDITOR ||
|-
|COUNT ||
|}
{{Template:M204.0502 skeleton}}


{{Template:M204.0511 skeleton}}


{{Template:M204.0511 footer}}

M204.0506

2025-04-01T19:57:00Z

Ekern:

== M204.0506 ==



{|
|-
|RETCODE ||
|-
|RETCODE ||
|-
|CLASS ||
|-
|AUDITOR ||
|-
|COUNT ||
|}
{{Template:M204.0502 skeleton}}


{{Template:M204.0506 skeleton}}


{{Template:M204.0506 footer}}

M204.0502

2025-04-01T19:52:14Z

Ekern:

== M204.0502 ==



{|
|-
|RETCODE ||
|-
|RETCODE ||
|-
|CLASS ||
|-
|AUDITOR ||
|-
|COUNT ||
|}
{{Template:M204.0502 skeleton}}


{{Template:M204.0502 footer}}

M204.0523

2025-04-01T18:38:18Z

Ekern: Created page with "{{Template:M204.0523 skeleton}} {{Template:M204.0523 footer}} "

{{Template:M204.0523 skeleton}}


{{Template:M204.0523 footer}}

M204.0515

2025-04-01T18:38:02Z

Ekern: Created page with "{{Template:M204.0515 skeleton}} {{Template:M204.0515 footer}} "

{{Template:M204.0515 skeleton}}


{{Template:M204.0515 footer}}

M204.0514

2025-04-01T18:37:49Z

Ekern: Created page with "{{Template:M204.0514 skeleton}} {{Template:M204.0514 footer}} "

{{Template:M204.0514 skeleton}}


{{Template:M204.0514 footer}}

M204.0512

2025-04-01T18:37:33Z

Ekern: Created page with "{{Template:M204.0512 skeleton}} {{Template:M204.0512 footer}} "

{{Template:M204.0512 skeleton}}


{{Template:M204.0512 footer}}

M204.0511

2025-04-01T18:37:15Z

Ekern: Created page with "{{Template:M204.0511 skeleton}} {{Template:M204.0511 footer}} "

{{Template:M204.0511 skeleton}}


{{Template:M204.0511 footer}}

M204.0506

2025-04-01T18:36:50Z

Ekern: Created page with "{{Template:M204.0506 skeleton}} {{Template:M204.0506 footer}} "

{{Template:M204.0506 skeleton}}


{{Template:M204.0506 footer}}

M204.0502

2025-04-01T18:36:11Z

Ekern: Created page with "{{Template:M204.0502 skeleton}} {{Template:M204.0502 footer}} "

{{Template:M204.0502 skeleton}}


{{Template:M204.0502 footer}}

M204.0509

2025-04-01T18:35:57Z

Ekern:

{{Template:M204.0509 skeleton}}



{{Template:M204.0509 footer}}

M204.0509

2025-04-01T18:34:44Z

Ekern:

{{Template:M204.0509 skeleton}}

This message is issued by the Line Editor in response to the <VAR>[[EDIT command|EDIT]]</VAR> command, and it indicates that the Editor is ready to accept editing commands. <var class="term">procedure</var> is the name of the procedure or previous request that will contain the results of the editing session.

{{Template:M204.0509 footer}}

M204.0509

2025-04-01T18:34:27Z

Ekern:

{{Template:M204.0526 skeleton}}

This message is issued by the Line Editor in response to the <VAR>[[EDIT command|EDIT]]</VAR> command, and it indicates that the Editor is ready to accept editing commands. <var class="term">procedure</var> is the name of the procedure or previous request that will contain the results of the editing session.

{{Template:M204.0526 footer}}

HASHSPIL parameter

2025-02-10T18:37:40Z

Ekern:

{{Template:HASHSPIL parameter subtitle}}
==Summary==
<dl>
<dt>Default value
<dd> 16
<dt>Parameter type
<dd>System
<dt>Where set
<dd>User 0 parameter line
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> version 6.1 or earlier
</dl>

==Description==
If a Hash-Key Record cannot be stored on the page to which its hash-key hashes,
Model 204 will attempt to store that record on the next physical page in that file and is said to have spilled to that page.

HASHSPIL determines the number of times Model 204 will attempt to store a record on a spilled page and therefore, the spill chain length.
Long hash spill chains may affect performance as more records may have to be retrieved before the desired record is located.

[[Category:Parameters]]
[[Category:System parameters]]

HASHSPIL parameter

2025-02-10T18:37:28Z

Ekern: /* Summary */

{{Template:HASHSPIL parameter subtitle}}

This page is [[under construction]].
==Summary==
<dl>
<dt>Default value
<dd> 16
<dt>Parameter type
<dd>System
<dt>Where set
<dd>User 0 parameter line
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> version 6.1 or earlier
</dl>

==Description==
If a Hash-Key Record cannot be stored on the page to which its hash-key hashes,
Model 204 will attempt to store that record on the next physical page in that file and is said to have spilled to that page.

HASHSPIL determines the number of times Model 204 will attempt to store a record on a spilled page and therefore, the spill chain length.
Long hash spill chains may affect performance as more records may have to be retrieved before the desired record is located.

[[Category:Parameters]]
[[Category:System parameters]]

HASHSPIL parameter

2025-02-10T18:37:12Z

Ekern: /* Description */

{{Template:HASHSPIL parameter subtitle}}

This page is [[under construction]].
==Summary==
<dl>
<dt>Default value
<dd>? 16
<dt>Parameter type
<dd>System
<dt>Where set
<dd>User 0 parameter line
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> version 6.1 or earlier
</dl>

==Description==
If a Hash-Key Record cannot be stored on the page to which its hash-key hashes,
Model 204 will attempt to store that record on the next physical page in that file and is said to have spilled to that page.

HASHSPIL determines the number of times Model 204 will attempt to store a record on a spilled page and therefore, the spill chain length.
Long hash spill chains may affect performance as more records may have to be retrieved before the desired record is located.

[[Category:Parameters]]
[[Category:System parameters]]

HASHSPIL parameter

2025-02-10T18:36:56Z

Ekern: /* Description */

{{Template:HASHSPIL parameter subtitle}}

This page is [[under construction]].
==Summary==
<dl>
<dt>Default value
<dd>? 16
<dt>Parameter type
<dd>System
<dt>Where set
<dd>User 0 parameter line
<dt>Related products
<dd>All
<dt>Introduced
<dd><var class="product">Model 204</var> version 6.1 or earlier
</dl>

==Description==
If a Hash-Key Record cannot be stored on the page to which its hash-key hashes,
Model 204 will attempt to store that record on the next physical page in that file and is said to have spilled to that page.
HASHSPIL determines the number of times Model 204 will attempt to store a record on a spilled page and therefore, the spill chain length.
Long hash spill chains may affect performance as more records may have to be retrieved before the desired record is located.

[[Category:Parameters]]
[[Category:System parameters]]

HASHSPIL parameter

2025-02-10T18:36:45Z

Ekern: /* Summary */

RESTORE command

2025-01-31T23:44:38Z

Ekern: /* Syntax */

==Summary==
<dl>
<dt>Privileges
<dd>File manager plus ad hoc updates
<dt>Function
<dd>Restores a <var class="product">Model 204</var> file from a dumped version of that file
</dl>

==Syntax==
RESTORE [option] FROM ddname [NBUFF I/Obuffers]


Where:
<table>
<tr>
<th>option</th>
<td>A decimal value. Options can be summed. The options are:
<table>

<tr class="head"> <th>Option</th>
<th>Meaning</th> </tr>

<tr> <th align="right"><var>128</var></th>
<td>The size of a file data set or the number of data sets in a file is being changed. </td> </tr>

<tr> <th align="right"><var>64</var></th>
<td>The name of a file is being changed.</td> </tr>
</table>
</td></tr>

<tr>
<th>ddname</th>
<td>The name of the data set from which the <var class="product">Model 204</var> file is being restored. If the <code>FROM ddname</code> clause points to a data set that was not created by the <var class="product">Model 204</var> <var>DUMP</var> command, the following error messages is issued:
M204.2711: <var class="term">ddname</var> IS NOT A DUMP DATASET, CANNOT RESTORE INTO <var class="term">ddname2</var>
</td>
</tr>
<tr>
<th>NBUFF</th>
<td>
NBUFF set the number of sequential I/O buffers for BACKUP or RESTORE. Code the NBUFF keyword after the DUMP or RESTORE command. For example:
RESTORE 192 FROM TESTFILE NBUFF 50
Each buffer is equal in size to the blocksize of the sequential dataset. Thus, if NBUFF is 20, and the sequential dataset blocksize is 30920 bytes, 618,400 bytes of storage will be needed for the sequential I/O buffers. NBUFF can be set to any number between 1 and 99 inclusive.
pagesize * 180 / blocksize
</td>
</tr>
<tr>
<th>I/Obuffers</th>
<td>
Optionally sets the number of sequential I/O buffers RESTORE can use. For example:
RESTORE 192 FROM TESTFILE NBUFF 50
Each buffer is equal in size to the blocksize of the sequential dataset. Thus, if NBUFF is 20, and the sequential dataset blocksize is 30920 bytes, 618,400 bytes of storage will be needed for the sequential I/O buffers. NBUFF can be set to any number between 1 and 99 inclusive.
</td>
</tr>
</table>

==Example==
OPEN CEN
M204.0620: FILE CEN OPENED
M204.1203: FILE CEN WAS LAST UPDATED ON hh:mm:ss
RESTORE 192 FROM DUMPCEN 
M204.0500: FILE CEN: RESTORING FROM DUMP OF 88.262 SEP 19 14.24.29
M204.1760: FILE CEN: RESTORE BEGINNING AT 14.29.06
M204.1761: FILE CEN: RESTORE COMPLETED AT 14.29.24


==Usage notes==
<ul>
<li>The <var>RESTORE</var> command restores a <var class="product">Model 204</var> file from a dumped version of that file. <var>RESTORE</var> takes a sequential data set produced by a <var>[[DUMP command|DUMP]]</var> command and turns it into a <var class="product">Model 204</var> file again.
Note: Before using the <var>RESTORE</var> (or <var>[[REGENERATE command|REGENERATE]]</var>) command, you need to have <var>DUMP</var> copies of the files. <var>DUMP</var> processing updates the file while making a backup copy (to a target media). Otherwise, when you do a media recovery using either <var>RESTORE</var> (which does not include journals) or <var>REGENERATE</var> (to include journals), the backup copy does not incorporate all updates, and you cannot detect this.</li>

<li>The <var>RESTORE</var> command can be issued only in file context. (That is, the current default must be a file, not a group.) The file must be opened with file manager privileges and privileges to update with ad hoc requests.</li>

<li>If an external security interface is active, the user ID issuing the command is checked for the proper data set usage authorization. If the authorization check fails, the attempt is logged as a security violation and the command is not executed. Under a security interface, you must have READ privileges to read a file specified by this command. For more information, refer to the [[:Category:Security interfaces|Security interfaces]] pages.</li>

<li>If a file is skewed, the file can only be transferred from one device type to another through the <var class="product">Model 204</var> DUMP/RESTORE facility. File skewing is an obsolete feature.</li>

<li>When <var>RESTORE</var> has finished processing, it automatically closes all private or semi-public files. Public files remain open.</li>

<li>When it processes <var>RESTORE</var>, <var class="product">Model 204</var> ends any [[File integrity and recovery#Update units and transactions|update unit]] in progress and begins a non-backoutable update unit. </li>

<li>After <var class="product">Model 204</var> starts to restore a file, it displays a message showing the date and time the file was dumped. [[File dumping and restoring]] discusses the <var>RESTORE</var> options, along with a full presentation of <var>DUMP</var>, <var>RESTORE</var>, and their use in moving, renaming, and changing the size of files.</li>

<li>Although the <var>DUMP</var> command copies the <code>FILE BROADCAST</code> message with the FPL, the <var>RESTORE</var> command leaves the current <var>[[BROADCAST command: Sending a file message|BROADCAST]]</var> message in the file. For example:</li>
OPEN FPLJUNK
BROADCAST FILE BROADCAST MESSAGE NUMBER ONE
DUMP TO DUMPFPL
OPEN FPLJUNK
BROADCAST FILE BROADCAST MESSAGE NUMBER TWO
RESTORE FROM DUMPFPL
OPEN FPLJUNK
<broadcast message number two> is displayed.
</li>
</ul>

[[Category: File manager commands]]
[[Category:Commands]]

RESTORE command

2025-01-31T23:43:14Z

Ekern: /* Syntax */

==Summary==
<dl>
<dt>Privileges
<dd>File manager plus ad hoc updates
<dt>Function
<dd>Restores a <var class="product">Model 204</var> file from a dumped version of that file
</dl>

==Syntax==
RESTORE [option] FROM ddname [NBUFF I/Obuffers]


Where:
<table>
<tr>
<th>option</th>
<td>A decimal value. Options can be summed. The options are:
<table>

<tr class="head"> <th>Option</th>
<th>Meaning</th> </tr>

<tr> <th align="right"><var>128</var></th>
<td>The size of a file data set or the number of data sets in a file is being changed. </td> </tr>

<tr> <th align="right"><var>64</var></th>
<td>The name of a file is being changed.</td> </tr>
<tr>
<th>NBUFF</th>
<td>
NBUFF set the number of sequential I/O buffers for BACKUP or RESTORE. Code the NBUFF keyword after the DUMP or RESTORE command. For example:
RESTORE 192 FROM TESTFILE NBUFF 50
Each buffer is equal in size to the blocksize of the sequential dataset. Thus, if NBUFF is 20, and the sequential dataset blocksize is 30920 bytes, 618,400 bytes of storage will be needed for the sequential I/O buffers. NBUFF can be set to any number between 1 and 99 inclusive.
pagesize * 180 / blocksize
</td>
</tr>
</table>
</td></tr>

<tr>
<th>ddname</th>
<td>The name of the data set from which the <var class="product">Model 204</var> file is being restored. If the <code>FROM ddname</code> clause points to a data set that was not created by the <var class="product">Model 204</var> <var>DUMP</var> command, the following error messages is issued:
M204.2711: <var class="term">ddname</var> IS NOT A DUMP DATASET, CANNOT RESTORE INTO <var class="term">ddname2</var>
</td>
</tr>
<tr>
<th>I/Obuffers</th>
<td>
Optionally sets the number of sequential I/O buffers RESTORE can use. For example:
RESTORE 192 FROM TESTFILE NBUFF 50
Each buffer is equal in size to the blocksize of the sequential dataset. Thus, if NBUFF is 20, and the sequential dataset blocksize is 30920 bytes, 618,400 bytes of storage will be needed for the sequential I/O buffers. NBUFF can be set to any number between 1 and 99 inclusive.
</td>
</tr>
</table>

==Example==
OPEN CEN
M204.0620: FILE CEN OPENED
M204.1203: FILE CEN WAS LAST UPDATED ON hh:mm:ss
RESTORE 192 FROM DUMPCEN 
M204.0500: FILE CEN: RESTORING FROM DUMP OF 88.262 SEP 19 14.24.29
M204.1760: FILE CEN: RESTORE BEGINNING AT 14.29.06
M204.1761: FILE CEN: RESTORE COMPLETED AT 14.29.24


==Usage notes==
<ul>
<li>The <var>RESTORE</var> command restores a <var class="product">Model 204</var> file from a dumped version of that file. <var>RESTORE</var> takes a sequential data set produced by a <var>[[DUMP command|DUMP]]</var> command and turns it into a <var class="product">Model 204</var> file again.
Note: Before using the <var>RESTORE</var> (or <var>[[REGENERATE command|REGENERATE]]</var>) command, you need to have <var>DUMP</var> copies of the files. <var>DUMP</var> processing updates the file while making a backup copy (to a target media). Otherwise, when you do a media recovery using either <var>RESTORE</var> (which does not include journals) or <var>REGENERATE</var> (to include journals), the backup copy does not incorporate all updates, and you cannot detect this.</li>

<li>The <var>RESTORE</var> command can be issued only in file context. (That is, the current default must be a file, not a group.) The file must be opened with file manager privileges and privileges to update with ad hoc requests.</li>

<li>If an external security interface is active, the user ID issuing the command is checked for the proper data set usage authorization. If the authorization check fails, the attempt is logged as a security violation and the command is not executed. Under a security interface, you must have READ privileges to read a file specified by this command. For more information, refer to the [[:Category:Security interfaces|Security interfaces]] pages.</li>

<li>If a file is skewed, the file can only be transferred from one device type to another through the <var class="product">Model 204</var> DUMP/RESTORE facility. File skewing is an obsolete feature.</li>

<li>When <var>RESTORE</var> has finished processing, it automatically closes all private or semi-public files. Public files remain open.</li>

<li>When it processes <var>RESTORE</var>, <var class="product">Model 204</var> ends any [[File integrity and recovery#Update units and transactions|update unit]] in progress and begins a non-backoutable update unit. </li>

<li>After <var class="product">Model 204</var> starts to restore a file, it displays a message showing the date and time the file was dumped. [[File dumping and restoring]] discusses the <var>RESTORE</var> options, along with a full presentation of <var>DUMP</var>, <var>RESTORE</var>, and their use in moving, renaming, and changing the size of files.</li>

<li>Although the <var>DUMP</var> command copies the <code>FILE BROADCAST</code> message with the FPL, the <var>RESTORE</var> command leaves the current <var>[[BROADCAST command: Sending a file message|BROADCAST]]</var> message in the file. For example:</li>
OPEN FPLJUNK
BROADCAST FILE BROADCAST MESSAGE NUMBER ONE
DUMP TO DUMPFPL
OPEN FPLJUNK
BROADCAST FILE BROADCAST MESSAGE NUMBER TWO
RESTORE FROM DUMPFPL
OPEN FPLJUNK
<broadcast message number two> is displayed.
</li>
</ul>

[[Category: File manager commands]]
[[Category:Commands]]

DUMP command

2025-01-31T23:42:56Z

Ekern: /* Syntax */

==Summary==
<dl>
<dt>Privileges
<dd>File manager
<dt>Function
<dd>Backs up a <var class="product">Model 204</var> file to a sequential data set
</dl>

==Syntax==
DUMP TO ddname [NBUFF I/Obuffers]


Where
<table>
<tr>
<th>ddname</th>
<td>Is the name of the sequential dataset to which the file is written.</td>
</tr>
<tr>
<th>I/Obuffers</th>
<td>
Optionally sets the number of sequential I/O buffers DUMP can use. For example:
DUMP TO TESTFILE NBUFF 50
Each buffer is equal in size to the blocksize of the sequential dataset. Thus, if NBUFF is 20, and the sequential dataset blocksize is 30920 bytes, 618,400 bytes of storage will be needed for the sequential I/O buffers. NBUFF can be set to any number between 1 and 99 inclusive.
</td>
</tr>
<tr>
<th>NBUFF</th>
<td>
NBUFF set the number of sequential I/O buffers for BACKUP or RESTORE. Code the NBUFF keyword after the DUMP or RESTORE command. For example:
RESTORE 192 FROM TESTFILE NBUFF 50
Each buffer is equal in size to the blocksize of the sequential dataset. Thus, if NBUFF is 20, and the sequential dataset blocksize is 30920 bytes, 618,400 bytes of storage will be needed for the sequential I/O buffers. NBUFF can be set to any number between 1 and 99 inclusive.
pagesize * 180 / blocksize
</td>
</tr>
</table>

===Syntax notes===
<var>DUMP</var> must be issued in file context (that is, the current default must be a file, not a group).

==Example==
OPEN PEOPLE
M204.0620: FILE PEOPLE OPENED
M204.1203: FILE PEOPLE WAS LAST UPDATED ON hh:mm:ss
DUMP TO DUMPPEOP
M204.1760: FILE PEOPLE: DUMP BEGINNING AT hh:mm:ss
M204.1761: FILE PEOPLE: DUMP COMPLETED AT hh:mm:ss
CLOSE PEOPLE


==Usage notes==
The <var>DUMP</var> command copies an open <var class="product">Model 204</var> file to a sequential data set that is located on either a magnetic tape or a direct access device. <var>DUMP</var> backs up a file so that the dumped version is available in case of a system or media failure. The dumped version can subsequently be restored using either the <var>[[RESTORE command|RESTORE]]</var> command or the <var>[[REGENERATE command|REGENERATE]]</var> command.
Note: Use the DUMP command before using either the REGENERATE or the RESTORE command. DUMP updates the file while making a backup copy (to a target media). Otherwise, when you do a media recovery using either REGENERATE (to include journals) or RESTORE (without journals), the backup copy does not incorporate all updates, but you cannot detect this.

If a file is skewed, the file can be transferred from one device type to another only through the <var class="product">Model 204</var> DUMP/RESTORE facility. File skewing is an obsolete feature.

Dump files can be accessed and updated during execution of the <var>DUMP</var> command. After the <var>DUMP</var> command has been issued, the <var>DUMP</var> waits until all existing transactions that might update the file are complete and the existing copy of the file is in a consistent state. At that point the <var>DUMP</var> begins. If a subsequent user request updates the file being dumped, preimages of database pages to be updated are dumped before the update is allowed. The dumped copy matches the state of the file at the time the <var>DUMP</var> begins.

If updates are not complete when the <var>DUMP</var> command for a file is issued, you receive a message that the file is still in use. The DUMP can be canceled at this juncture. If errors are detected during the file dump, the dump is ended. A message to this effect is displayed.

Job level enqueuing is not affected by this facility. A BATCH204 job cannot be started to dump files that are being updated in another <var class="product">Model 204</var> job. Use of the <var>DUMP</var> command from any <var class="product">Model 204</var> job requires exclusive access to the file by that copy of <var class="product">Model 204</var>.

If an external security interface is active, the user ID issuing the command is checked for the proper data set usage authorization. If the authorization check fails, the attempt is logged as a security violation and the command is not executed. 

With a security interface, you must have <var>WRITE</var>, <var>ALTER</var>, or <var>UPDATE</var> privileges to use the DUMP command with sequential data sets. For more information, refer to the [[:Category:Security interfaces|Security interfaces]] pages. 

When it processes <var>DUMP</var>, <var class="product">Model 204</var> ends any [[File integrity and recovery#Update units and transactions|update unit]] in progress and begins a non-backoutable update unit. 

The <var>DUMP</var>, <var>RESTORE</var>, and <var>REGENERATE</var> commands and their use in dumping, restoring, and regenerating files are explained in [[File dumping and restoring]] and [[Media recovery]].

[[Category: File manager commands]]
[[Category:Commands]]

DUMP command

2025-01-31T23:41:48Z

Ekern: /* Syntax */

==Summary==
<dl>
<dt>Privileges
<dd>File manager
<dt>Function
<dd>Backs up a <var class="product">Model 204</var> file to a sequential data set
</dl>

==Syntax==
DUMP TO ddname [NBUFF I/Obuffers]


Where
<table>
<tr>
<th>ddname</th>
<td>Is the name of the sequential dataset to which the file is written.</td>
</tr>
<tr>
<th>I/Obuffers</th>
<td>
Optionally sets the number of sequential I/O buffers DUMP can use. For example:
DUMP TO TESTFILE NBUFF 50
Each buffer is equal in size to the blocksize of the sequential dataset. Thus, if NBUFF is 20, and the sequential dataset blocksize is 30920 bytes, 618,400 bytes of storage will be needed for the sequential I/O buffers. NBUFF can be set to any number between 1 and 99 inclusive.
</td>
</tr>
<tr>
<th>NBUFF</th>
NBUFF set the number of sequential I/O buffers for BACKUP or RESTORE. Code the NBUFF keyword after the DUMP or RESTORE command. For example:
RESTORE 192 FROM TESTFILE NBUFF 50
Each buffer is equal in size to the blocksize of the sequential dataset. Thus, if NBUFF is 20, and the sequential dataset blocksize is 30920 bytes, 618,400 bytes of storage will be needed for the sequential I/O buffers. NBUFF can be set to any number between 1 and 99 inclusive.
pagesize * 180 / blocksize
</tr>
</table>

===Syntax notes===
<var>DUMP</var> must be issued in file context (that is, the current default must be a file, not a group).

==Example==
OPEN PEOPLE
M204.0620: FILE PEOPLE OPENED
M204.1203: FILE PEOPLE WAS LAST UPDATED ON hh:mm:ss
DUMP TO DUMPPEOP
M204.1760: FILE PEOPLE: DUMP BEGINNING AT hh:mm:ss
M204.1761: FILE PEOPLE: DUMP COMPLETED AT hh:mm:ss
CLOSE PEOPLE


==Usage notes==
The <var>DUMP</var> command copies an open <var class="product">Model 204</var> file to a sequential data set that is located on either a magnetic tape or a direct access device. <var>DUMP</var> backs up a file so that the dumped version is available in case of a system or media failure. The dumped version can subsequently be restored using either the <var>[[RESTORE command|RESTORE]]</var> command or the <var>[[REGENERATE command|REGENERATE]]</var> command.
Note: Use the DUMP command before using either the REGENERATE or the RESTORE command. DUMP updates the file while making a backup copy (to a target media). Otherwise, when you do a media recovery using either REGENERATE (to include journals) or RESTORE (without journals), the backup copy does not incorporate all updates, but you cannot detect this.

If a file is skewed, the file can be transferred from one device type to another only through the <var class="product">Model 204</var> DUMP/RESTORE facility. File skewing is an obsolete feature.

Dump files can be accessed and updated during execution of the <var>DUMP</var> command. After the <var>DUMP</var> command has been issued, the <var>DUMP</var> waits until all existing transactions that might update the file are complete and the existing copy of the file is in a consistent state. At that point the <var>DUMP</var> begins. If a subsequent user request updates the file being dumped, preimages of database pages to be updated are dumped before the update is allowed. The dumped copy matches the state of the file at the time the <var>DUMP</var> begins.

If updates are not complete when the <var>DUMP</var> command for a file is issued, you receive a message that the file is still in use. The DUMP can be canceled at this juncture. If errors are detected during the file dump, the dump is ended. A message to this effect is displayed.

Job level enqueuing is not affected by this facility. A BATCH204 job cannot be started to dump files that are being updated in another <var class="product">Model 204</var> job. Use of the <var>DUMP</var> command from any <var class="product">Model 204</var> job requires exclusive access to the file by that copy of <var class="product">Model 204</var>.

If an external security interface is active, the user ID issuing the command is checked for the proper data set usage authorization. If the authorization check fails, the attempt is logged as a security violation and the command is not executed. 

With a security interface, you must have <var>WRITE</var>, <var>ALTER</var>, or <var>UPDATE</var> privileges to use the DUMP command with sequential data sets. For more information, refer to the [[:Category:Security interfaces|Security interfaces]] pages. 

When it processes <var>DUMP</var>, <var class="product">Model 204</var> ends any [[File integrity and recovery#Update units and transactions|update unit]] in progress and begins a non-backoutable update unit. 

The <var>DUMP</var>, <var>RESTORE</var>, and <var>REGENERATE</var> commands and their use in dumping, restoring, and regenerating files are explained in [[File dumping and restoring]] and [[Media recovery]].

[[Category: File manager commands]]
[[Category:Commands]]

REGENERATE command

2025-01-31T23:28:30Z

Ekern: /* The USING option */

==Summary==
<dl>
<dt>Privileges
<dd>User 0
<dt>Function
<dd>In the event of a media failure, for example, a disk head crash, a REGENERATE command recovers a <var class="product">Model 204</var> file by reapplying some or all of the updates that have been made to the file since the time of the last dump.
</dl>
==Syntax==
REGENERATE [USING ddname] FILE filename [FROM dumpname | IGNORE]
[TO {LAST UPDATE [BEFORE yy.ddd hh:mm:ss.th]
| LAST CHECKPOINT [BEFORE yy.dd hh:mm:ss.th]
| UPDATE number OF yy.ddd hh:mm:ss.th
| CHECKPOINT yy.ddd hh:mm:ss.th}]

For more than one file, specify REGENERATE only once; the remaining syntax is repeated for each file.

Where:
<ul>
<li>
<var class="term">ddname</var> allows an alternate ddname to be used for the input journal to be used by REGENERATE. It is one to eight characters long and defaults to CCAGEN if not specified
</li>

<li>
<var class="term">filename</var> is the name of a <var class="product">Model 204</var> file that is one to eight characters long.
</li>

<li>
A FROM clause determines whether or not REGENERATE processing performs a restore: 
<ul>
<li>
If a FROM clause is present for a file, REGENERATE processing restores that file from the <var class="product">Model 204</var> dump specified in the clause.
</li>

<li>
If a FROM clause is not present for a file, REGENERATE processing assumes that the file was previously restored. 
</li>
</ul>
</li>

<li>
<var class="term">dumpname</var> is the ddname of the dumped file, one to eight characters long, from which to recover.
</li>

<li>
<var>IGNORE</var> lets REGENERATE processing bypass the file parameter list (FPL) update timestamps, so you can run REGEN processing with one CCAGEN at a time, instead of requiring you to concatenate the CCAGEN files.
</li>

<li>
The TO clause options listed in the table below identify the stopping point:
<table>

<tr class="head"> <th>
Option
</th> <th>
Applies updates to the file up to...
</th> </tr>

<tr> <th><var>LAST UPDATE</var></th> <td>All. This is the default. </td> </tr>

<tr> <th><var>LAST CHECKPOINT</var></th>
<td>Last checkpoint on the input journal.
</td> </tr>

<tr> <th nowrap><var>UPDATE number OF id</var></th> <td>And including the update specified by number and id. The ID is the date/time stamp from the END OF UPDATE message, specified in the form: yy.ddd hh:mm:ss.th.</td> </tr>

<tr> <th><var>CHECKPOINT id</var></th>
<td>Specified checkpoint. The ID is specified in the form: yy.ddd hh:mm:ss.th. </td> </tr>
</table>
</li>

<li>
A BEFORE clause specifies a nonspecific stopping point. The BEFORE clause is an alternative to specifying an exact checkpoint ID or update unit number and ending date and time from an audit trail.
If you specify a BEFORE clause, Pass One of REGENERATE processing determines the last complete update or checkpoint before the time specified. Pass Two of REGENERATE processing stops reapplying file updates when it reaches the stopping point identified in Pass One. 
</li>
</ul>
===Syntax notes===
When multiple files are regenerated, each file must be specified on a separate line. The line can begin in any column. The END keyword indicates the end of the list of files.

==Examples==
REGENERATE FILE DB1 FROM DUMPDB1
REGEN FILE DB1 FROM DUMPDB1 TO LAST UPDATE
REGEN FILE DBAUDIT FROM DUMP01 TO LAST -
CHECKPOINT
REGEN FILE DB1 FROM DUMPDB2 TO UPDATE 3 -
OF 88.216 06:28:42.98
REGEN FILE MODFILE FROM DUMPMOD TO -
CHECKPOINT 88.216 01:05:22.99
REGEN
FILE DB1 FROM DUMPDB1 TO LAST CHECKPOINT
FILE DB2 FROM DUMPDB2
FILE DB3 FROM DUMPDB3 TO UPDATE 5 OF -
88.008 05:19:41.27
END

Note: Blank lines are not valid between the REGENERATE and END command.
REGEN FILE ABC FROM DUMPABC /* First run */
.
.
REGEN FILE ABC IGNORE /* A later run */


==Usage notes==
The REGENERATE command lets the system manager use the <var class="product">Model 204</var> media recovery feature to regenerate one or more files. A REGENERATE command is issued in case of a loss of storage integrity caused by a hard system error such as a disk head crash.
The algorithm for identifying starting points, used whether or not a FROM clause is present, is to find the first start of an update unit with a time greater than the last updated time of the file being processed. 
If REGENERATE processing opens a file for which it is not performing a restore, and if that file is marked physically inconsistent, REGENERATE processing for that file is discontinued.
When it processes REGENERATE, <var class="product">Model 204</var> ends any update unit in progress and begins a no-back out-allowed update unit. For more information about <var class="product">Model 204</var> update units, see [[File_integrity_and_recovery#Update_units_and_transactions|Update units and transactions]].
For a single-user (batch) <var class="product">Model 204</var> run, specify a REGENERATE command on User 0's command line. REGENERATE need not be the first command issued. You can intermix User Language procedures and other batch functions with REGENERATE commands.
====Using the IGNORE option====
For example, providing the first journal the first REGEN command might be
REGEN FILE ABC FROM DUMPABC

A second run may provide the second journal and specify: 
REGEN FILE ABC IGNORE

The second run begins where the previous REGEN processing ended and applies the second journal updates.
Note: If you omit a journal, <var class="product">Model 204</var> does not report this to you. Therefore, use the IGNORE option with care.
====Using the TO UPDATE option====
You can specify the TO UPDATE option for a single or multiple file run.
If TO UPDATE <var class="term">nn</var> OF <var class="term">id</var> is specified, it must appear only on the first FILE statement, and no other ‘TO’ options are allowed on subsequent files.
(In Model 204 version 7.6, the new message: <code>M204:1664 "TO UPDATE" only allowed on first line of REGENerate</code> appears any time more than one TO UPDATE is specified, or if TO UPDATE is specified on a line other than the first.)
All additional files are recovered as though they each specified the same 'TO UPDATE' option. The <var class="term">id</var>' timestamp is the END OF TRANSACTION timestamp. Once the 'end of transaction' is reached, further processing stops, all inflight transactions are backed out, and RC=0 is set.

If the update is not found in the journal, then the run stops immediately after pass 1. RC=4 is set. This message is displayed for each file: 
M204.1409: MISSING STOPPING POINT FOR FILE <var class="term">filename</var>
And this message is also displayed:
M204.1435: Error during regenerate

==== The USING option====
Allows for user to specify ddname for input journal stream to be used by REGENERATE command. This is a new addition as of <var>[[https://m204wiki.rocketsoftware.com/index.php?title=Release_notes_for_Model_204_version_7.8#Recovery_enhancements:M204 v7.8]]</var>

====Using REGENERATE with multiple files====
The number of files you can regenerate in a single run depends upon the settings of these parameters: [[NDIR parameter|NDIR]] (number of directory entries) and [[NFILES parameter|NFILES]] (number of file areas).

[[Category:Commands]]

REGENERATE command

2025-01-31T23:25:53Z

Ekern: /* The USING option */

==Summary==
<dl>
<dt>Privileges
<dd>User 0
<dt>Function
<dd>In the event of a media failure, for example, a disk head crash, a REGENERATE command recovers a <var class="product">Model 204</var> file by reapplying some or all of the updates that have been made to the file since the time of the last dump.
</dl>
==Syntax==
REGENERATE [USING ddname] FILE filename [FROM dumpname | IGNORE]
[TO {LAST UPDATE [BEFORE yy.ddd hh:mm:ss.th]
| LAST CHECKPOINT [BEFORE yy.dd hh:mm:ss.th]
| UPDATE number OF yy.ddd hh:mm:ss.th
| CHECKPOINT yy.ddd hh:mm:ss.th}]

For more than one file, specify REGENERATE only once; the remaining syntax is repeated for each file.

Where:
<ul>
<li>
<var class="term">ddname</var> allows an alternate ddname to be used for the input journal to be used by REGENERATE. It is one to eight characters long and defaults to CCAGEN if not specified
</li>

<li>
<var class="term">filename</var> is the name of a <var class="product">Model 204</var> file that is one to eight characters long.
</li>

<li>
A FROM clause determines whether or not REGENERATE processing performs a restore: 
<ul>
<li>
If a FROM clause is present for a file, REGENERATE processing restores that file from the <var class="product">Model 204</var> dump specified in the clause.
</li>

<li>
If a FROM clause is not present for a file, REGENERATE processing assumes that the file was previously restored. 
</li>
</ul>
</li>

<li>
<var class="term">dumpname</var> is the ddname of the dumped file, one to eight characters long, from which to recover.
</li>

<li>
<var>IGNORE</var> lets REGENERATE processing bypass the file parameter list (FPL) update timestamps, so you can run REGEN processing with one CCAGEN at a time, instead of requiring you to concatenate the CCAGEN files.
</li>

<li>
The TO clause options listed in the table below identify the stopping point:
<table>

<tr class="head"> <th>
Option
</th> <th>
Applies updates to the file up to...
</th> </tr>

<tr> <th><var>LAST UPDATE</var></th> <td>All. This is the default. </td> </tr>

<tr> <th><var>LAST CHECKPOINT</var></th>
<td>Last checkpoint on the input journal.
</td> </tr>

<tr> <th nowrap><var>UPDATE number OF id</var></th> <td>And including the update specified by number and id. The ID is the date/time stamp from the END OF UPDATE message, specified in the form: yy.ddd hh:mm:ss.th.</td> </tr>

<tr> <th><var>CHECKPOINT id</var></th>
<td>Specified checkpoint. The ID is specified in the form: yy.ddd hh:mm:ss.th. </td> </tr>
</table>
</li>

<li>
A BEFORE clause specifies a nonspecific stopping point. The BEFORE clause is an alternative to specifying an exact checkpoint ID or update unit number and ending date and time from an audit trail.
If you specify a BEFORE clause, Pass One of REGENERATE processing determines the last complete update or checkpoint before the time specified. Pass Two of REGENERATE processing stops reapplying file updates when it reaches the stopping point identified in Pass One. 
</li>
</ul>
===Syntax notes===
When multiple files are regenerated, each file must be specified on a separate line. The line can begin in any column. The END keyword indicates the end of the list of files.

==Examples==
REGENERATE FILE DB1 FROM DUMPDB1
REGEN FILE DB1 FROM DUMPDB1 TO LAST UPDATE
REGEN FILE DBAUDIT FROM DUMP01 TO LAST -
CHECKPOINT
REGEN FILE DB1 FROM DUMPDB2 TO UPDATE 3 -
OF 88.216 06:28:42.98
REGEN FILE MODFILE FROM DUMPMOD TO -
CHECKPOINT 88.216 01:05:22.99
REGEN
FILE DB1 FROM DUMPDB1 TO LAST CHECKPOINT
FILE DB2 FROM DUMPDB2
FILE DB3 FROM DUMPDB3 TO UPDATE 5 OF -
88.008 05:19:41.27
END

Note: Blank lines are not valid between the REGENERATE and END command.
REGEN FILE ABC FROM DUMPABC /* First run */
.
.
REGEN FILE ABC IGNORE /* A later run */


==Usage notes==
The REGENERATE command lets the system manager use the <var class="product">Model 204</var> media recovery feature to regenerate one or more files. A REGENERATE command is issued in case of a loss of storage integrity caused by a hard system error such as a disk head crash.
The algorithm for identifying starting points, used whether or not a FROM clause is present, is to find the first start of an update unit with a time greater than the last updated time of the file being processed. 
If REGENERATE processing opens a file for which it is not performing a restore, and if that file is marked physically inconsistent, REGENERATE processing for that file is discontinued.
When it processes REGENERATE, <var class="product">Model 204</var> ends any update unit in progress and begins a no-back out-allowed update unit. For more information about <var class="product">Model 204</var> update units, see [[File_integrity_and_recovery#Update_units_and_transactions|Update units and transactions]].
For a single-user (batch) <var class="product">Model 204</var> run, specify a REGENERATE command on User 0's command line. REGENERATE need not be the first command issued. You can intermix User Language procedures and other batch functions with REGENERATE commands.
====Using the IGNORE option====
For example, providing the first journal the first REGEN command might be
REGEN FILE ABC FROM DUMPABC

A second run may provide the second journal and specify: 
REGEN FILE ABC IGNORE

The second run begins where the previous REGEN processing ended and applies the second journal updates.
Note: If you omit a journal, <var class="product">Model 204</var> does not report this to you. Therefore, use the IGNORE option with care.
====Using the TO UPDATE option====
You can specify the TO UPDATE option for a single or multiple file run.
If TO UPDATE <var class="term">nn</var> OF <var class="term">id</var> is specified, it must appear only on the first FILE statement, and no other ‘TO’ options are allowed on subsequent files.
(In Model 204 version 7.6, the new message: <code>M204:1664 "TO UPDATE" only allowed on first line of REGENerate</code> appears any time more than one TO UPDATE is specified, or if TO UPDATE is specified on a line other than the first.)
All additional files are recovered as though they each specified the same 'TO UPDATE' option. The <var class="term">id</var>' timestamp is the END OF TRANSACTION timestamp. Once the 'end of transaction' is reached, further processing stops, all inflight transactions are backed out, and RC=0 is set.

If the update is not found in the journal, then the run stops immediately after pass 1. RC=4 is set. This message is displayed for each file: 
M204.1409: MISSING STOPPING POINT FOR FILE <var class="term">filename</var>
And this message is also displayed:
M204.1435: Error during regenerate

==== The USING option====
Allows for user to specify ddname for input journal stream to be used by REGENERATE command. This is a new addition as of <var>[[https://m204wiki.rocketsoftware.com/index.php?title=Release_notes_for_Model_204_version_7.8#Media_Recovery_in_a_multi-user_environment:M204 v7.8]]</var>

====Using REGENERATE with multiple files====
The number of files you can regenerate in a single run depends upon the settings of these parameters: [[NDIR parameter|NDIR]] (number of directory entries) and [[NFILES parameter|NFILES]] (number of file areas).

[[Category:Commands]]

REGENERATE command

2025-01-31T01:38:11Z

Ekern: /* The USING option */

==Summary==
<dl>
<dt>Privileges
<dd>User 0
<dt>Function
<dd>In the event of a media failure, for example, a disk head crash, a REGENERATE command recovers a <var class="product">Model 204</var> file by reapplying some or all of the updates that have been made to the file since the time of the last dump.
</dl>
==Syntax==
REGENERATE [USING ddname] FILE filename [FROM dumpname | IGNORE]
[TO {LAST UPDATE [BEFORE yy.ddd hh:mm:ss.th]
| LAST CHECKPOINT [BEFORE yy.dd hh:mm:ss.th]
| UPDATE number OF yy.ddd hh:mm:ss.th
| CHECKPOINT yy.ddd hh:mm:ss.th}]

For more than one file, specify REGENERATE only once; the remaining syntax is repeated for each file.

Where:
<ul>
<li>
<var class="term">ddname</var> allows an alternate ddname to be used for the input journal to be used by REGENERATE. It is one to eight characters long and defaults to CCAGEN if not specified
</li>

<li>
<var class="term">filename</var> is the name of a <var class="product">Model 204</var> file that is one to eight characters long.
</li>

<li>
A FROM clause determines whether or not REGENERATE processing performs a restore: 
<ul>
<li>
If a FROM clause is present for a file, REGENERATE processing restores that file from the <var class="product">Model 204</var> dump specified in the clause.
</li>

<li>
If a FROM clause is not present for a file, REGENERATE processing assumes that the file was previously restored. 
</li>
</ul>
</li>

<li>
<var class="term">dumpname</var> is the ddname of the dumped file, one to eight characters long, from which to recover.
</li>

<li>
<var>IGNORE</var> lets REGENERATE processing bypass the file parameter list (FPL) update timestamps, so you can run REGEN processing with one CCAGEN at a time, instead of requiring you to concatenate the CCAGEN files.
</li>

<li>
The TO clause options listed in the table below identify the stopping point:
<table>

<tr class="head"> <th>
Option
</th> <th>
Applies updates to the file up to...
</th> </tr>

<tr> <th><var>LAST UPDATE</var></th> <td>All. This is the default. </td> </tr>

<tr> <th><var>LAST CHECKPOINT</var></th>
<td>Last checkpoint on the input journal.
</td> </tr>

<tr> <th nowrap><var>UPDATE number OF id</var></th> <td>And including the update specified by number and id. The ID is the date/time stamp from the END OF UPDATE message, specified in the form: yy.ddd hh:mm:ss.th.</td> </tr>

<tr> <th><var>CHECKPOINT id</var></th>
<td>Specified checkpoint. The ID is specified in the form: yy.ddd hh:mm:ss.th. </td> </tr>
</table>
</li>

<li>
A BEFORE clause specifies a nonspecific stopping point. The BEFORE clause is an alternative to specifying an exact checkpoint ID or update unit number and ending date and time from an audit trail.
If you specify a BEFORE clause, Pass One of REGENERATE processing determines the last complete update or checkpoint before the time specified. Pass Two of REGENERATE processing stops reapplying file updates when it reaches the stopping point identified in Pass One. 
</li>
</ul>
===Syntax notes===
When multiple files are regenerated, each file must be specified on a separate line. The line can begin in any column. The END keyword indicates the end of the list of files.

==Examples==
REGENERATE FILE DB1 FROM DUMPDB1
REGEN FILE DB1 FROM DUMPDB1 TO LAST UPDATE
REGEN FILE DBAUDIT FROM DUMP01 TO LAST -
CHECKPOINT
REGEN FILE DB1 FROM DUMPDB2 TO UPDATE 3 -
OF 88.216 06:28:42.98
REGEN FILE MODFILE FROM DUMPMOD TO -
CHECKPOINT 88.216 01:05:22.99
REGEN
FILE DB1 FROM DUMPDB1 TO LAST CHECKPOINT
FILE DB2 FROM DUMPDB2
FILE DB3 FROM DUMPDB3 TO UPDATE 5 OF -
88.008 05:19:41.27
END

Note: Blank lines are not valid between the REGENERATE and END command.
REGEN FILE ABC FROM DUMPABC /* First run */
.
.
REGEN FILE ABC IGNORE /* A later run */


==Usage notes==
The REGENERATE command lets the system manager use the <var class="product">Model 204</var> media recovery feature to regenerate one or more files. A REGENERATE command is issued in case of a loss of storage integrity caused by a hard system error such as a disk head crash.
The algorithm for identifying starting points, used whether or not a FROM clause is present, is to find the first start of an update unit with a time greater than the last updated time of the file being processed. 
If REGENERATE processing opens a file for which it is not performing a restore, and if that file is marked physically inconsistent, REGENERATE processing for that file is discontinued.
When it processes REGENERATE, <var class="product">Model 204</var> ends any update unit in progress and begins a no-back out-allowed update unit. For more information about <var class="product">Model 204</var> update units, see [[File_integrity_and_recovery#Update_units_and_transactions|Update units and transactions]].
For a single-user (batch) <var class="product">Model 204</var> run, specify a REGENERATE command on User 0's command line. REGENERATE need not be the first command issued. You can intermix User Language procedures and other batch functions with REGENERATE commands.
====Using the IGNORE option====
For example, providing the first journal the first REGEN command might be
REGEN FILE ABC FROM DUMPABC

A second run may provide the second journal and specify: 
REGEN FILE ABC IGNORE

The second run begins where the previous REGEN processing ended and applies the second journal updates.
Note: If you omit a journal, <var class="product">Model 204</var> does not report this to you. Therefore, use the IGNORE option with care.
====Using the TO UPDATE option====
You can specify the TO UPDATE option for a single or multiple file run.
If TO UPDATE <var class="term">nn</var> OF <var class="term">id</var> is specified, it must appear only on the first FILE statement, and no other ‘TO’ options are allowed on subsequent files.
(In Model 204 version 7.6, the new message: <code>M204:1664 "TO UPDATE" only allowed on first line of REGENerate</code> appears any time more than one TO UPDATE is specified, or if TO UPDATE is specified on a line other than the first.)
All additional files are recovered as though they each specified the same 'TO UPDATE' option. The <var class="term">id</var>' timestamp is the END OF TRANSACTION timestamp. Once the 'end of transaction' is reached, further processing stops, all inflight transactions are backed out, and RC=0 is set.

If the update is not found in the journal, then the run stops immediately after pass 1. RC=4 is set. This message is displayed for each file: 
M204.1409: MISSING STOPPING POINT FOR FILE <var class="term">filename</var>
And this message is also displayed:
M204.1435: Error during regenerate

==== The USING option====
Allows for user to specify ddname for input journal stream to be used by REGENERATE command. This is a new addition as of <var>[[https://m204wiki.rocketsoftware.com/index.php?title=Release_notes_for_Model_204_version_7.8#Media_Recovery_in_a_multi-user_environment|M204 v7.8]]</var>

====Using REGENERATE with multiple files====
The number of files you can regenerate in a single run depends upon the settings of these parameters: [[NDIR parameter|NDIR]] (number of directory entries) and [[NFILES parameter|NFILES]] (number of file areas).

[[Category:Commands]]

REGENERATE command

2025-01-31T01:28:32Z

Ekern: /* Usage notes */

==Summary==
<dl>
<dt>Privileges
<dd>User 0
<dt>Function
<dd>In the event of a media failure, for example, a disk head crash, a REGENERATE command recovers a <var class="product">Model 204</var> file by reapplying some or all of the updates that have been made to the file since the time of the last dump.
</dl>
==Syntax==
REGENERATE [USING ddname] FILE filename [FROM dumpname | IGNORE]
[TO {LAST UPDATE [BEFORE yy.ddd hh:mm:ss.th]
| LAST CHECKPOINT [BEFORE yy.dd hh:mm:ss.th]
| UPDATE number OF yy.ddd hh:mm:ss.th
| CHECKPOINT yy.ddd hh:mm:ss.th}]

For more than one file, specify REGENERATE only once; the remaining syntax is repeated for each file.

Where:
<ul>
<li>
<var class="term">ddname</var> allows an alternate ddname to be used for the input journal to be used by REGENERATE. It is one to eight characters long and defaults to CCAGEN if not specified
</li>

<li>
<var class="term">filename</var> is the name of a <var class="product">Model 204</var> file that is one to eight characters long.
</li>

<li>
A FROM clause determines whether or not REGENERATE processing performs a restore: 
<ul>
<li>
If a FROM clause is present for a file, REGENERATE processing restores that file from the <var class="product">Model 204</var> dump specified in the clause.
</li>

<li>
If a FROM clause is not present for a file, REGENERATE processing assumes that the file was previously restored. 
</li>
</ul>
</li>

<li>
<var class="term">dumpname</var> is the ddname of the dumped file, one to eight characters long, from which to recover.
</li>

<li>
<var>IGNORE</var> lets REGENERATE processing bypass the file parameter list (FPL) update timestamps, so you can run REGEN processing with one CCAGEN at a time, instead of requiring you to concatenate the CCAGEN files.
</li>

<li>
The TO clause options listed in the table below identify the stopping point:
<table>

<tr class="head"> <th>
Option
</th> <th>
Applies updates to the file up to...
</th> </tr>

<tr> <th><var>LAST UPDATE</var></th> <td>All. This is the default. </td> </tr>

<tr> <th><var>LAST CHECKPOINT</var></th>
<td>Last checkpoint on the input journal.
</td> </tr>

<tr> <th nowrap><var>UPDATE number OF id</var></th> <td>And including the update specified by number and id. The ID is the date/time stamp from the END OF UPDATE message, specified in the form: yy.ddd hh:mm:ss.th.</td> </tr>

<tr> <th><var>CHECKPOINT id</var></th>
<td>Specified checkpoint. The ID is specified in the form: yy.ddd hh:mm:ss.th. </td> </tr>
</table>
</li>

<li>
A BEFORE clause specifies a nonspecific stopping point. The BEFORE clause is an alternative to specifying an exact checkpoint ID or update unit number and ending date and time from an audit trail.
If you specify a BEFORE clause, Pass One of REGENERATE processing determines the last complete update or checkpoint before the time specified. Pass Two of REGENERATE processing stops reapplying file updates when it reaches the stopping point identified in Pass One. 
</li>
</ul>
===Syntax notes===
When multiple files are regenerated, each file must be specified on a separate line. The line can begin in any column. The END keyword indicates the end of the list of files.

==Examples==
REGENERATE FILE DB1 FROM DUMPDB1
REGEN FILE DB1 FROM DUMPDB1 TO LAST UPDATE
REGEN FILE DBAUDIT FROM DUMP01 TO LAST -
CHECKPOINT
REGEN FILE DB1 FROM DUMPDB2 TO UPDATE 3 -
OF 88.216 06:28:42.98
REGEN FILE MODFILE FROM DUMPMOD TO -
CHECKPOINT 88.216 01:05:22.99
REGEN
FILE DB1 FROM DUMPDB1 TO LAST CHECKPOINT
FILE DB2 FROM DUMPDB2
FILE DB3 FROM DUMPDB3 TO UPDATE 5 OF -
88.008 05:19:41.27
END

Note: Blank lines are not valid between the REGENERATE and END command.
REGEN FILE ABC FROM DUMPABC /* First run */
.
.
REGEN FILE ABC IGNORE /* A later run */


==Usage notes==
The REGENERATE command lets the system manager use the <var class="product">Model 204</var> media recovery feature to regenerate one or more files. A REGENERATE command is issued in case of a loss of storage integrity caused by a hard system error such as a disk head crash.
The algorithm for identifying starting points, used whether or not a FROM clause is present, is to find the first start of an update unit with a time greater than the last updated time of the file being processed. 
If REGENERATE processing opens a file for which it is not performing a restore, and if that file is marked physically inconsistent, REGENERATE processing for that file is discontinued.
When it processes REGENERATE, <var class="product">Model 204</var> ends any update unit in progress and begins a no-back out-allowed update unit. For more information about <var class="product">Model 204</var> update units, see [[File_integrity_and_recovery#Update_units_and_transactions|Update units and transactions]].
For a single-user (batch) <var class="product">Model 204</var> run, specify a REGENERATE command on User 0's command line. REGENERATE need not be the first command issued. You can intermix User Language procedures and other batch functions with REGENERATE commands.
====Using the IGNORE option====
For example, providing the first journal the first REGEN command might be
REGEN FILE ABC FROM DUMPABC

A second run may provide the second journal and specify: 
REGEN FILE ABC IGNORE

The second run begins where the previous REGEN processing ended and applies the second journal updates.
Note: If you omit a journal, <var class="product">Model 204</var> does not report this to you. Therefore, use the IGNORE option with care.
====Using the TO UPDATE option====
You can specify the TO UPDATE option for a single or multiple file run.
If TO UPDATE <var class="term">nn</var> OF <var class="term">id</var> is specified, it must appear only on the first FILE statement, and no other ‘TO’ options are allowed on subsequent files.
(In Model 204 version 7.6, the new message: <code>M204:1664 "TO UPDATE" only allowed on first line of REGENerate</code> appears any time more than one TO UPDATE is specified, or if TO UPDATE is specified on a line other than the first.)
All additional files are recovered as though they each specified the same 'TO UPDATE' option. The <var class="term">id</var>' timestamp is the END OF TRANSACTION timestamp. Once the 'end of transaction' is reached, further processing stops, all inflight transactions are backed out, and RC=0 is set.

If the update is not found in the journal, then the run stops immediately after pass 1. RC=4 is set. This message is displayed for each file: 
M204.1409: MISSING STOPPING POINT FOR FILE <var class="term">filename</var>
And this message is also displayed:
M204.1435: Error during regenerate

==== The USING option====
Allows for user to specify ddname for input journal stream to be used by REGENERATE command. This is a new addition as of <var>M204 v7.8</var>

====Using REGENERATE with multiple files====
The number of files you can regenerate in a single run depends upon the settings of these parameters: [[NDIR parameter|NDIR]] (number of directory entries) and [[NFILES parameter|NFILES]] (number of file areas).

[[Category:Commands]]