$STATUS after CONVERT or ANAL/RMS/CHECK

[Art Wiens]

Do I need to be any more specific after a CONVERT or ANAL/RMS/CHECK other than:

IF .NOT. $STATUS THEN GOTO something_bad_happened

Are there different "levels of success" after CONVERTing or ANALYZEing a file that I really should check?

I'm writing a DCL procedure to do some file reorgs.

Thanks,
Art

[John Gillings · Accepted solution]

Art,

If all you care about is "definitely good" or "maybe not good" then "IF .NOT.$STATUS" will do the trick. If you want to go into more detail, replace it with:

$ command-you-care-about
$ status=$STATUS
$ IF .NOT.status
$ THEN
$ look at variable status for more detail
$ ENDIF

In the former, The "IF THEN GOTO" command will change the value of $STATUS when you get to "something_bad_happened". If you've saved $STATUS in your own symbol, you can go into more detail.

>Are there different "levels of success"
>after CONVERTing or ANALYZEing a file
>that I really should check?

Potentially, yes.

A success status can be severity "I" (Informational) or "S" (Success). Generally you don't care which.

A failing status can be "W" (Warning), "E" (Error) or "F" (Fatal). It's entirely possible that a CONVERT that returned a "W" status actually "worked".

To determine the severity, examine the low 3 bits of the status value:

$ severity=status.AND.%X07

Severity values are:
0 Indicates a warning. This code is used whenever a procedure produces output, but the output produced might not be what the user expected (for example, a compiler modification of a source program).
1 Indicates that the procedure generating the condition value completed successfully, as expected.
2 Indicates that an error has occurred but the procedure did produce output. Execution can continue, but the results produced by the component generating the condition value are not all correct.
3 Indicates that the procedure generating the condition value completed successfully but has some parenthetical information to be included in a message if the condition is signaled.
4 Indicates that a severe error occurred and the component generating the condition value was unable to produce output.


Exactly how you deal with the different severities depends on what you're doing...

See section 18.11 in HP OpenVMS Programming Concepts Manual and Chapter 8 in HP OpenVMS Calling Standard

http://h71000.www7.hp.com/doc/82FINAL/5841/5841pro_055.html#errorsfrom_routine_sec

http://h71000.www7.hp.com/doc/82final/5973/5973pro_022.html#index_x_626

for full details of condition values

[Art Wiens]

Sorry for the delay on points assignment and thanks for the reply!

Thanks,
Art

[Hein van den Heuvel]

Ah, I kinda missed this topic. Some thoughts:

- Excellent plan to have a procedure to reorg and tuneup files!

Now let's assume you can only do so while the application is down and that downtime is at a premium.

- Skip (postpone) the Analyze!
What do you do if the analyze spots a problem? Well, you start convert, and hope for the best right? So why not just convert right away?
= Perhaps you wanted to do an automatic tuneup with EDIT/FDL/NOINTER and needed input for that? Well, the real input for that is the file layout, and that did not change, then average record size which probably did not change, the cluster size and record count.
= ust take an old FDL file, tweak the cluster size and record count as desired and go!
# For the cluster size I actually recommend a white lie. IMHO the edit/fdl algoritmes do more harm than good. Just pick a non-prime number with a few actors like 6, 10, 12, 15, or 30.
# For the record count, just use the /STAT output from the last convert and adjust for the business.

- when doing the convert, leave the old file behind for a while:
= you can skip the backup for that day, saving down time.
= you can use the old file to make a backup from if need be in outsode the down window.
= you can run the anal/rms on the old file outside the down window, to make sure no silent corruption appeared.
= you migth be able to use it as a file to run heacy queries against.

- Be sure to add /STAT to the convert.
= as a sanity check
= as input record count to the next reorg
= to collect permanently in a file to allow you to know how much records your critical files have and how that does, or does not change over time.

Hope this helps some,
Regards,
Hein.

[Jan van den Ende]

Like Hein, I missed it. :-(

@John,


To determine the severity, examine the low 3 bits of the status value:

$ severity=status.AND.%X07


You surprise me quite often with unknown and unsuspected magic, but now, for the use of this detour, because:

DCL defines (for as long as I can remember) the local symbol $SEVERITY
with that value!

Proost.

Have one on me.

jpe

[Art Wiens]

Hein it's the other way around. I wanted to do the CONVERT ... check it's status and then just to be sure do an ANALYZE and check it's status too. If both say it's ok, it's probably ok ;-) Is the ANALYZE overkill?

The goal is that the operators can run this while I'm at home sleeping ... I want to make sure my error handling is sound.

Cheers,
Art

ps. I read a few mentions about the CHARON-VAX training 14/15 June. I will be attending, anyone else?

[Hein van den Heuvel]

Analyze after a convert is overkill.

If anything, just search/stat, or something like: convert/stat/fdl=nl: idx nl:

As long as that works, sequential gets can read all the data and even if there was a problem during the convert, then a future re-convert can recover the data anyway, as that just reads the main data, no index.

[Convert, using RMS, will use the primary index to read the first record, sequential access from there on through the data level next pointers]

Cheers,
Hein.

[Art Wiens]

Thanks all, the command procedure is basically done with one proc to get the input from the operator which submits another to batch to do the converts. Error handling out the wazoo ... makes it's own backup, sends emails upon failures, I will sleep well ;-)

I rewrote the exisitng procedures and took Hein's suggestion - leave the original in place as a backup. In the previous instance, the live file would get deleted and then a copy would get CONVERTed to the live directory. (Did they check to see if the file existed in the backup area before deleting the live one? umm..no!!! Yikes!!!)

I have further questions regarding the FDL file and optimizing etc, but I'll start another thread so Hein doesn't have to scroll down so far ;-)

Thanks,
Art

[Art Wiens]

See above.