Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

lex on OpenVMS?

 
Mark Katz
Advisor

lex on OpenVMS?

Old piece of software (we have all the source code) that needs to be ported to Alpha and eventually IA64.

That software uses lex from the VAX DEC/Shell product. There are two lex source files, one relatively simple and the other fairly complex. Due to the use of DEC/Shell, this software runs on one of our few remaining VAXen. Even though the source is frozen and the C intermediate is thus fixed, it requires SHELLRTL which is not available for Alpha/IA64 so porting the C intermediate code by hand doesn't help.

DEC/Shell is obsolete.

Optional POSIX facility has come and gone (not sure if it ever included lex anyhow).

I see that lex is in the the future vision for GNV but it doesn't appear to be part of the latest GNV. Even if it was, our customer is adamant that no freeware/open source be used, so it would be out anyway.

Also see references to FLEX on some freeware CD but no freeware so can't use it either.

So, does anyone know of any real, commercially available version of lex that will run on OpenVMS Alpha and IA64? Not holding out much hope here - not a real moneymaker for anyone.

Or, we recode the lex stuff in something else (maybe TPU) that will remain supported for a while at least. Not an exciting prospect - remember I said one source was simple but one was complex.

Looking for anyone with other possibilities to look at.

Thanks,
Mark

12 REPLIES 12
Steven Schweda
Honored Contributor

Re: lex on OpenVMS?

> Also see references to FLEX on some
> freeware CD but no freeware so can't use it
> either.

I'd work on a more reasonable policy for
software acquisition.

> I see that lex is in the the future vision
> for GNV [...]

What's the "G" for in "GNV". From where do
you think that that "lex" will be coming?
Mark Katz
Advisor

Re: lex on OpenVMS?

>> Also see references to FLEX on some
>> freeware CD but no freeware so can't use it
>> either.

>I'd work on a more reasonable policy for
>software acquisition.

He who holds the purse strings makes the policy and the purse has many years of coin in it. Policy ain't gonna change.

>> I see that lex is in the the future vision
>> for GNV [...]

>What's the "G" for in "GNV". From where do
>you think that that "lex" will be coming?

Not sure if this is a serious question but this URL is my only clue to the latter question. The post is *only* four years old.

http://sourceforge.net/mailarchive/forum.php?thread_name=B24FABB430F7C94D942D6386447C93DC082B5B00%40tayexc17.americas.cpqcorp.net&forum_name=gnv-develop
Hoff
Honored Contributor

Re: lex on OpenVMS?

Lex: "The asteroid to kill this dinosaur is still in orbit."

If open-source is off limits, that means it's time to open the checkbook and start porting the code to something else. And to start hemorrhaging cash out of the budget. This won't be cheap project, in other words.

Use of lib$table_parse is an obvious option for parsing on OpenVMS, if you're going to move from open source to closed source and from portable and maintained to non-portable and maintained. TPU would not be my choice as a parser or as a lexical analyzer; it's just not set up for that.

Traditionally, most folks go to flex and bison here. More recently, I'd certainly look toward llvm and something akin to kaleidoscope; to one of the more recent tool chains and one seeing funding and active development.

And no, GNV (the replacement for POSIX) doesn't include lex and yacc, nor flex and bison. Nor kaleidoscope.

Or pay somebody (you? one of the consultant-types or other small businesses here?) to maintain one of the open-source tools for your customer. There are likely various organizations here that may or would be willing to take on a contract to maintain one of these tools for your customer.

If you want to see what's available as a product for OpenVMS, check with the listings over at the HP DSPP web site, or search over there for consulting folks.

For an example of creating a grammar and using lib$table_parse, see the GNM tool on the OpenVMS Freeware.

Stephen Hoffman
HoffmanLabs LLC


Hoff
Honored Contributor

Re: lex on OpenVMS?

The G in GNV is Gnu; that's most definitely open-source code, and the various packages within the GNV kit are very likely covered by either the GPL or the LGPL.

AFAIK, GNV doesn't contain lex or flex nor yacc or bison; it's certainly not listed in the GNV documentation that's currently posted.
Steven Schweda
Honored Contributor

Re: lex on OpenVMS?

> Not sure if this is a serious question but
> this URL is my only clue [...]

What I see there is "LEX/FLEX", which, along
with the "_G_NV" context, would lead me to
expect GNV to offer "flex", if it offers
anything in this category. So, if you're
lucky, and willing to wait for it, you might
be able to get the same "flex" from GNV that
you seem so eager to avoid.

What makes the GNU freeware packaged in GNV
more desirable than the same GNU freeware in
some other (more currently available) form?
Robert Gezelter
Honored Contributor

Re: lex on OpenVMS?

Mark,

There is freeware and then there is freeware. In there personal computer space, there are many tools that are available as freeware, but are not supplied as compilable source kits, and thus can be a source of problems (and lack of long term support).

There are Open Source tools that have limited audiences and limited user communities. There are also tools that are used throughout the IT community. By definition, the Open Source tools are available in source form, which means that self-maintenance is an option, although many elect to use the available executable files rather than download the sources and run the builds themselves.

The question is the reasoning behind the policy. Is it a support question? Or is it a question of concern over what might be within the source?

The first question can be resolved by finding one of the many firms that have support offerings for these tools, or by retaining a firm with the expertise to assist in this area [Disclosure: Like Hoffman Labs, our firm does provide services in this area].

It is important to note that a tool such a LEX/FLEX is not external facing, and outside of bugs, is an extremely unlikely attack vector.

- Bob Gezelter, http://www.rlgsc.com
Mark Katz
Advisor

Re: lex on OpenVMS?

Thanks for all the replies!

Hoff: Thank you for starting out with "If open-source is off limits" and going from there. I'll consider the TPARSE vs. TPU argument and other suggestions if I get to that place.

Steven Schweda: No real difference in acceptability between GNU and GNV except that *IF* I could use either one the GNV version is probably more VMS compatible (more tested? I don't know). Please don't go off on that tangent. All I was saying was that lex isn't in there anyway.

Bob Gezelter: Thanks for the phone call this morning - nice touching base again after at least 15 years since the old DECUS days (I was the L&T Session Note Editor for about 10 years).

As we discussed, the inflexibility of the policy is out of my control, regardless of the reasonableness of the argument. I will pursue the question of a waiver given that the program in question is not used in the production environment - not holding my breath though.

I did do some experimenting and found out that if I link the object without the SHELLRTL, the only undefined symbol is yyreject. A google search told me that on the AT&T flavor of lex that yyreject is only distributed in object form in the lex library making programs that use the REJECT macro non-portable in C form. Apparently, the AT&T Unix was used as the basis for DEC/Shell (I vaguely remember something like this with regard to DEC/Shell pricing and AT&T licensing costs). This is not the case for most other lex variants - everything they need is embedded in the generated C code.

So, I'm beginning to think I could take the lex source off to another machine without the freeware/open-source restriction, compile it into C using another lex and bring that back (subject to visual inspection by our customer - not that it would be decipherable). Once I had the standalone C version as the new source, it could be compiled on Alpha and IA64 and regression-tested.. I'm not worried about maintenance - this stuff was written and last changed in 1993. I'll be re-retired before the next stumbling block appears!.

I'm going to pursue this approach a bit further before I resort to rewriting anything.

Thanks again, Mark
Steven Schweda
Honored Contributor

Re: lex on OpenVMS?

> So, I'm beginning to think [...]

Well, yeah. If it's a one-time "lex" job,
and not an actual need for "lex" on VMS (as
originally stated), then I'd look for, say,
a Tru64 system, and do the job there. You
might need to shop around a little to find
the "lex" most compatible with your old
"lex".

> Please don't go off on that tangent.

Please state your actual requirements.
Mark Katz
Advisor

Re: lex on OpenVMS?

Steven Schweda replies"

>Well, yeah. If it's a one-time "lex" job,
>and not an actual need for "lex" on VMS (as
>originally stated),

[snip]

>> Please don't go off on that tangent.

>Please state your actual requirements.

******

Which part of the following from the *first* paragraphs of my original post did you not understand?

"Old piece of software (we have all the source code) that needs to be ported to Alpha and eventually IA64."

Important word(s): Old

"That software uses lex from the VAX DEC/Shell product."

Important word(s): VAX DEC/Shell (i.e. long ago obsolete)

"There are two lex source files, one relatively simple and the other fairly complex."

Important word(s): two lex source files (i.e. *only* two files)

"Due to the use of DEC/Shell, this software runs on one of our few remaining VAXen. Even though the source is frozen and the C intermediate is thus fixed, it requires SHELLRTL which is not available for Alpha/IA64 so porting the C intermediate code by hand doesn't help. "

Important word(s): source is frozen and the C intermediate is thus fixed, (i.e. we're not making any changes to this any time soon)

If that's not a statement of a need for a one-time need for lex (or two if you count Alpha and Itanium separately), then I don't know how to make it clearer.

Mark
Hoff
Honored Contributor

Re: lex on OpenVMS?

Have the corporate lawyers and the funding-level managers cough up a decision about use of GPL versus LGPL versus MIT/BSD software licenses, too. This might well reaffirm the "no open source" decision, or it might be a more nuanced decision.

Various companies might not or do not want to deal with the requirements of GPL code, fewer are averse to using LGPL and fewer still to MIT/BSD code.

flex is BSD.

Bison is GPL.

If the "we're from corporate and we're here to help" folks do go for a nuanced decision, zip up the source code for the open-source tool(s) needed to rebuild the lexer code, check it all into the source pool, and get on with the tasks at hand.
Robert Gezelter
Honored Contributor

Re: lex on OpenVMS?

Mark,

Yes, it was nice speaking again after all these years. I seem to recall that I did a lunchtime seminar for your group on either ASTs or shareable libraries (essentially an encore of the sessions that I did on those subjects at various DECUS symposia).

As I noted earlier, Open Source material and freeware are the base of many commercial offerings. The "commercial" LINUX systems being the most obvious case. However, the phenomenon is not limited to LINUX.

As was recently shown by the episode involving DNS cache poisoning described in "VU#800113 -- Multiple DNS implementations vulnerable to cache poisoning" (see http://www.kb.cert.org/vuls/id/800113 ), a large number of manufacturers use such components as the base of their products. This is not inherently a bad thing, but it is a far different issue with publicly exposed interfaces (e.g., BIND, sendmail), than it is for tools used for implementing other software (e.g. PERL, GNU c, lex/yacc-flex/bison).

One hazard that can be eliminated is the danger of contaminated executable files. Compiling from the source archives greatly reduces this hazard.

- Bob Gezelte, http://www.rlgsc.com
Dennis Handly
Acclaimed Contributor

Re: lex on OpenVMS?

>A google search told me that on the AT&T flavor of lex that yyreject is only distributed in object form in the lex library making programs that use the REJECT macro non-portable in C form.

That's probably true. On HP-UX, libl contains:
MultiByte allprint main sprint
yyless yyracc yyreject yywrap