Editorial

We say goodbye to Robert Batts, the European Consumer Division's Consumer Relations Manager. Robert is heading back to the States this month, having managed to put up with folk like me for probably the longest of any of the ECD managers.

The post of ECD Consumer Relations Manager must be one of the most thankless in the UK, a fact which did not fully impinge on me until after Mike Lunch moved on to other things. You see, ECD and TI are not one and the same thing. When Robert (and his predecessors) were asked questions by us, they did not have a ready source of information which they could tap. If they responded by saying "well, you tell us", it was not out of obduracy but genuine ignorance - Robert has been more persistent than the rest, but in the end he can only relate to us what TI Inc. USA are willing to tell him (and that has not been a great deal).

Essentially ECD act as a buffer between TI Stateside and us, a very neat arrangement and one which has enabled TI to balk all our efforts to make something worthwhile of our machines. Robert did his best to help us, and he managed to be surprisingly successful on many occasions.

I shall certainly miss writing to him (about once a month on average), but I doubt if he will miss the endless stream of unanswerable questions (or the smaller stream of information).

I don't know if you will get the chance to read this Robert, but good luck and don't forget to write.

Enhanced Basic

CALL H() - THE HEADER SUBPROGRAM

Form-filling

Perhaps one good way to begin to understand all of the facilities of CALL H() is to work through an example in Immediate Mode. In fact, there is some degree of repetition involved, so to make life a little easier on both of us I will mix entries in both Immediate Mode and in the form of a short routine (and I do mean short). Here we'll look at a simple form, its structure and likely contents, and how the structure can be transported to the PRK module (and possibly Statistics).

I detest filling in forms, and yet I have to admit to being quite fond of designing forms for others to fill. Here though, I will try to limit my natural excesses and discuss a simple form for compiling useful data on members of a computer club

