In similar vein, we used to write the Basic variables used for each data
item in Image sets in comments in teh Master schema copy, so you knew what
was what. We tended to use separate variables, rather than merge strings,
but arrayed them as Tom has shown. FOr each base we also wrote standard GET,
PUT UPDATE code as GOSUBs and stored them as ASCII XEQ files.
The major problems were the lack of support for Long Ints as numerics, and
the need for conversions from Packed Dec to long float and back. If any body
is interested, we could maybe add sample code for such things to Wirt's
/basic stuff?

> ----------
> From:         Tom[SMTP:[log in to unmask]]
> Reply To:     Tom
> Sent:         Sunday, March 05, 2000 10:41 AM
> To:   [log in to unmask]
> Subject:      Re: HP3000 Basic Manuals
>
> Wirt Atmar wrote:
> >
> > Larry asks:
> >
> > > The second part of my email was, Where can I get an HP3000 Basic
> Manual?
> >
> > Because of these qualities, it makes an exceptionally good applications
> > programming language, particularly so for putting together
> user-interactive
> > screens that feed data to an IMAGE database(s).
>
> Growthpower is written in Basic. The Order Entry module alone is 40
> separate source-code segments.
>
> > What the Pocket Guide doesn't have is much information regarding how to
> > compile, invoke and chain BASIC programs -- or how to call the special
> > BASIC-IMAGE intrinsics (that material was in the old IMAGE manuals).
>
> Essentially, the same way you called them in other languages. The
> difference is that you preceed Image calls with an 'X' (such as
> *XDBOPEN). One thing that will bite you in the butt is calling *DBOPEN
> instead of *XDBOPEN. No error message is issued at all, your program
> just doesn't seem to be able to open the database.
>
> Undocumented Image errors are Errors 50 through 53. These mean that
> Basic doesn't have enough memory to complete the call (it's limit is
> 64k). In this case, consolidate code or split out code to another source
> module.
>
> There's no such thing as Data Structure in Basic. Each line is limited
> to about 240 bytes which means you MUST consolidate all fields with the
> same type together. An example is Growthpower's Sales Order Header set
> which has all strings first, followed by Short Reals, followed by Long
> Reals. Also, strings are limited to 254 bytes so Growthpower uses three
> string to hold all the string items and arrays to hold the short and
> long reals. Therefore a call to get an Order might be:
>
>  100 COM(1) B2$[36],W5$[210],W6$[224],W8$[216]
>  110 COM(1) INTEGER Z[10]
>  120 COM(1) REAL W5[27]
>  130 COM(1) LONG X5[25]
>  500 MAT Z=ZER
>
>
> 1000 *XDBFIND(B2$,"SOH;",FNI(1),Z[*],"SOH-NUMBER;",W5$[1;6])
> 1005 IF Z[1]=0 THEN DO
> 1010   *XDBGET(B2$,"SOH;",FNI(5),Z[*],"@;",W5$,W6$,W8$,W5[*],X5[*],"")
> 1015    IF Z[1]=0 THEN DO
> 1020      GOSUB 2000
> 1025      GOTO 1010
> 1030    DOEND
> 1035   REM Bail out if Unexpected Error
> 1040   IF Z[1]<>15 THEN 9700
> 1045 DOEND
>
> 9000 DEF INTEGER FNI(X)=X
>
> Parameters are always Base,Set,Mode,Status,List,Buffer [,Key]. The empty
> quote at the end of the XDBGET would be where the Key Value for a Mode-7
> Hashed Get would go.
>
> To compile is thus:
>
> :BASICOMP
> >CONTROL USLINIT,INIT
> >COMPILE SUSO
> >CONTROL SEGMENT=SUSO1
> >COMPILE SUSO1
>  .
>  .
>  .
> >E
> :PREP $OLDPASS,SUSO.PROG;MAXDATA=32000;STACK=26500
>
> It gets squirrelly with really large programs because you have to
> pre-Build the USL in Segmenter to be big enough.
>
> I wrote an MPEX macro that would take a list of Source Code files and
> build a complete Basic Compile Jobstream for it. That was two employers
> ago on a since-abandoned box but I think I can recreate it.
>