Need to know parameter format for a Call function?

[Elkvis]

Programming without being able to establish Base Registers makes it virtually impossible to do complex passing of data between programs (and subroutines) that are compiled separately.

Most non-embedded database systems use shared memory, named pipes, or other IPC (inter-process communication) systems to communicate between application and database. They each have their own isolated memory space, and the OS kernel facilitates the communication.

It virtually destroys the ability to write really good subroutines like ADAM.

Considering that you still have yet to show any side-by-side comparisons with systems with which forum members might be familiar, making this claim is difficult to justify.

Using tables instead of Base registers seems terribly inefficient to me!

The "efficiency" you lose is offset by the fact that you can access all the memory that the processor can physically address. In order for segmentffset to work the same way as it does in DOS, segment registers would need to be 32/64 bits wide, and would likely bloat applications far beyond reasonable limits.

The important thing that you need to remember is that the processor handles the tables at a very low level. If your program had to maintain and enforce them, it would be incredibly inefficient, as you say, but the processor does it automatically with ease. Memory protection (responsible for your inability to use the segment registers in the way you want) is very important for security.

[Will1]

The PC architecture has made it such a long and difficult process of programming for 32 (and 64) bit PCs that I guess I'll just abandon the project. In case anyone wants to look at an ADAM application that runs under DOS and has a desktop computer running WINDOWS XP or an older WINDOWS system, Send me your email address and I'll send you the zipped system. My email address is:

[email protected]

If you have a desktop with WINDOWS version 7 or 8, I have a version of the same system that I'll send you but it doesn't have graphics nor mouse support the way the version for earlier versions of WINDOWS does because MicroSoft chose to do away with "Full Screen Mode" in WINDOWS 7. Why did they do that? The only reason I can imagine is because there are bugs in it and Microsoft doesn't seem to have the expertise to fix bugs anymore so doing away with a very useful function, rather than fix it, was what they did.

What ADAM does is not all that unique! What is unique about it is it's speed! I would say efficiency except that modern PC's are so "powerful" that programs can be grossly inefficient and still run with reasonable speed. That wasn't true when I programmed the original version of ADAM but even back then MicroSoft and the rest of the PC IT community wouldn't look at anything new unless they could buy it or copy it. Bill Gates bought DOS from GE when he got the contract with IBM to supply an Operating System for the PC. IBM got burned pretty bad in that whole deal so they abandoned the PC market about 15 years ago. Too bad because IBM was and still may be the corporation with the best computer expertise.

[Will1]

Has anyone noticed the story about Social Security spending hundreds of millions of dollars and 5 years, so far, to update their disability claims from "outdated" computers systems to PCs? Probably the "outdated" systems they are talking about are mainframes. Moving from a mainframe to a system of PCs is about as ignorant a decision as I am used to seeing from our monolithic federal government. The problem is probably the same as the problem was when too many people tried to sign up for Obamacare. PCs just won't handle the traffic that mainframes do. As a former mainframer I can tell you what the problem with PCs is. A PC can NOT overlap processing with IO, a mainframe can. A mainframe can overlap the input data from several sources with processing the data. It's really that simple what the problem with the Social Security system is and the problem that signing up for Obamacare was or still is. A PC is a fraction of the cost of a mainframe but a PC (INTEL or AMD) processor can only process the data that it has in memory. (And even getting from memory to the processor takes time!) Getting that data into memory takes millions of microseconds if you have thousands of data inputs to handle. Too bad that modern colleges, universities and vocational schools don't even understand the problems that are being experienced in today's IT world. Most of you probably didn't get a course on the differences between mainframes and PCs. Such a course should be IT 101. But then, virtually all college professors are convinced that mainrames are "outdated." I say the Social Security Disability processing system should have been programmed on a mainframe. The problems that have caused me to abandon my project to update ADAM for the 32 and 64 bit systems don't exist on the mainframe. ADAM, if converted, would help tremendously in speeding up data access on PCs. It is "blink of the eye" fast processing thousands of records under DOS.

[Elkvis]

What you fail to realize is that modern "mainframes" are really nothing more than high-end PCs with many CPU cores and tons of memory and mass storage. IBM's mainframes typically run Linux or AIX (IBM's flavor of UNIX), and bear little resemblance to the mainframes you knew 40 years ago. Chances are, they can still run the same software, in emulation layers, but for the price of a mainframe and a bunch of terminals that do nothing more than access the applications on the mainframe itself, you can get a somewhat lower spec server (or several) and the equivalent number of PCs, and still get the same performance or better, and get much greater user productivity, because the PC on the user's desk can do much more than simply access a mainframe and a rigid set of applications. The PC would run client applications for accessing server functions, and all the processing is still done by the server. The advantage is that now the user can access his/her company email, documents, and the web from the PC, without requiring any involvement from the server. This reduces the workload on the server, and frees up its resources for processing user requests.

[phantomotap]

Has anyone noticed the story about [...] fast processing thousands of records under DOS.

O_o

You really need to make you your mind. If "ADAM" is so fast under "DOS" as you claim, the "PC" part of the equation your parading on isn't the problem.

[Edit]
I needed to edit a few bits because rewording left some bits misplaced.
[/Edit]

As for the speed of "ADAM", until you tell use what "ADAM" is the measurement is actually less than irrelevant. (You've been told the fact several different ways several different times.) I threw a test at my "PostgreSQL" instance on one of my "Raspberry Pi", for comparisons sake, seeing only about twenty transactions a second while the test thrown at my own "big block store" resulted in several hundred transactions per second. (People who know how best these vastly different kinds of databases are used have already said to themselves what I'm about to say.) Until I tell what what sort of transactions I was testing, the results themselves are irrelevant. I may as well have literally said "A relational database engine processed potato transactions while a fixed-width binary file processed tomato transactions.". You aren't learning anything about the tests; you are only learning a very little bit about the technologies used in the test.

Soma

[Will1]

What you fail to realize is that modern "mainframes" are really nothing more than high-end PCs with many CPU cores and tons of memory and mass storage. IBM's mainframes typically run Linux or AIX (IBM's flavor of UNIX), and bear little resemblance to the mainframes you knew 40 years ago. Chances are, they can still run the same software, in emulation layers, but for the price of a mainframe and a bunch of terminals that do nothing more than access the applications on the mainframe itself, you can get a somewhat lower spec server (or several) and the equivalent number of PCs, and still get the same performance or better, and get much greater user productivity, because the PC on the user's desk can do much more than simply access a mainframe and a rigid set of applications. The PC would run client applications for accessing server functions, and all the processing is still done by the server. The advantage is that now the user can access his/her company email, documents, and the web from the PC, without requiring any involvement from the server. This reduces the workload on the server, and frees up its resources for processing user requests.

You're talking about the smaller computers that still can be called "mainframes." Show me a "System" made up of PCs that will do what the IBM system 390 can do? You are completely ignorant of mainframe technology because whoever taught you to program computers was probably among the ignorant cadre of teachers that believe that PCs can do anything that a real mainframe can do. Show me a PC that can be accessing data from a hard drive concurrently with processing data that it has accessed from the hard drive previously. Only mainframes can do that. Normally, you access a mainframe using a PC to enter and retrieve data. The PC is used in the ways you mentioned when not accessing a mainframe. IBM's main Operating System is called MVS. It is a quantum leap ahead of Windows or Linux, or UNIX or any other Operating System.

[Will1]

As for the speed of "ADAM", until you tell use what "ADAM" is the measurement is actually less than irrelevant. (You've been told the fact several different ways several different times.) I threw a test at my "PostgreSQL" instance on one of my "Raspberry Pi", for comparisons sake, seeing only about twenty transactions a second while the test thrown at my own "big block store" resulted in several hundred transactions per second. (People who know how best these vastly different kinds of databases are used have already said to themselves what I'm about to say.) Until I tell what what sort of transactions I was testing, the results themselves are irrelevant. I may as well have literally said "A relational database engine processed potato transactions while a fixed-width binary file processed tomato transactions.". You aren't learning anything about the tests; you are only learning a very little bit about the technologies used in the test.

OK, I tried, using the 32 bit Windows version of ADAM, adding 5,000 records 512 bytes long to an ADAM file to see how long it would take. the last thing I had to do was hit the "Enter" key. Before I could even get my finger off the key, ADAM finished adding the records and put the successfully completed message on the screen. Since you have an SQL data base for comparison, try adding 5,000 "Rows" of data to the data base and see how long it takes. After the test, the file is 2 and a half megs long. I'd be interested in a comparison!

[Codeplug]

>> Show me a PC that can be accessing data from a hard drive concurrently with processing data that it has accessed from the hard drive previously.
I'm assuming you have a PC - look at it.

Synchronization and Overlapped Input and Output (Windows)
Boost application performance using asynchronous I/O

>> You are completely ignorant of ...
The only ignorance I've observed so far is of modern OS concepts and capabilities.

Operating-System Comparisons
I see nothing special about MVS compared to a modern OS.

gg

[phantomotap]

Show me a PC that can be accessing data from a hard drive concurrently with processing data that it has accessed from the hard drive previously.

O_o

That is, essentially, the definition of "DMA".

OK, I tried, using the 32 bit Windows version of ADAM, adding 5,000 records 512 bytes long to an ADAM file to see how long it would take. the last thing I had to do was hit the "Enter" key.

o_O

You are bragging about processing an insignificant bit of data.

The harness on the "Raspberry Pi" I mentioned has 12,000,000 records which, to be clear, is also insignificant.

After the test, the file is 2 and a half megs long.

O_O

You are bragging about processing flat binaries?

You are bragging about processing FLAT binaries?

That is actually "laugh out loud" funny.

Do you know what "silvering" is? "transactions"? "atomicity"?

Do you have any idea how far removed "dumb binary file" is from what is stored by modern databases?

What you are doing is so far removed from what databases actually do you may as well be bragging about the color of your car.

I'd be interested in a comparison!

I'm betting that you will soon not be "interested".

./sql.sh 512 5000
real 0m0.156s
user 0m0.153s
sys 0m0.083s
5.5M example.db

./sql.sh 1024 10000
real 0m0.357s
user 0m0.367s
sys 0m0.223s
21M	example.db

[Edit]
You'll need "bash" and "sqlite3" as well as some other common tools.
[/Edit]

Soma

#!/bin/bash

instructions() {
  # just to have something to pad the value
  VALUE="$(dd if=/dev/urandom bs=1 count=$1 2>/dev/null | hexdump -e \"%.2x\" 2>/dev/null)"
  echo "create table mytable(key int, value varchar);"
  for KEY in $(seq $2); do
    echo "insert into mytable values($KEY, \"$KEY-$VALUE-$KEY\");";
  done
}

build() {
  instructions $1 $2 | sqlite3 "example.db"
}

rm -f "example.db"
time build $1 $2
du -h "example.db"

[Will1]

Do you have any idea how far removed "dumb binary file" is from what is stored by modern databases?

You call ADAM 5,000 records a "dumb binary file" and make what I would call "dumb" comparisons. An ADAM record has as much use and can be compared to a "row" in an SQL data base. I challenge you to add 5,000 "rows" to your SQL data base and see how long it takes and you come back with a bunch of bull.......... I guess you practice the, "If you can't dazzle them with brilliance, baffle them with bull........" philosophy. WOULD YOU PLEASE ADD 5,000 "ROWS" TO YOUR SQL DATA BASE AND SEE HOW LONG IT TAKES!" Then we'll have a comparison. Stop evading the comparison that you and others on this board have challenged me to make so I set up the test to make it. Then you evade making the comparison. ALSO NOTE THAT THE TEST I MADE WAS ON THE WINDOWS 32 BIT VERSION OF ADAM, NOT THE DOS VERSION! Like I said before, I have converted ADAM to run on Windows 32 bit but it is so restricted by the lame Windows operating system that I decided to keep it to myself just like I did the DOS version of ADAM.

[Will1]

[QUOTE=Codeplug;1208380I see nothing special about MVS compared to a modern OS.[/QUOTE]

The CS, DS, and ES registers can be compared to "Base" registers under MVS. MVS has "Memory Protection" and I can still freely manipulate "Base" registers. That ability is critical to making Data Bases (ADAM) efficient.

"phantomotap" evaded making a real comparison of SQL to ADAM. ADAM can add thousands of records to a file in a fraction of a second. How long does it take modern SQL to add thousands of "rows" to a data base on a PC? IBM's mainframe SQL is called DB2. If I could take control of the Social Security disability claims, hundreds of millions of dollars and years of work, I'll bet I could have it up and running in less than six months. IBM uses VSAM as an engine for DB2 and I'll bet that DB2 is a quantum leap faster than any PC SQL system. VSAM is similar to ADAM. I might well have been the original designer of VSAM but that is ancient history and speculation on my part. It happened in 1969, several years before IBM announced VSAM.

[stahta01]

To Will1: Your lack of knowledge of SQL and relational databases makes us all doubt your conclusions!

Hint: You often use SQL where relational database(s) is likely what you mean.

Tim S.

[Codeplug]

>> I have converted ADAM to run on Windows 32 bit but it is so restricted by the lame Windows operating system ...
The only thing restricting you is your unwillingness to learn and understand new technology.

>> I challenge you to add 5,000 "rows" to your SQL data base and see how long it takes and you come back with a bunch of bull..........
You obviously have no idea what your looking at in post #69. Why not just ask for an explanation instead of exposing your ignorance in caps?

gg

[Will1]

You often use SQL where relational database(s) is likely what you mean.

Tim S.

Tim:

What other relational database system do you suggest I compare ADAM with?

How old are you young guns anyway? It's obvious from Elk's posts that he has no idea how mainframe architecture works. When I programmed the father of ADAM on the mainframe when Bill Gates was a grammar school kid, I had to do EXCP instructions. An EXCP is an Execute Channel Program. After you do an EXCP instruction you can do a lifetime of work on the same processor while the Channel Program is waiting the many years it takes for the data that is to be read or written comes under the R/W head. An INTEL or AMD processsor is a midget compared to an OS/390 processor. You really can't compare a PC with an OS/390 system. The PC doesn't have channels where the disks reside in the system. A mainframe, and here we are talking about the System 390 and z\OS, not the much smaller AS400, has many channels so the one processor can be accessing several disk files at the same time. It also can be talking to literally hundeds of people at the same time who are using their PCs as terminals. Take a look at CICS! I ran into a guy a few years ago that was trying to program a CICS system on a PC. I told him that he was going about it the wrong way and he balked at me working with him or even giving him advice. The company name he was using was Eden Software but now I can't even find him on the internet. I guess he gave up on the idea, but if he had worked with me we could have replaced CICS systems with a network of PCs. It is virtually impossible to do it on one PC. Anyway, "Who is John Galt?"

Will M.

[Will1]

Most non-embedded database systems use shared memory, named pipes, or other IPC (inter-process communication) systems to communicate between application and database. They each have their own isolated memory space, and the OS kernel facilitates the communication.

OK Elk:

How do I go about acquiring a chunk of memory at execution time?

Will