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

[Dave Froble]

On 11/8/2019 8:23 AM, seasoned_geek wrote:
> On Thursday, November 7, 2019 at 10:35:45 PM UTC-6, Dave Froble wrote:
>> 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:
>>>>
>>>
>>> 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" ?
>
> It means "We were paid to tell you to buy something else."
>
>>
>>> 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.
>
> Then you were looking at the cute butt across the street as you ran over the woman and the baby caraige.

Well, cute butts are nice to look at, right?  Better done from a bench 
than a moving vehicle, perhaps.

> The power of the XML parser is enforcing an XML Schema on incoming messages, mostly for security, secondarily for ease of change. With a tool like Xerces you can completely change your XML schema without having to modify your code, just replace the schema file.
>
>>
>> Note, perhaps there may be products that actually extract your data, but
>> we never saw one.
>>
>> I'm guessing that they still had to have code to actually extract the data?
>
> See your comment later about people looking to buy someone else's tool.
>
>>
>>> 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?
>>
> That was the early 1980s, before the Gartner Group was paid to market "right sizing" and "off-shoring" as trendy crimes all management should be involved in.

Yes, TOLAS design and implementation started in the mid 1970s.

>>> 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 ...
>
> No. The problem wasn't as you state. Users of Microsoft development tools, VB in particular, are universal idiots. They have to have a GUI development environment with pick & point letting .Net do everything for them. None of them have taken a class in logic.

Yeah.  The competence to do something without point-and-click ...

>>> 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.
>>
> TOLAS isn't the accounting system. That's on an IBM mainframe. The department used to be located down in Knoxville.
>
> Reasonable != SEC reporting and auditing requirements for a multi-billion dollar publicly traded company. They bought something the auditors and SEC blessed long ago. Was in place before TOLAS.
>
>>> 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.
>
> I don't know what you mean here. We weren't modifying TOLAS. That was a completely independent system receiving data from 5 completely different outside sources which only needed to pull a tiny bit of pricing data from TOLAS before running an independent "inventory forecasting" (really hand polished turd) system which then generated suggested stock orders.

Sorry, I assumed (bad habit) we were discussing working on the TOLAS 
product.

>>> 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.
>
> Kind of like your previous expectations of an XML parser.
>
> Messaging is simple only if one takes the Linux/PC/Windows brain dead mentality of "oh well, those messages are gone." When you have to have 100% delivery with 100% execution of all messages, even those in process during a hard crash, without manual intervention, THAT is when you have to use MQ Series and ACMS. No other combination can get you that. None.

With a proper protocol messaging is simple.  Now, the implementation can 
be a bit more complex, having to monitor and adjust to communication 
failures and such.

1) Hey, I got a message for you, it is 99 bytes of data
2) Ok, I'm here, send the message
3) send the message and wait for a response, with timeout
4) Ok, I got 99 bytes of data
5) consider the message complete, remove from queue

If at any step there is a failure, go back to step #1

Lots of details omitted, but, the concept is simple.

Note that what the recipient does with the data is outside the 
messaging.  Security is outside the messaging.

> With the Gartner Group being paid to declare all things VMS "non-strategic" and Keller MBAs like those at Navistar actually paying to be fed this marketing scam, some/many/several other be-all-end-all order processing systems whose vendors paid Gartner to market their product as "strategic" to their customers have been brought in. They have all failed. They have all lost large numbers of orders thus violating the business mandate.

Beancounters many times don't have a clue about what they are doing.

>>> 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?
>
> Because this wasn't TOLAS and "fine menu utility" is not exactly the phrase I would use for it.

Now that hurts, I designed and implemented the original version of that 
utility.  Don't know what may have been changed.


-- 
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