Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!taco!hobbes.catt.ncsu.edu!kdarling From: kdarling@hobbes.catt.ncsu.edu (Kevin Darling) Newsgroups: comp.os.os9 Subject: Re: Can't execute "J" - Error #000: 216 Message-ID: <1991Jun15.001249.5963@ncsu.edu> Date: 15 Jun 91 00:12:49 GMT References: <1991Jun14.202821.20308@unhd.unh.edu> Sender: news@ncsu.edu (USENET News System) Organization: North Carolina State University Lines: 26 ram@kepler.unh.edu (Richard A Messner) writes: >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 >they have been compiled on my machine [...] 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