So, with that in mind, what information will we be likely to want? (Questions like Have You Got A Big Sister?" are out of order).

How about general details on all the club members — nothing too fancy, because the PRK and Stats modules will probably object(!).

I have drawn up a simple list of minimum requirements (with which you may disagree).

The following items are not arranged in any definite order — I have placed related items together in some cases (just to be awkward).

1. TITLE and INITIALS
This is for use in a mailing list program to send out circulars and the like. For labeling purposes this will be useful.

2. FAMILIAR TITLE
This is used in conjunction with "Dear", so that the circular can begin "Dear Baldie" or "Dear Mr. Brooks". These are actually of only minor importance and you may well decide that they are not worth including.

3. SURNAME
Standard requirement.

4-8. ADDRESS
This is quite a tricky one. The limit to the data line of just 15 characters means that a full address will need several entries. These may not follow a simple pattern, which means that you have to cater for the largest likely address. I have chosen to use 5 lines for the full address (to allow for lengthy UK items or for overseas addresses, which often use a different format). I have also chosen to put the post code (or zip code) on a separate line. This gives:

4. ADDRESS 2
5. ADDRESS 3
6. ADDRESS 4
7. ADDRESS 5
8. POST CODE

9. TELEPHONE
A phone number is often included in any reasonably informative database, although in this case only a total of 15 digits are catered for.

10. GENDER
M or F.
[2016-sjs- in context why was this a relevant data item? Title will give you a fair idea in 98% of cases eg Mr, Ms, Miss, Mrs. But does it matter? Was Peter an early keeper of diversity statistics?]

11. TYPE OF MEMBERSHIP
Many groups have different categories of membership — Full, Honorary, Associate, Junior, etc, and this entry must reflect the diversity of types. F for Full, J for Junior, and so on, will be acceptable.

12. RENEWAL DATE

This can be helpful in that a mailing list type of program can be run every day, checking all the entries and finding out who is due to renew membership, etc. For those who are either Honorary or Life members it might be simpler to make no entry at all (which is perfectly possible) and have the file processed only for those with entries in this section.
One thing which must be decided before any system is set in motion is the format to be used for the entry of dates. You can use any of several different formats, but ultimately the choice is limited to a form which does not result in confusion. You might consider a two-digit day, a three-character month, and a two-digit year are sufficient to avoid problems: 1MAR86, 25DEC99, etc.
Or you may decide that you will use a six digit system: 010386, 251299. This is fine if you are sure that there will never be any confusion — is 010386 the same as 3JAN86 or 1MAR86? The problem is worsened by the fact that the PRK and Stats modules will accept digits only for certain items (as is evident when using the modules at any time).
Although the PRK for example begins its entry procedure by asking for a month-day-year, you can in fact enter day-month-year if you so choose.

13. PAID
This entry can indicate one of several things. Some people are in the habit of overpaying by rounding up all of their checks. This can cause no end of problems (I speak from experience) in trying to ensure that records show them to be in credit. Here my intention is to record the total amount paid to date. This should not only take care of any overpayments, but should also indicate the period of time for which they have been a member. You could always make that a separate entry, of course.

That is all the information which I think would be relevant to club records — in fact I keep far less information myself on Oxon TI Users — and of course you may have totally different views and ideas. Now comes the hard part — converting fully to PRK format. Thus far the items could be set out in a standard form (which I have not bothered to draw up — I have only limited space after all) — but PRK's 15-character limit for each entry of data is a little restricting. I have made some allowances above when allocating lines for the address for example, but none for exceptionally long names or titles: "Reverend" for example, or "Mountbatten-Hughes".

Let's now go through the list again, this time deciding how to describe (and ultimately, limit) the types of data required. There are a few things which we need to clarify first. The description of any entry (i.e. SURNAME, RENEWAL DATE) will have to fit within the 9-character length limit imposed by PRK, and conform to its rules for characters which are valid. For this reason, in some cases I have separated two words by a hyphen (-) where appropriate. You may choose a different approach. Here is the list again, with tentative entries describing the type of data required and allowed.

Title and Initials- TITL-INIT- 15 chars
Familiar title- DEAR- 15 CHARS
Surname- SURNAME- 15 chars
Address Lines: AD1,AD2,AD3,AD4,AD5 -15 chars each
Post Code- POST-CODE- I have chosen 9 chars for NNNN NNNN format.
Telephone- PHONE- 15 chars
Gender- SEX- One char
Type of membership- MEM-TYPE- a single char
Date for Renewal- RENEWAL- I have used 7 chars for the format NNMMMNN
Total sum paid to date- SUM-PAID- Decimal with 2 decimal places

Nitty gritty
Now we come to the nitty gritty of this month's article: actual work on the machine itself. I am also going to have to jump the gun a little in order to make this example work, and invoke one of the subprograms which was not due to be discussed for several issues yet: CALL S().

Set your machine up with disk/cassette system attached, and insert your PRK (or Stats module — there may be some minor difficulties with regard to storage, which we will cover later).

Select TI BASIC.

Make sure that there is no program in memory. Type NEW if it makes you feel better. Then type: CALL P(10000)

and then NEW. It is important that you follow the CALL P() with NEW, in order to force the 4A to re-assess its available free memory.

What we will be doing is to set up the structure of the database by making use of CALL H() with successive values for INFO. We will call the file "CLUB-85A" and it is a simple matter to place that name in memory: CALL H(0,1,0,"CLUB-85A")

Breaking that down, the first zero is the R/W parameter, which in this case indicates that we intend to write information to the header. The second digit, 1, is the INFO parameter, and this specifies which item we are writing — namely, the FILE NAME (0 to 9 characters). The third digit, another zero, is the FLD parameter, which in this case is unused, so I have set it to zero. Finally, the string at the end is the V$ parameter

We will now enter the date into the relevant positions in the header.

I have chosen January 1, 1985 as the date, and this is entered, again, very simply thus:
CALL H(0,2,0,1)
CALL H(0,3,0,1)
CALL H(0,4,0,85)

The first two CALLs store the day and month values (remember that I said that the entry can be made either day-month-year or month-day-year) and the third is the last two digits of the chosen year.

Now we will enter the names of each of the FIELDS (INFO = 9 on page 19 of Volume 1 Issue 9). As this is a fairly repetitive process — we will be doing the same basic CALL fourteen times — we can enter and run a short routine to do the work for us. This will also demonstrate one of the advantages of the PRK database: once the data has been stored, you can virtually do what you like (apart from using BYE or FCTN =).

There are many different ways of doing this, but possibly the most straightforward method is to use this routine:

100 FOR L=1 TO 14
110 INPUT STR$(L):I$
120 CALL H(0,9,L,I$)
130 NEXT L

That's all there is to it. Because the INFO parameter has a value in excess of 8, the FLD parameter now has a use and a meaning (the loop controller, L, will provide the number of each of our 14 fields in turn, and in this case I$ will pass the FIELD NAME to the header).

Run the program, and enter the values from the ITEM NAME column in the Summary Table above.
Once those have been entered, edit the program thus:

Change line 110:
110 INPUT STR$(L):I

and line 120:
120 CALL H(0,10,L,I)

The program is now ready for entry of the TYPE of FIELD for each of the defined fields. The TYPE is given by either 1, 2, 3, or 4. In all but one case the type is CHAR, which is represented by a 1. The last entry is DEC or Decimal, whose number is 3 .
All you have to do then is to run the program, enter 1 for thirteen INPUTS, and 3 for the last one. You might even be bold and alter the program to do it all for you!

The fun isn't over yet. We now have to enter the WIDTHs of the FIELDs, which are detailed in the Summary Table (again). The program needs one minor but important change in Line 120. As we are now dealing with INFO number 11, that parameter needs to be updated:
120 CALL H(0,11,L,I)

Run the program again, entering the Width values as you are prompted.
If you feel that you are getting the hang of it, you might like to insert a line to read the field name each time and incorporate it in the INPUT prompt. Here's how, in case you need a little help:
105 CALL H(1,9,L,F$)
110 INPUT F$:I

If you don't feel that confident, don't make the changes.

Almost near the end. The last entry to be made concerns INFO = 12, which is the number of decimal places for a field of type DEC. We have only one of those — item 14 — and so a single command is sufficient:
CALL H(0,12,14,2)

Translating, this instructs the computer to WRITE, the number of decimal places, for field number 14, which is 2.

Now comes the jumping of the gun. If you have a cassette system, enter this:
CALL S("CS1",A)

and follow the instructions.

If you have a disk system, enter this (for drive 1):
CALL S("DSK1.CLUB-85A",A)

Once the SAVE is complete, PRINT A and check that it is 1. This should indicate a successful SAVE — although it may not be applicable to the cassette file.

Now quit with either BYE or FCTN = and select PRK this time. When the opening titles have got out of the way (press ENTER to speed it up), enter an acceptable date (perhaps 1, 2, 85?) and answer N to the query about the printer. There may be a problem with opening a file to the RS232 at this stage (should you be fortunate enough to have one).

Select the option to load a file, and depending upon the method of storage that you used, make a further selection. With regard to the disk system, enter the same file name as you did above for CALL S(). Once the file has loaded successfully, select the option to examine the file structure. You should see two displays:

Note also that the PRK module has defined the size of your file as 59 pages, of which there are none used (because we haven't reached CALL G() yet).

Go back into TI Basic and experiment further on your own, examining some of the other INFO items, especially those which are automatically maintained by the Header routine. To read an item, set the R/W parameter to 1 and supply the necessary string or numeric variable in the V/V$ parameter. Specify the INFO and suitable FLD values, and see what you can find out.

Finally, for the desperately bug-ridden, here is an opportunity to be troubled even more by bugs: A full routine to place the basic items in the header for you:

100 CALL H(0,1,0,"CLUB-85A")
110 CALL H(0,2,0,1)
120 CALL H(0,3,0,1)
130 CALL H(0,4,0,85)
140 DATA TITL-INIT,DEAR,SUR
NAME,AD1,AD2,AD3,AD4,AD5,POS
T-CODE,PHONE,SEX,MEM-TYPE,RE
NEWAL,SUM-PAID
150 FOR L=1 TO 14
160 READ I$
170 CALL H(0,9,L,I$)
180 NEXT L
190 FOR L=1 TO 13
200 CALL H(0,10,L,1)
210 NEXT L
220 CALL H(0,10,14,3)
230 DATA 15,15,15,15,15,15,
15,15,9,15,1,1,7,5
240 FOR L=1 TO 14
250 READ I
260 CALL H(0,11,L,I)
270 NEXT L
280 CALL H(0,12,14,2)

That's all folks. Next issue: CALL G().