Hi Mike,

Replying to a message of Mike Luther to Murray Lesser:

However, if you are not in too much of a hurry at run time, you
could write your application in REXX.

I investigated that .. but actually gave up on it, as one reason, for precisely the exact same reason you noted above. I carefully avoided
all CHAIN operations and chose to carry all the required parameters
for control passage between executables as disk I/O. I thought that
made more sense in planning for portability. Thus executable
shifting and load time is important.

The switch of execution context in REXX is much more rapid than a CHAIN in BASIC. [The longest time I ever saw a compiled BASIC system take for a CHAIN statement was just over 45 minutes, but that was on a DEC PDP-11/70 in 1977. Modern machines are a tad more powerful.]

More interestingly, REXX is an extensible language. This means you can write extension DLL's in whatever native code language you fancy, provided it supports _System linkage convention. There are plenty of samples in C, and I have posted samples in PL/I and assembler. Thus, when the base language runs out of capability or too slowly, branch off into some native object code to do the fiddly bits.

That is also one of the reasons I winced when I tried Visual Age for
Basic in OS/2 which I bought and have! Sure the ball bounces! But
by the time you ever see it bounce, your opponent has already stolen
the interpreter and scored ten goals with the silly compiled ball!

Visual Age for BASIC runs slower than almost anything else. It is on a par with
Java for poor execution performance. Even the 2-CD "fixed" version was slower than treacle.

If, a la as PowerBASIC finally did for WIN-ugh, M/S and IBM had ever released a full compiler version of VB, that would have run on both
OS/2 and WIN-ugh, the world would have been VERY different today!

IBM was not into native object code when VAB (originally named "Bart") was being planned and developed. The company is still into Java byte codes in place
of object code, as that sells more hardware for fewer end-user results.

REXX has the same SELECT construct as does
PL/I. (REXX was derived, in part, from PL/I; in the same sense that
the original line-by-line-compiled Dartmouth BASIC was derived from
FORTRAN.) I got my copy of REXX for DOS (Personal REXX v 3.0 by
Quercus Systems) in 1991. It may still be available.

Here comes the education! Yes, if true, a part of portability sure
might be made between OS/2 and back-level DOS!

Quercus Personal REXX is still around, I believe.

However, PC-DOS 7.0 (or patched to PC-DOS 2000) comes with REXX built-in. It also has an extension function facility.

When Gordon Letwin crafted the foundation for OS/2 he also happened to
be the Chief Architect of the PDS Compiler! Somewhere in my printed
text I happen to have read his remark, I think it's his, that, "The arrival of a new language is marked by the arrival of the first true compiler." That's, in my feeble understanding of things, a very
correct statement.

All too many modern languages cannot be compiled (e.g. SmallTalk).

Because of the way that PDS 7.1 was written to integrate the assembler operations for the HEX21 interrupt work so well into BASIC, we got
two very,very important things cross-referenced to both OS/2 and DOS!
We got a terribly simple-to-implement full network file I/O system
with file lock,record lock; shared multi-user tools. And to a lesser note, we also got the entire ISAM file engine buttoned up so that
even a dunce like Mikey could learn to use and implement full
networked file I/O with deadlock intervention and all that!

Compared to what is potentially ahead for you, that facility is crude and limited.

You know that insane feeling, the whirl of the dance, it plays with
you, it plays with you. And when the room quits spinning, "Morning
is breaking, comes the first morning ..."

Please go easy on the Cat Stevens. ... :-)

