Hi,

(best viewed with a fixed width font)

>        export stub: b6.002ce76c P__PASCFERROR+$118
> * 2) SP=418529f0 RP=b6.002ccc80 P__FERR+$70
>   3) SP=418526b0 RP=b6.002d4648 P_WRITESTR+$334
>   4) SP=41852630 RP=b6.002d4300 ?P_WRITESTR+$8
>        export stub: 1fe.0003bf24 aif_port_open+$27c
>   5) SP=41852530 RP=1fe.0003bbf4 ?aif_port_open+$8

What's the outer block language...Pascal, or something else?

I'll predict: non-Pascal, and that the problem is that you didn't
get the Pascal I/O and/or string initialization stuff.
OTOH, I'm not as familiar with this problem as I could be, because
of suggestions 1, 2, and 3 below :)


> How do I get this program to display the messages like your average COBOL
> program does so easily?

#1: don't use Pascal I/O.
#2: don't use Pascal I/O.
#3: see #1 and #2 above.

(I've been advising that for 20+ years :)

Pascal I/O is **SLOW** and trouble-prone.

(We'll come back to Pascal I/O further below.)


> $standard_level 'hp_modcal'$
> $optimize on$

Get rid of the optimize until you've fully, 100%, and totally debugged
your program.


> program aif_port_open (output);

Get rid of "output" (if you follow my advice about dropping Pascal I/O)


BTW,  http://www.allegro.com/papers/htpp.html
is required reading for all Pascal programmers :)


> procedure aif_port_open(var overall_status:status_type;

You'll find yourself better served to name your routine something
other than "aif_port_open" ... that name is far too similar to "aifportopen",
such that the skilled reader will be fooled when they see your procedure name.
You might consider something like:  create_my_aif_port, or some such ... a
name that indicates to the reader that this is *your* routine, not one of
MPE's AIF routines.

> begin
>    GETPRIVMODE;

Argh!  Email me offline about the above.


>    itemnum_ports        := init_itemnum_array;
>    item_ports           := init_item_array;
>    item_status_ports    := init_item_status_array;

Hmm...I didn't see any local declarations for these
variables (nor a "..." indicating they might have been
elided).

If this is the only routine that uses some of the variables,
like item_ports, why not make them local so their storage
disappears upon exit from this routine?


>    writeln ('start HPGETPROCPLABEL');

Ok...on replacing Pascal I/O:


  type
     str16  = string [16];
     str256 = string [256];    {or whatever size your max write wants to be}

  Function  dascii : shortint;   intrinsic;
  Procedure print;               intrinsic;

  function num32 (n : integer) : str16;
       {e.g.: num32 (123) --> '123'}

     var
        len : integer;
        s   : str16;

     begin

     setstrlen (s, dascii (n, 10, s));

     num32 := s;

     end {num32 proc};

  procedure spout (s : str256);

     begin

     print (s, - strlen (s), 0);

     end {spout proc};

  procedure spoutstop (s : str256);

     begin

     print (s, - strlen (s), octal ('320'));

     end {spoutstop proc};


Usage:

           Old                         New

   writeln ('hello')              spout ('hello')
   write ('wait...')              spoutstop ('wait...')

   writeln ('ktr = ', ktr:1)      spout ('ktr = ' + num32 (ktr));

I have a suite of "formatting" routines to convert numbers (16-bit,
32-bit, 64-bit, signed/unsigned) to decimal, hex, octal, with and
without formatting (e.g., "I want this number to take 9 spaces,
with leading blanks"), and other routines to convert pointers,
dates, times, into Pascal strings ... I'm sure you'll create
your own such library.

Of course, the drawback is that the New version of the software
will run a bit faster, will be easier to port to other
languages, and is less vulnerable to run-time problems :)

HTH,

Stan
--
Stan Sieler
[log in to unmask]
www.allegro.com/sieler/wanted/index.html

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *