Computers: Universe: The REVISE Command

Creating and modifying UniVerse records

So far, we have been creating records using the editor: and you will find throughout your UniVerse career that this is often the simplest and quickest way of entering and modifying information. It is particularly useful when you are very familiar with the format of a file, and therefore know with confidence what information should go onto each numbered field. This is particularly true, of course, of VOC and dictionary records, which have a format common to all UniVerse accounts, applications, and systems.

However, such an approach is clearly unsuitable to an end-user, and would never be incorporated as a permanent part of a live system. The editor provides no help, no control, and no validation. For this reason, data entry under UniVerse is almost always done under the control of UniVerse Basic programs, which can offer users meaningful prompts, help messages, type and data validation, security control, and so forth. Sometimes such programs are coded by hand. Others consist of unique UniVerse Basic programs generated by 'screen generators' or 'fourth generation languages' (4GL's) working from screen specifications created by analysts or even end users.

A variation on this theme is the 'screen interpreter'. This is a UniVerse Basic program designed to handle all the common functions required for data entry and modification. Instead of taking a screen specification and generating a UniVerse Basic program from it, it uses it to control the prompts it displays, and validation it applies, at run time, and actually does the data entry itself.

The pros and cons of these various methods are really outside the scope of this course. I mention them because UniVerse provides its own, rather basic, screen interpreter. It is called REVISE, and it uses the dictonary of a file as a screen specification: because the dictionary contains much of the information it requires: the names of the fields, user friendy labels for them (column headings), display widths and so on.

Truth be told, though, REVISE is not great. It's interface is extremely clunky, and it is still too awkward for most users, while offering few advantages to the developer over the naked editor.

Having said that, it is sometimes a convenient way of creating a quick and dirtry makeshift data entry screen. It is also used to edit menu records, which contain many multivalued fields and are therefore rather tiresome to handle using ED. Once you've tried it, you'll need to decide on its suitability for any particular purpose, but almost any tool is sometimes useful.

To illustrate the REVISE command, we shall need a data file. If you wish to follow the examples which follow, create a dynamic file called CUSTOMERS with the dictionary below (if you are unsure how to do this, consult the earlier sections of this guide on Universe Files, Dictionaries and The Editor: ED before continuing).

A sample REVISE session

The simplest way to invoke REVISE is simply to type REVISE filename. Try it:

>REVISE CUSTOMERS

CUSTOMERS REVISE.1 Mon Aug 16 13:44:29 1999


Cus. Code=

The prompt here, Cus. Code, is taken from the 'column heading' (line 4) of your @ID dictionary record. REVISE is asking for the key of the record you wish to edit or create. If the key you entered existed, the corresponding record would be displayed on the screen for you to edit: you will see what this display looks like a little later. For now, the file is empty, so any key is going to be new. When you enter a new key, REVISE prompts you field by field for the information it needs to create the record.

Cus. Code= GSL
New Record
Cus. Name=

Again, this prompt is taken from line 4 of a dictionary record: this time line 4 of the NAME field definition. Simply enter a value and hit ENTER:

Cus. Name= Grommet Subframes Limited
CUSTOMERS -Screen 2-CONTACTS Mon Aug 16 13:48:46 1999

@ID==> GSL
No. CONTACTS......................
1
Contacts=

You may recall that the CONTACTS field was defined as multivalued, to allow more than one contact name to be recorded against each company. REVISE handles multivalued fields by clearing the screen and then prompting you for values one by one. When you do not wish to enter any more values, you just press ENTER:

Contacts= Hugo Grommet (MD)
Contacts= Ashleigh Plumbstone (FD)
Contacts= (Press RETURN)

CUSTOMERS -Screen 2-CONTACTS Mon Aug 16 13:56:26 1999

@ID==> GSL
No. CONTACTS......................
1 Hugo Grommet (MD)
2 Ashleigh Plumbstone (FD)
3

Change which line item=

Once you have entered as many values as you wish, REVISE lists them for you to check, and to modify if necessary. Let us assume that you need to modify the second contact, as his name is actually spelt 'Ashley'. Enter 2:

Change which line item= 2

CUSTOMERS -Screen 2-CONTACTS Mon Aug 16 13:58:05 1999

@ID==>>GSL Line==>> 2
3 CONTACTS Ashleigh Plumbstone (FD)
Contacts= Ashley Plumbstone (FD)
CUSTOMERS -Screen 2-CONTACTS Mon Aug 16 13:59:50 1999

@ID==> GSL
No. CONTACTS......................
1 Hugo Grommet (MD)
2 Ashley Plumbstone (FD)
3

Change which line item=

As you can see, the new contact name is now in the list of values: but only because you retyped it in its entirety. Is there a quicker way to correct small mistakes? Say, this time, you must correct the second contact because there should be no 'b' in his surname. Once again, you begin by selecting the second line to edit.

Change which line item= 2
CUSTOMERS -Screen 2-CONTACTS Mon Aug 16 14:02:46 1999

@ID==>>GSL Line==>> 2
3 CONTACTS Ashley Plumbstone (FD)
Contacts=

At this point, you could retype the entire name, ommitting the 'b' from the surname by way of correction. However, there is an easier way. REVISE allows you to use the C or 'change' command from its cousin ED. To remove the 'b', you therefore need only enter:

Contacts= C/b//

CUSTOMERS -Screen 2-CONTACTS Mon Aug 16 14:03:32 1999

@ID==> GSL
No. CONTACTS......................
1 Hugo Grommet (MD)
2 Ashley Plumstone (FD)
3

Change which line item=

Once again, the corrected list of values is displayed for your approval. Let us now assume there are no further errors. Simply press ENTER to complete your entry of the CONTACTS:

Change which line item= (Press ENTER)

CUSTOMERS -Screen 1-FIRST SCREEN Mon Aug 16 14:04:15 1999

1 @ID GSL
2 NAME Grommet Subframes Limited

S1 == FIRST SCREEN
S2 == CONTACTS

CHANGE=

You have now finished enter your CUSTOMERS record, and you now have the chance to modify any of the fields you have entered. This, incidentally, is the display you would have seen if, when you first entered GSL at the Cus. Code prompt, it had been an existing record.

Notice, incidentally, how this screen is using the actual underlying field names to label the values in the display, rather than the column headings from line 4 of the dictionary records it was using earlier: such as @ID instead of Cus. Code. It is difficult to account for this rather bizzare inconsistency, and if you plan to allow you eventual users to use REVISE to enter and modify records, you should try and stick to friendly and meaningful field names (but of course, you were going to do that anyway, weren't you?). Even so, it is difficult to avoid the most arcane of them all: @ID, unless you set up a second D type dictionary record for field 0, which is something I hate doing.

At this prompt, you could enter a 2 to change the customer's name, or (interestingly enough) a 1 to change its key. Changing the key of a new record has no unusual implications: REVISE will simply file the new record under its new key, and as it never existing under its old, this is straightforward. However, if you use REVISE to modify an existing record, REVISE will quite happily let you do so. This has the effect of deleting the original record and creating a new one under your new key: logical enough, but a somewhat drastic implementation to be buried under what looks like a simple field change.

You could also enter S1 or S2. They are both labelled: and as you can see from those labels, S2 will take you back to the CONTACTS list for further additions or modifications. S1 will take you to the 'first screen'. But hang on: aren't you at the first screen? Yes. And would you see this prompt anywhere except the first screen? No. So what does S1 do? Try it.

CHANGE= S1
CHANGE=

That's it. Enter S1 and it will simply redisplay the prompt: and keep redisplaying it until you enter something other than S1. Stranger than fiction.

Anyway, by now I am assuming you have recorded more than you ever wanted to know about Grommet Subframes Limited, so simply press ENTER to indicate that you do not wish to change anything further:

CHANGE= (Press ENTER)

CUSTOMERS REVISE.1 Mon Aug 16 14:07:49 1999


Cus. Code=

You are finally returned to the very first revise screen you saw after entering the original REVISE command. Here, you can enter further keys to edit or create, or you can just press ENTER to exit.

Cus. Code= (Press ENTER)
>

?, TOP and ^

REVISE has a few special instructions you can use while you are editing. The most important are ?, TOP and ^.

? is a request for help. It displays messages of varying degrees of helpfulness and consistent terseness.

^ is supposed to resemble an 'up arrow', which is does a bit, once you know. It returns you to the previous prompt, in case you have made a mistake during entry you wish to correct immediately.

TOP returns you right to the 'top' of your record: effectively 'quitting' the record (like Q in ED). Why it couldn't have been called QUIT I am not sure. Be aware also that TOP, unlike ED's Q, does not warn you if you are about to abandon changes without filing them.

@REVISE and @ phrases

So where does revise get the list of fields to prompt for? It follows the following strategy:

1. If there is an @REVISE (or @ENTRO) phrase on the dictionary, it will derive its list of fields to edit from that. This is a link back to the good old days when REVISE was called ENTRO: UniVerse seems to have gone to some lengths to provide versions of all command names with a 'V' in them (or should I have said 'Versions'?). Try ENTRO, it still works.

2. Failing an @REVISE/@ENTRO, it will take use an @ entry (see Phrases).

3. Failing both of these, it will automatically create an @ENTRO phrase by listing all the D types in the dictionary. If more than one D type refers to the same field number, it will choose the first one it finds (not by alphabetical order: effectively at random). This is another good reason for only having one D type per physical field. You could, of course, edit the @ENTRO phrase to correct the choice of field names if you would prefer others, but why set up situations like this which increase your workload?

By editing the @ENTRO phrase, you can persuade REVISE to edit only a subset of the fields. You can also add keywords (like VERIFY and VERIFIELD) which add some useful internal and external validation: but this level of detail is outside the scope of this course. As ever, if your appetite is wetted, consult the UniVerse documentation for more information.

In summary, REVISE is a sometimes useful but rather clunky and at times rather odd program. Personally, I would never stick it in front of a user, though I find it occassionally useful as a developer's utility. It's a nice idea, but I can't help feeling it could have been written better. At the end of the day, it's your call.