[And it's "Morning has broken, like the first morning ..."]

Gee, playing that hymn on
a Baldwin concert grand is just like the computer keyboard when I
first discovered INT21, I swear it!

The INT 21H interrupt is not especially special, especially once one forgets raw DOS and uses a system with greater facilities.

I still have somewhere, I think, the FidoNet post Bob Juge posted that chided me for even comparing DesqView to OS/2. I think that is one
of the landmark posts I've ever had addressed to me. I listened
CAREFULLY to what Bob said, took his advice. But ... in doing so,
the superb work of Gordon Letwin with PDS 7.1's FAMILY approach to programs and, specifically,the business of full network aware I/O,
has been, to me a mess elsewhere.

We can safely forget FAPI too.

Where do I go to get the complete cadre of INT21 network tools, in
such a concise form as I've learned and written stuff for
shared-locked file I/O with other than C?

You don't get them at all in C!

All those facilities are external calls as non-standard extensions to the C Standard Library. Functions like int86x(), etc., are not at all portable. They aren't even a reasonably mnemonic way of coding. And they aren't part of C!

Remember! It isn't that
it can't be done in other languages that are available in OS/2!

It's that I have to be able to extend the services *BACKWARDS* in DOS, yes,pure DOS for another seven damned years after I make the toolset switch!

How DOS is DOS? Remember that much of what you are asking for is implemented by
add-ons such as TSR's. I have largely dropped DOS support in my work these days, unless something serendipitous happens such as a 32-bit DPMI extender offering facilities that allow some code to work in DOS too.

None of the major development tools vendors is supporting 16-bit code any more,
except in their assemblers. All modern compilers produce 32-bit code exclusively. The upshot is that DOS is dead. Indeed, there is no ISO/ANSI-certified C++ compiler for 16-bit DOS, AFAIK. [Jonathan might know of one.] All the 16-bit C compilers are C89 or worse [K&R], with no C99 compilers available. As I said, DOS is dead.

That and another of Gordon's diamond sharp gifts, variable length
string arrays with the assembly language automatic trashman! I
listened! I listened! I learned a little, enough to know I ain't
very smart.

Gordon Letwin did not invent variable length strings, nor did he invent garbage
collection. These were both mature technologies by the late 1960's, some 20 years before MS BASIC PDS 7.1. [Read some of Bill McKeeman's papers published through Stanford in the mid-to-late 1960's for some insight into both of these topics.]

I need two things, big time! I need multi-dimensional variable-length string arrays, that, in fact, can be dimensioned, not as you might
suppose most folks do, but as DIM A$(-150 to +150, 10), or the like,

How about:

DCL String_array(-150:150,10) CHAR(4096) VAR;

?

That's a PL/I declaration of an array of strings, varying in length up to 4096 bytes and subscripted from -150 to +150 in the first dimension and 1 to 10 in the second dimension. Of course, the array bounds and the string maximum length
don't have to be constants in most contexts; they can be arithmetic expressions
involving variables of "outer scope" if needed.

and full network aware file I/O shared read-write lock and deadlock protectable.

File locking is intrinsic to PL/I's record-oriented I/O. There is an UNLOCK statement too.

Can REXX, for example, and PL/1, in one easy common source code caper,provide me with full support for OS/2, WIN-ugh, and DOS, for
these?

For 16-bit DOS you could be constrained by your environment, and by the elderly
Digital Research compiler.

For OS/2 and Win32 you are off and racing with PL/I. All you ask for is built into the base language.

And don't you, huge grin, tell me like Paul Sittler used to and keeps telling me, "Write your own functions, stupid!" I won't live long
enough!

Functions? That is making one's point the hard way.

The use of function calls to perform I/O is one of the worst features of C, and
one reason why the iostreams of C++ make that language a major leap forward. An
even better approach is the use of native language statements, a la COBOL, so that the compiler is aware of the semantics of I/O. This is also the PL/I approach, liberally plagiarised from COBOL, except for handling raw bytestreams.

I've spent many hours with Ileff vectors, all that. I still can't
quite get Watcom C++ to let me get through the string game, but I'm
close.

Good luck.

C's string semantics are so divergent from BASIC's that this could be quite a tough port. If you are using a C++ string class then you are starting a little closer.

I think that's doable, and I know the file I/O bit is.

The file locking is actually a little sporty in C, as you will likely need to ... ugh ... write your own functions to call the native API [whatever that might be].

The Watcom library is quite helpful here, though. Just be aware that not all the exotic functions are available on all platforms, as they are not standard C.

PL/1(i), whatever, OS/2, Win-ugh, DOS .. and REXX, are they really suitable tools for poor Mikey?

It's PL/I.

Only you can answer the question. How you collect background information to formulate the answer is up to you. But you have been given information from the
two members of this echo who have the most experience with PL/I, and we both know/knew C too. I also know C++ quite thoroughly. And I dabble in REXX a bit, too. ... :-)

Regards

Dave
<Team PL/I>

--- FleetStreet 1.25.1
* Origin: My other computer is an IBM S/390 (2:257/609.5)