[Info-vax] Any Way to Pass Arrays of Strings from C to Basic?

[Dave Froble]

On 11/7/2019 11:40 AM, seasoned_geek wrote:
> On Wednesday, November 6, 2019 at 9:11:46 PM UTC-6, Craig Dedo
> wrote:
>> This project requires communication between two unlike information
>> systems that are written in different languages.  The only thing
>> that they have in common is that both systems run under the same
>> version of the OpenVMS operating system.
>>
>> The accounting system is TOLAS and is written in Basic.  It uses
>> RMS indexed files for its data storage, not a relational database
>> system.
>>
>> The inventory system for managing the inventories at the
>> dealerships is a home-grown system called the Dealer Inventory
>> Alliance (DIA).  It is written in C and uses 6 different RDBMSes
>> for its data storage.
>>
>> Why is DIA written in C?  Ask Roland Hughes, aka, seasoned_geek.
>> The old-timers told me that he made that decision.
>
> Nope.
>
> Accenture and The Gartner Group whispering into the ears of upper
> management declared BASIC "non-strategic".

I've never seen anything that justified these people (Gartner) claiming 
to have any worthwhile knowledge.  Well, perhaps the knowledge to 
separate people and their money.

I'd really like to know just what they mean by "non-strategic" ?

> The only portion which
> needed to be in C was the piece which originally called Xerces XML
> parser which was, at the time heavily supported by IBM. There was a
> correct decision all XML parsing should be done by an industry
> standard library.

A while back we looked at several XML parsers.  When done looking, we 
looked at each other and basically said WTF?  The products would test 
some XML for matching tag pairs, but nothing else we could see.  One 
thing they didn't do was parse out the actual data that we needed. 
That, we still had to custom program.  Have to wonder just what these 
bloatware products are good for?  Nothing we could see or justify.

Note, perhaps there may be products that actually extract your data, but 
we never saw one.

> Xerces then got used by many other systems at the
> company. Management didn't want a one-off roll-your-own parser they
> would have to support for decades so it was a legitimate decision.

I'm guessing that they still had to have code to actually extract the data?

> The industry standard library would be continually updated and
> supported given the heavyweights behind it.
>
> The other big push was if they used C/C++ they would be able to have
> the system supported by off-shore/visa workers for far less than
> market rate.

Got to wonder why they purchased a made-in-USA software product?

> At the time, you could teach a PC C programmer how to program on VMS
> ala the book you own. Given how far behind the C compiler fell, that
> was less and less of a reality.
>
> The company had already tried training Visual Basic programmers how
> to write VAX BASIC in EDT and that met with repeated failure.

Perhaps the problem was the VB programmers they started with. 
VAX/DEC/??? Basic is very easy to use.  But, of course, one must first 
be competent ...

> TOLAS isn't the accounting system, it's the order processing system.
> It feeds the accounting system which used to be on an IBM mainframe.

I was long gone from Transcomm when Navistar became a customer.  Don't 
know what parts they purchased or used.  But, TOLAS does have some 
reasonable accounting software.  A/R, A/P, G/L, and such.  I was the 
architect for much of the earliest versions of TOLAS.  Dan Rosen and 
Charlie Eckhaus also were deeply involved.

> Choice of language did not matter to most of the development team as
> we worked with them all. FORTRAN-90 was even considered for some time
> because there were many FORTRAN developers in the various engineering
> groups and FORTRAN-90 had great string handling capabilities. In the
> end, management wanted to use a language where they could find the
> lowest wage workers anywhere in the world, so C/C++ was selected.

Somehow I have to figure that using other than the implementation 
language caused problems.

> The only other real consideration was the mandate from upper
> management that all messages have both guaranteed delivery and
> guaranteed execution with throttle control. This mandated the tool
> set of MQ Series feeding ACMS servers. No other tool set on the
> platform could deliver that. Routing things to batch jobs meant data
> could and would be lost as had happened in the past with other
> systems.

Messaging is rather simple, but, it seems all anyone wants to do anymore 
is find someone else's tool to do the job, regardless of fit.

> The menuing and reporting portion of that system along with some of
> the bulk processing was originally done in Cognos PowerHouse because
> a justification could not be made for consuming developer time with
> what would mostly be one-off reporting.

TOLAS came with a fine menu utility.  Got to wonder why it wasn't used?

> Somewhere there is a big pile of documentation covering the design
> and architecture of the system you are working on. The system flow
> diagram had to be printed on an engineering plotter which used paper
> rolls. It printed pages about 3 feet wide by 4 or 5 feet long. The
> entire diagram had to be taped together because it was 2 high and 3
> or 4 sheets wide. It was even color coded identifying which group was
> responsible for what. At the time it was created it was an
> architectural marvel, pulling at least 6 companies forward two
> decades in technology. It took a small, dedicated team 3 years to get
> it all the way through to production and it spanned multiple
> countries.

That's impressive.  Documentation?  Most never heard of it.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486