f



CP/M 3 program return code

I have an application that supports program return codes.  Values 0 and 1 are
reserved for 'normal' and 'abnormal' termination respectively.  Other values are
at the programmer's discretion.

The application supports Z-System and CP/M 3 - both of which permit program
return codes.  Z-System supports values 0..255 so I just send the code as is.

Currently I'm doing the same for CP/M 3 ... however the entry for BDOS 108 states:

Table 3-5. Program Return Codes

Code                        Meaning

0000 - FEFF            Successful return
FF00 - FFFE           Unsuccessful return

0000                        The CCP initializes the Program Return Code to zero unless
                                the program is loaded as the result of program chain.

FF80 - FFFC          Reserved
FFFD                     The program is terminated because of a fatal BDOS error.
FFFE                     The program is terminated by the BDOS because the user
                               typed a CTRL-C.

Since 0000 - FEFF is considered "successful" by CP/M should I instead be
mapping codes in the range 1..127  to  FF01..FF7F ?

Does anyone know of CP/M 3 applications that support program return code?
I'd be curious to know how they handle it.





0
Ed
11/14/2016 3:10:35 AM
comp.os.cpm 3422 articles. 0 followers. Post Follow

12 Replies
307 Views

Similar Articles

[PageSpeed] 15

I never used return codes for CP/M, I did for DOS.  It normally is used in batch processing.  DOS and Unix lets you do conditional execution in batch files which is very handy.

I do not know if submit has such abilities, if not then error codes would be much more limited in CP/M.


Randy
0
randy482
11/14/2016 4:02:37 AM
The CCP of CP/M 3 supports conditional execution by prefixing a command with the ':' character.

If the previously executed command termines with a success code, the :command will be executed, otherwise not.

Then, we could do:

if mydoc.txt exists
:edit mydoc.txt

Unfortunately, the error code is cleared after the first :command.

There is a published patch for the CCP to solve that problem.
0
Floppy
11/14/2016 7:37:18 AM
On Monday, November 14, 2016 at 4:10:45 AM UTC+1, Ed wrote:

> Does anyone know of CP/M 3 applications that support program return code?
> I'd be curious to know how they handle it.

There is a UNIX like make for CP/M 3 and for working it needs
return codes of course, so one should set them appropriate in
applications. Excerpt from the manual page:


       BUGS
                The -i option is opposite of "normal" so that error codes
                are normally ignored.  If the -i option is used, colons
                will proceed commands that aren't to execute after an
                error.  This sortof almost works in CP/M Plus.  To be
                made to work three things need to be done. 1) an RSX
                written that makes a compiler(etc) set the error flag (should
                be easy to do). 2) Keep CP/M 3.0 and/or the CCP from resetting
                the error flag on each command that is executed (patch
                somewhere?), and 3) Let the ":" exclusion work in front
                of .SUB files as well as .COM files (patch somewhere?). 
                Discription of the ":" is in the CP/M Plus Programmer's
                Guide in the description of bdos function 108.

0
Udo
11/14/2016 10:34:02 AM
Hi Udo,

Obvious question: what Unix like are you talking about?

That's very interesting for me.

Thanks.
0
Floppy
11/14/2016 6:43:11 PM
On Monday, November 14, 2016 at 7:43:11 PM UTC+1, Floppy Software wrote:
> Hi Udo,
> 
> Obvious question: what Unix like are you talking about?
> 
> That's very interesting for me.
> 
> Thanks.

None, for CP/M 3 someone familiar with UNIX systems wrote a make utility, which won't
work too well, see BUG section from the manual.

The early UNIX like systems for 8086 systems like Coherent, Minix etc. all had a working
make of course, because the UNIX API is much clearer about return codes, time stamps and such.
0
Udo
11/14/2016 7:19:26 PM
On 11/14/2016 02:19 PM, Udo Munk wrote:
> On Monday, November 14, 2016 at 7:43:11 PM UTC+1, Floppy Software wrote:
>> Hi Udo,
>>
>> Obvious question: what Unix like are you talking about?
>>
>> That's very interesting for me.
>>
>> Thanks.
>
> None, for CP/M 3 someone familiar with UNIX systems wrote a make utility, which won't
> work too well, see BUG section from the manual.
>
> The early UNIX like systems for 8086 systems like Coherent, Minix etc. all had a working
> make of course, because the UNIX API is much clearer about return codes, time stamps and such.

FYI: There's a workable version of 'make' for CP/M 2.2 (written in BDS C).  It 
was supplied as a contributed application with Bridger Mitchell's 
'DateStamper' system extension.  I used it to manage the build of a fairly 
complex application written in a mix of Modula-2 and Z80 assembler.  There was 
something odd about its original behavior that I had to patch (don't recall 
what), but once you get used to its quirks it works great.

Even though it was designed for DateStamper it could probably be easily 
adapted to work with CP/M 3.


0
Steven
11/15/2016 12:40:33 AM
Floppy Software wrote:
> The CCP of CP/M 3 supports conditional execution by prefixing a command with the ':'
> character.
>
> If the previously executed command termines with a success code, the :command will be
> executed, otherwise not.
>
> Then, we could do:
>
> if mydoc.txt exists
> :edit mydoc.txt
>
> Unfortunately, the error code is cleared after the first :command.
>
> There is a published patch for the CCP to solve that problem.

Thanks.  Is this an official patch as I'm not seeing it CP/M 3 DRI patches 1 to 18?
Where is it available?

