7

Back when I first started in the industry, my first job was processing royalty for an oil and gas company. They used TRS-80 model 1 computers using a BASIC interpreter. The programs were on floppy disks. They contained the owner information in DATA statements. The problem was there were always leftover cents that couldn't be assigned to an owner. Was it possible to store the left over funds to be stored in the DATA statements to be used in the next run?

This question has no relevance in today's industry, it's historical.

Sep Roland
  • 1,043
  • 5
  • 14
Tom Magaro
  • 71
  • 3
  • 1
    You might find some proposals here: https://retrocomputing.stackexchange.com/questions/11286/was-self-modifying-code-possible-using-basic?r=SearchResults&s=1%7C76.9115 – tofro Feb 28 '24 at 14:46
  • 7
    See also the movies 'Superman III' and 'Office Space' for alternative ways to deal with small financial residues. – Eight-Bit Guru Feb 28 '24 at 16:31
  • 1
    @Eight-BitGuru Why did you have to put that grin on my face... Superman III ROTFLOL – Raffzahn Feb 28 '24 at 19:21
  • I'm not an expert but I imagine the DATA statement is a relic of the punch card era. When you could solve this by just punching some new cards and collating them with the other ones before your next run. – The Photon Feb 29 '24 at 19:27
  • There were two main/official BASICs for the TRS-80 Model I. Level 1 BASIC and Level 2 BASIC. I can't remember if they were as different as Apple II Integer BASIC vs AppleSoft BASIC. OK I just checked and in fact both TRS-80 Level 1 BASIC and APPLE II Integer BASIC were written in-house and both replaced by versions of Microsoft BASIC, so the difference is probably just as big, which is to say it probably makes a difference for your question. – hippietrail Mar 02 '24 at 08:11

3 Answers3

14

I'm not sure of what that particular dialect of BASIC can and can't do, but it may be possible if it supports writing ASCII files and reading them in with CHAIN MERGE. Here's an example that works in Microsoft BASIC under CP/M:

10 OPEN "o",1,"data.bas"
20 PRINT #1, "9000 DATA 60.31,7.69"
30 CLOSE #1
100 CHAIN MERGE "data.bas", 110, ALL
110 RESTORE 9000
120 READ a,b
130 PRINT a,b

Lines 10-30 create the data to be persisted. Line 100 merges the data in with the current program and resumes execution at line 110. Lines 110-130 display the data.

john_e
  • 7,263
  • 20
  • 44
  • Yeah, I have to admit I was pretty green when it came to file io using Basic. I eventually got everything working but the woman that kept the books on the wells didn't like that the totals for the checks was off from her figures by a couple of cents. – Tom Magaro Feb 29 '24 at 19:10
6

For the direct question, I am going to guess no, unless those values are written to a file and managed that way.

Uncertain if this is helpful, but early in my career, I worked in a pension department, and we had exactly the same issue -- take $100 and divide it up for 7 people, you get left over cash. The solution ended up being really easy... we distributed cash to the first person, deducted that from the starting total and then divided the remaining funds across the number that were left. So, the first person gets $14.29 in this scenario, deduct that from $100 ($85.71) and figure it out for the 6 remaining people (2nd=$14.29, 3rd=$14.28, etc). It's not always even, but it's only pennies (and we used a database, so presumably the order of accounts changed). Ultimately you get to just one person and they get whatever is left.

Rounding down at 50:

$100.00 / 7 = $14.2857 = $14.29  --> $100.00 - $14.29 = $85.71  
 $85.71 / 6 = $14.2850 = $14.28  -->  $85.71 - $14.28 = $71.43  
 $71.43 / 5 = $14.2860 = $14.29  -->  $71.43 - $14.29 = $57.14  
 $57.14 / 4 = $14.2850 = $14.28  -->  $57.14 - $14.28 = $42.86    
 $42.86 / 3 = $14.2867 = $14.29  -->  $42.86 - $14.29 = $28.57    
 $28.57 / 2 = $14.2850 = $14.28  -->  $28.57 - $14.28 = $14.29    
                         $14.29

Rounding up at 50:

$100.00 / 7 = $14.2857 = $14.29  --> $100.00 - $14.29 = $85.71  
 $85.71 / 6 = $14.2850 = $14.29  -->  $85.71 - $14.29 = $71.42  
 $71.42 / 5 = $14.2840 = $14.28  -->  $71.42 - $14.28 = $57.14  
 $57.14 / 4 = $14.2850 = $14.29  -->  $57.14 - $14.29 = $42.85    
 $42.85 / 3 = $14.2833 = $14.28  -->  $42.85 - $14.28 = $28.57  
 $28.57 / 2 = $14.2850 = $14.29  -->  $28.57 - $14.29 = $14.28    
                         $14.28
Sep Roland
  • 1,043
  • 5
  • 14
A2Geek
  • 103
  • 4
  • 10
    People make fun of the wordiness of COBOL, but its DIVIDE statement could not only accommodate `DIVIDE TOTALPAYOUT BY NUMPEOPLE GIVING EACHPAYOUT REMAINDER LEFTOVER``, but if e.g. EACHPAYOUT and REMAINDER were of a type that supported two digits to the right of the decimal point, the payouts would each be accurate to a cent, with every penny accounted for. – supercat Feb 28 '24 at 15:46
  • 1
    The fun comes when you have to divide the figure in unequal proportions. But the principle's the same -- calculate the amount for each destination in turn, round it, and deduct that from the balance. Last person left gets the balance. – john_e Feb 28 '24 at 23:49
  • Yeah, that's what I finally had to do. The data statements just had the percentage of ownership, so everything was based on the total payout and what each owner received. I was trying to get the company to invest in better disk drives, (we were using 5.25 in diskettes to store the program on, there was no hard drive) but i couldn't get them to invest in the hardware – Tom Magaro Feb 29 '24 at 19:16
5

Not with BASIC tools, as DATA lines are read only parts of the program code.

Of course one could manipulate the program text in memory using POKE, but that's not only a rather high effort, as one needs to manage a dedicated address for each entry and keep that address updated with each program change, but also would it need to save that program back to disk every time one value got updated. The latter bearing the risk of destroying the application.

With all that I can't imagine going that way. Since the system does have floppies, it's way more convenient and secure to simply store those remaining sums in a disk file. Done with a dedicated data disk would also eliminate all risk of destroying the program.

Greenonline
  • 4,296
  • 2
  • 19
  • 57
Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • ... but it would be a clever hack to write a little emit() method that converts a data array into DATA statements appended to the existing program in memory. I agree a data file on disk is a way better solution, but it would be a fun and interesting technical exercise... – Geo... Feb 28 '24 at 15:38
  • @Geo... No doubt. Would be a fun hack. Quite satisfying once it works. Just in no way something for a productive environment. – Raffzahn Feb 28 '24 at 19:18
  • 3
    As you say, a program that rewrites its own source file is a recipe for production disaster. – dave Feb 28 '24 at 23:17
  • In MS-BASIC, and probably other versions of BASIC, the variable area starts in memory immediately after the program text, so it's not possible to add lines to a running program without either restarting it (clearing all current variables) or stomping on some variable values and corrupting them. It would be possible to create "placeholder" DATA statements (e.g., DATA xxxxxxxxxxxxxxxx) that you could then overwrite with pokes, though if you wanted to save these afterwards, that could get tricky. – cjs Feb 29 '24 at 04:30