[Coco] new problem with unpack

Wayne Campbell asa.rand at gmail.com
Thu Oct 31 14:27:25 EDT 2013


Well, the problem isn't what I was thinking it was. I removed DRPN from the
equation by packing it separately so that instruction would be small enough
to execute. That was when I realized that instruction was not executing at
all. The error is being generated by the system (or runb), not by my
program. I looked again at my code in instruction. The first instruction is:

PRINT #2,"Building Instruction Statements";

I thought, maybe that is the problem, and somehow #2 is not being
recognized by runb or the system as stderr. I replaced it with:

PRINT "buildSrc";

The same error occured. The first instruction is not being executed,
period. The error occurs as soon as an attempt to execute instruction is
made. Since instruction and hex$ both fit well under 8k and the data space
requirements for instruction are <8k, something else must be causing the
problem.

One change I made to make instruction smaller was I replaced 2 of the 3
records with only the variables needed to hold those fields, and passed the
fields from unpack. I thought, maybe runb doesn't like me trying to pass a
filepath number contained in a record. I changed unpack so it contained the
necessary variables, assigned those variables the necessary field values,
and passed just those variables. The same error occurs in the same place.

I know I can use a path number in a record field because I do it in every
procedure in unpack. The only difference here is, instead of passing the
entire record I am passing a specific field of the record. And now I am not
even doing that. I am assigning a different variable of the same type as
the field the value of the field, and passing that variable instead.

ERROR #201 (as the system displays it) is displayed by ErrorCodes as:

Error#: 201 ILLEGAL PATH NUMBER The path number is too large or you
specified a non-existent path.

since the error occurs when the first attempt to execute instruction is
made, instruction is small enough to fit in memory now, and the error
report is coming from the system (or runb) (and not through my program's
error trap system), I can only think that runb is the problem. I do not
know what to do about it.

Anyone out there have any ideas?

Wayne



More information about the Coco mailing list