I'll need to do some more testing.  Once I work out what the patch does I'll be
in a better position to decide whether or not to remap non-zero return codes.
At the moment the only way I can see to pass return codes to another program
is via 'program chain' (BDOS 47).  The problem with that is it completely
bypasses the normal exit routine of my program - not something I want to do.





0
Ed
11/15/2016 2:24:05 AM
On Tuesday, November 15, 2016 at 3:24:18 AM UTC+1, Ed wrote:

> Thanks.  Is this an official patch as I'm not seeing it CP/M 3 DRI patches 1 to 18?
> Where is it available?

Fixed in the Caldera release of the CP/M 3 sources:

  WHATS-NEW    


  All the  CP/M 3  patches  described in the  document  CPM3FIX.PAT 
  have  been  applied to the source code,  except those relating to 
  INITDIR. Patches applied were nos. 1-18, except nos. 5 and 9.

  CP/M 3  is  now  fully  Year  2000  compliant.  This  affects the 
  programs DATE.COM, DIR.COM and SHOW.COM.

  Dates can be displayed in US,  UK or Year-Month-Day format.  This 
  is set by SETDEF.

  The CCP has a further bug fix: A command sequence such as:

  C1
  :C2
  :C3

  will now not execute the command C3 if the command C1 failed.

0
Udo
11/15/2016 2:34:40 AM
Udo Munk wrote:
> On Tuesday, November 15, 2016 at 3:24:18 AM UTC+1, Ed wrote:
>
> > Thanks.  Is this an official patch as I'm not seeing it CP/M 3 DRI patches 1 to 18?
> > Where is it available?
>
> Fixed in the Caldera release of the CP/M 3 sources:
>
>   WHATS-NEW
>
>
>   All the  CP/M 3  patches  described in the  document  CPM3FIX.PAT
>   have  been  applied to the source code,  except those relating to
>   INITDIR. Patches applied were nos. 1-18, except nos. 5 and 9.
>
>   CP/M 3  is  now  fully  Year  2000  compliant.  This  affects the
>   programs DATE.COM, DIR.COM and SHOW.COM.
>
>   Dates can be displayed in US,  UK or Year-Month-Day format.  This
>   is set by SETDEF.
>
>   The CCP has a further bug fix: A command sequence such as:
>
>   C1
>   :C2
>   :C3
>
>   will now not execute the command C3 if the command C1 failed.

What's supposed to happen in the following when C1 sends an
'unsuccessful' code - does C2 see the error, or has the CCP
already cleared it?  I assume the latter - hence the need for a
'chain program' command.

    C1
    C2

-----

The way I intend to handle my program's return code (0 to 255) under
CP/M 3 is to invert the bits only for non-zero values.  Thus codes 1..255
get mapped to $FFFE..FF00 and passed to BDOS 108.  CP/M 3 then
sees return code 0 as success and 1..255 as fail - which is the same
as Z-System's handling of program return code (AFAIK).



0
Ed
11/16/2016 8:47:32 AM
On Wednesday, November 16, 2016 at 9:47:57 AM UTC+1, Ed wrote:

> What's supposed to happen in the following when C1 sends an
> 'unsuccessful' code - does C2 see the error, or has the CCP
> already cleared it?  I assume the latter - hence the need for a
> 'chain program' command.
> 
>     C1
>     C2

Any shell clears the return code before starting another external program,
so yes, C2 cannot see the return code from C1. The return code from C1
can only be used by shell internals before starting any other program,
in the CP/M 3 CCP this is limited to the : internal.
0
Udo
11/16/2016 12:25:21 PM
From John Elliott's web page:

"
BDOS function 108 (P_CODE) - Get/put program return code

Supported by: CP/M 3 and above.

Entered with C=6Ch, DE=code. Returns HL=code.

If DE=0FFFFh, then the current code is returned in HL. Otherwise, it is set to the value in DE. Allowable values are:

00000h - 0FEFFh
No fatal error
0FF00h - 0FF7Fh
Fatal error
0FF80h - 0FFFCh
Reserved
0FFFDh
Program terminated because of a hardware error.
0FFFEh
Program terminated by Control-C.
If a program was chained by function 47, an error code stored by the previous program will be available to it. Otherwise the CCP sets the return code to zero when it executes a program (some replacement CCPs do not do this).
If the error code is 0FF00h or above, and the next command begins with the character : then it will not be run.

"
0
Floppy
11/16/2016 2:26:58 PM
Ed wrote:
> ...
> The way I intend to handle my program's return code (0 to 255) under
> CP/M 3 is to invert the bits only for non-zero values.  Thus codes 1..255
> get mapped to $FFFE..FF00 and passed to BDOS 108.

Unfortunately this didn't work because in the case of $FFFE (corresponds
to my return code 1) the CCP hijacks it for its own use.  A pity.

The new strategy is to map codes 1..255 to $FF7F..FF00 which CCP will
treat as 'unsuccessful'.  Code 0 is sent unchanged.  Because of the folding,
codes 0..255 can be used but only 0..127 will be unique.

To get around the chaining problem (I can't use it) I read CCP105P has an
assembly-time option that stops CCP resetting the code between programs.
Unfortunately the supplied CCP.COM causes MYZ80 to hang so I've
postponed further investigation for now.



0
Ed
11/17/2016 5:03:29 AM
Reply: