I'm trying to get some code working to open a file (for writing). Initially, it was failing with a 0600115 error (GJFX33: Filename was not specified) and tracked that down to having the address of a char array in r2, rather than a byte pointer.

So I tried passing a proper byte pointer in r2; it still fails but with a code of 2. (I haven't found any documentation of an error code 2.)

When I read the TOPS-20 Monitor Calls Reference Manual regarding the GTJFN call, it isn't quite clear to my noob-ish self whether r2 is supposed to *contain* the byte pointer, or the *address* of the byte pointer.

I tried the latter, as well, and got 0600115, again.

It also isn't mentioned whether the byte pointer needs to be 6-bit, 7-bit, 8-bit, etc. I've tried 8-bit.

Does anyone remember how to do this?

-+- Sid

On Thursday, August 3, 2023 at 11:31:46 AM UTC-7, Sid Maxwell wrote:
> I'm trying to get some code working to open a file (for writing). Initially, it was failing with a 0600115 error (GJFX33: Filename was not specified) and tracked that down to having the address of a char array in r2, rather than a byte pointer.
>
> So I tried passing a proper byte pointer in r2; it still fails but with a code of 2. (I haven't found any documentation of an error code 2.)
>
> When I read the TOPS-20 Monitor Calls Reference Manual regarding the GTJFN call, it isn't quite clear to my noob-ish self whether r2 is supposed to *contain* the byte pointer, or the *address* of the byte pointer.
Short form or long form?

Otherwise, TOPS-20 uses 7 bit ASCII.

Sid Maxwell <srmaxwell3@gmail.com> writes:

> I'm trying to get some code working to open a file (for writing). Initially,
> it was failing with a 0600115 error (GJFX33: Filename was not specified) and
> tracked that down to having the address of a char array in r2, rather than a
> byte pointer.

> So I tried passing a proper byte pointer in r2; it still fails but with a
> code of 2. (I haven't found any documentation of an error code 2.)

> When I read the TOPS-20 Monitor Calls Reference Manual regarding the GTJFN
> call, it isn't quite clear to my noob-ish self whether r2 is supposed to
> *contain* the byte pointer, or the *address* of the byte pointer.

> I tried the latter, as well, and got 0600115, again.

> It also isn't mentioned whether the byte pointer needs to be 6-bit, 7-bit,
> 8-bit, etc. I've tried 8-bit.

There's your problem.

On TOPS-20, all ordinary text is encoded as 7 bit bytes containing ASCII
characters. In monitor calls, a 7 bit byte pointer has a shorthand form

-1,,<address of zero terminated ASCII string>

The pointer in AC2 is usually encoded as follows:

HRROI 2,[ASCIZ/DEVICE:<DIRECTORY.SUBDIRECTORY>FILENAME.EXTENSION/]

where the device and directory specifications default to the currently
connected directory. Depending on whether you are looking for an existing file
(GJ%OLD) or are creating a new file (GJ%NEW), the generation will default to 0
or -1. You can specify the generation in the filename if you need to.

> Does anyone remember how to do this?

Every day. Still writing Macro-20 for a living.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

> Short form or long form?

Short.

> Otherwise, TOPS-20 uses 7 bit ASCII.

I'm learning....

> There's your problem.
>
> On TOPS-20, all ordinary text is encoded as 7 bit bytes containing ASCII
> characters. In monitor calls, a 7 bit byte pointer has a shorthand form
>
> -1,,<address of zero terminated ASCII string>
>
> The pointer in AC2 is usually encoded as follows:
>
> HRROI 2,[ASCIZ/DEVICE:<DIRECTORY.SUBDIRECTORY>FILENAME.EXTENSION/]

This was the critical clue, Rich, and thanks! I'd seen an example with the HRROI, but told myself "that doesn't make a byte pointer!".

Next I need to figure out why the written data is gibberish! :-D

> > Does anyone remember how to do this?
> Every day. Still writing Macro-20 for a living.

I'd love to hear more about what you're doing and for whom.

On Friday, August 4, 2023 at 2:23:04 PM UTC-4, Sid Maxwell wrote:
> This was the critical clue, Rich, and thanks! I'd seen an example with the HRROI, but told myself "that doesn't make a byte pointer!".

Yeah, there is a test in the monitor's JSYS code to test for -1 in the left half of an argument register
and swap in 440700 for the -1

If you look at the exec sources, there are zillions of the
HRROI T1, FOO

On Saturday, August 5, 2023 at 6:43:21 PM UTC-7, fishtoprecords wrote:

(snip)
> Yeah, there is a test in the monitor's JSYS code to test for -1 in the left half of an argument register
> and swap in 440700 for the -1
> If you look at the exec sources, there are zillions of the
> HRROI T1, FOO

Pretty neat. One test in the monitor saves many instructions other places to load the 440700.

I an wondering about any similar user conveniences in OS/360.

One problem with OS/360, is that there were code byte quotas when it was
being written, to keep OS size down. That lead to decreased OS size, at the expense
of user program size, the opposite of this case.