Can't execute "J" - Error #000: 216
Richard A Messner
several times when trying to execute precompiled binaries for OSK. There
is no specific binary that gives this problem. They all seem to do it unless
they have been compiled on my machine (for example, the binary for C-Kermit
on smilodon.cs.wisc.edu causes this error). Does anyone know what the problem
is? I can't find a file named J anywhere in the standard directories.
The system in question is a Motorola MVME-133A-20 running Professional
OS-9/68020 version 2.2. Thanks.
Kevin Darling
>I have encountered the above error ('Can't execute "J" - Error #000:216')
>several times when trying to execute precompiled binaries for OSK. There
>is no specific binary that gives this problem. They all seem to do it unless
This one gets everyone at times :-). As you know, when the shell executes
a command line, it looks first in memory for the module... then in your
current execution directory (usually /dd/cmds)... then it looks for
an ascii shell script in your current data directory.
That last scenario is the culprit. When you compile your own binaries,
you're probably letting them default to ending up in your execution dir.
No problem there. But when you download, you're probably leaving a file
in your current data directory and trying to call it by name from there.
Thus by the time the shell looks there, it thinks it must be a script. Now,
the first bytes in a module header are $4A FC, right? The FC serves
as a delimiter, and $4A = "J". So shell tries to execute the command "J"
according to the "script file" it just found :-) :-).
And since it can't find "J", you get this bogus (not really) error.
Solution: set the exec attributes and copy the file to your cmds dir...
or, use a full pathname to call it (eg: /dd/downloads/newcmd ).
best - kevin <kdar...@catt.ncsu.edu>
James Jones
Check the attributes of the files you're trying to execute. The "can't
execute 'J'" message is from the shell, which, after trying other possibil-
ities, is trying to run the executable as a shell script! (Dump the file
and see what the first byte looks like. :-) You should set the execute
attributes of the file and try again.
James Jones
bal...@urz.unibas.ch
You have to place the executable file in your default execution directory
(you max change this with the chx command) or set the directory, in which
your binary resides, in the environment variable PATH. You could alternally
load the file with load -d filename prior to execution.
J is the first byte of all OS-9 executables, dump a few and you'll see..
- Marc
BTW: Error 216 means "File not found"
Walter Lloyd Wimer III
kdar...@hobbes.catt.ncsu.edu (Kevin Darling) writes:
> And since it can't find "J", you get this bogus (not really) error.
Hmmmm. . . . Someone should write a real executable program named "J"
which sits in the execution directory and prints out an appropriate
error message when invoked. . . . ;-)
Walt
Arthur T. Manning
to put ftp in binary mode.
--
Arthur T. Manning <man...@halley.est.3m.com>
3M Center 518-1 St Paul MN 55144-1000 \___/______
ph. 612 733-4401 fax 612 736-3122 __ / _ _ _ \
Allin1--> <MANNING @MRGATE @EST780> (_/_/_/ / / /_/ <><
bal...@urz.unibas.ch
Whenever the u-ware OS-9 shell tries to execute a file (programs are files...)
it searches in the current execution directory. If a file is not found in it,
the shell then searches every directory in the environment variable PATH for
the file. And at last it looks in the current directory for a shell-script
(not for a binary, executable file!). The shell tries to execute the "J"
because every OS-9 programs begins with it.
Someone proposed to write a program called "J" which would be executed in
this case. The programm J will actually execute, the problem is that the
shell tries to execute the next bytes of the binary file. You then get an
error message like "Error 216: can't execute verflow".
The best solution is, to put your directory in the environment variable
PATH, so all binaries will execute.
- Marc
Pete Lyall
standard input... a good suggestion (Kev - where have I seen that
before.. grin)...
Another alternative... If the OSK shell works like the OS9/6809 shell,
when a procedure file is run, a child shell is forked from the
original shell with its standard input redirected from the alleged
script/procedure file. The 'J' command could simply get a copy of its
process descriptor (F$gprdsc, or whatever), determine its parent's
process ID (the secondary shell's ID), and it could send a KILL
signal, terminating the erroneously spawned 'procedure' shell.
Pete
--
Pete Lyall [GTE] Compuserve: 76703,4230 Internet: pe...@wlbr.imsd.contel.com
UUCP: {hacgate,jplgodo,voder}!wlbr!pete
"... So I picked up my pride from beneath the pay phone, and combed his breath
right outta my hair. And sometimes, it's not so easy ..." J. Hendrix/My Friend
Tony Mountifield
> Someone proposed to write a program called "J" which would be executed in
> this case. The programm J will actually execute, the problem is that the
> shell tries to execute the next bytes of the binary file. You then get an
> error message like "Error 216: can't execute verflow".
This wouldn't happen if the program called "J" returned a non-zero exit
status (e.g. 1). That would cause the shell to stop reading the "script".
--
Tony Mountifield. | Microware Systems (UK) Ltd.
MAIL: to...@mwuk.uucp | Leylands Farm, Nobs Crook,
INET: tony%mwuk...@ukc.ac.uk | Colden Common, WINCHESTER, SO21 1TH.
UUCP: ...!mcsun!ukc!mwuk!tony | Tel: 0703 601990 Fax: 0703 601991
**** OS-9, OS-9000 Real Time Systems **** MS-DOS - just say "No!" ****
Kevin Darling
>Someone proposed to write a program called "J" which would be executed in
>shell tries to execute the next bytes of the binary file. You then get an
>error message like "Error 216: can't execute verflow".
Good point. The shell will execute "J", and then try to use the next bytes
(after the max readln point, or after a $0D seen as readln delimiter) in the
originally named binary file (which shell thought was a script file)
as a new script line.
This brings up a neat trick with shell scripts tho. The thing to remember
is that whenever a script line is executed, the standard input of the called
program (assuming no "<" redirection is done) is the file itself... which
in this case is the binary module!
Thus the program called "J" has a standard input conduit to the binary file.
Now all it has to do is to Seek its standard input path (0) to the end of
the binary, and voila... when J ends, its parent shell thinks the "script"
is at the end of file and exits. In BASIC, such a program would be...
PROCEDURE J
DIM modsize:INTEGER
SEEK #0,4 \ (* seek to module size location in header
GET #0,modsize \ (* read in module size
SEEK #0,modsize-1 \ (* seek to end of module/"file"
PRINT "You are trying to execute a module"
PRINT "from within your current data dir "
END
The J program could even look up the name of the target binary, and
perhaps load and/or execute it.
This standard input trick also allows you to write commands which loop
and do other "goto"-ish moves within a script file... by doing a Seek
to wherever you'd like your calling shell to continue from.
The simplest example is a program which repeats the script file:
PROCEDURE rewind
SEEK #0,0
END
Put that at the end of your script, and it'll execute over and over.
best - kevin <kdar...@catt.ncsu.edu>
Kevin Darling
>
>Why not just exit with a status of 1? (See previous discussion about how this
>terminates the shell procedure with no message.)
But...but...but, Bob! That's too easy! :-) :-)
Jeeeez. And you don't learn any neat tricks that way, either.
<grinning> regards - kev <kdar...@catt.ncsu.edu>
Pete Lyall
shell can be told to ignore an errant process and continue (-x in 6809
land), but in this one case, the 'procedure' shell was invoked
accidentally, and wouldn't have been told to ignore errors.
bal...@urz.unibas.ch
I suggest the following: The program J seeks to the beginning of its standard
input, then loads his standard input to a module (or saves it to temporary
file) and tries to execute the module or the temp. file.
I did not try it, but I'm sure we could get this running.
- Marc
blarson@blars
>Kevin Darling suggest having the 'J' command eat up all of the
>standard input...
>send a KILL
>signal [to the parent], terminating the erroneously spawned 'procedure' shell.
Why not just exit with a status of 1? (See previous discussion about how this
terminates the shell procedure with no message.)
--
bla...@usc.edu
C news and rn for os9/68k!
--
Bob Larson (blars) bla...@usc.edu usc!blarson
Hiding differences does not make them go away.
Accepting differences makes them unimportant.
Mark J. Sienkiewicz
>Hmmmm. . . . Someone should write a real executable program named "J"
>which sits in the execution directory and prints out an appropriate
>error message when invoked. . . . ;-)
Actually, this usually happens because the OS9 shell didn't want
load the executable in the first place. (Usually, it is not executable
or something like that.) You should have the "J\374" (the real name
it was looking for) figure out what file it was invoked from and
EXECUTE the file as an object module.
I figure this is possible, but I don't have time to work on it. Anyone
care to try this?
Mark.