DIBOL to <different language>
Tad Winters
programming languages. I'm after honest, technical answers.
I've done some work for a small company who happens to use some custom
software, written largely in DIBOL, with the rest in MACRO. The custom
forms editor generates additional MACRO code and DIBOL "include" files.
They've been using a single VAX system with an HSD30 for storage. The
system runs rather slowly at times and this both frustrates the users
and probably causes some customers to consider other suppliers. The
system has been tuned many times, without any appreciable improvement.
I would like to propose they move to an AlphaServer, however since
DIBOL is not available for Alpha, the standard answer would be Synergy
DBL. Since Synergy charges for a runtime license, this is a show
stopper. They would be looking at more than $20,000 for Synergy DBL
alone.
I did mention that CHARON-VAX might be a possibility, but I'm not a
huge fan of subjecting a stable operating system to running atop
something much less stable. (Too bad CHARON-VAX is not an emulator
running on bare metal.)
Now to the meat of my question. If a person was interested in moving
code from DIBOL to another language (on OpenVMS), what language would
be the best choice? Keep these details in mind:
A runtime license cost isn't going to fly.
The language will need to support RMS file types (since indexed,
relative and sequential files are used.)
Calls to subroutines written in MACRO will need to work like they would
with DIBOL.
The language would need to support "include" files.
Somebody will probably ask how many lines of code there are to convert.
I'm going to guess between 300,000 and 350,000, but don't hold me to
it.
The routines directly written in MACRO have previously been ported to
the Alpha processor, so as to MACRO, I'd only need to be sure I
continued to generate correct code.
A certain number of the DIBOL programs comprise the forms editor and
support applications, which I would port first. I'd like to start down
the correct road first. The languages which I first thought would meet
the requirements are FORTRAN, BASIC, Pascal, and COBOL. This doesn't
strictly rule out others, and it would seem prudent to choose a
language which is also supported on Itanium.
I await your wisdom.
David J Dachtera
A local associate of mine (who happens to own openvms.com) had a client
who did their DIBOL development on VAX, then VESTed the images to Alpha.
My first suggestion, however, would be to troubleshoot the performance
issue, if at all possible. Demons could be lurking there which will
migrate to the new platform, if you try to move them to Alpha without
exploring that.
David J Dachtera
DJE Systems
Hein RMS van den Heuvel
<stafford.no.spam.winte...@verizon.net> wrote:
> The custom forms editor generates additional MACRO code and DIBOL "include" files.
Since it is generated, a of 'perl' can probably readily transform that
into anything.
> They've been using a single VAX system with an HSD30 for storage. The
> system runs rather slowly at times
Slowly 'at times' suggests to me that the basic need is met, but there
might be an addresable peformance/tuning issue. But they shoudl
probably move regardless.
> The system has been tuned many times, without any appreciable improvement.
Personally I don't believe in system tuning.
Unless someting is really broken, that's just fumbling in the margins.
Application and DB tuning is the only way to make a proper difference.
> I would like to propose they move to an AlphaServer, however since
> DIBOL is not available for Alpha, the standard answer would be Synergy
> DBL.
Did you also check out our friend Bruce Claremon offerings?
http://www.migrationspecialties.com/CBL.html
> I did mention that CHARON-VAX might be a possibility, but I'm not a
> huge fan of subjecting a stable operating system to running atop
> something much less stable. (Too bad CHARON-VAX is not an emulator
> running on bare metal.)
It has been working well. Despite bad rap, I'm personally not so much
concerned about the underpinnings of the emulators. Windows is stable
in predictable environment. If is is just a host, then it will do
fine. Just don't use the same box too much native windows stuff. No
random web-browsing or family video productions on the side!
I would be more concerened about the application beginning to run into
inherent botlleneck which may be starting to show now on VAX but may
well still be there on Alpha or an other platform.
> The languages which I first thought would meet
> the requirements are FORTRAN, BASIC, Pascal, and COBOL.
Hmm, you don't mention C. Yeak it does not have native RMS (indexed
file) support, but it can call RMS any which way you like.
I (used) to like BASIC a lot, but it seems such a dead-end street to
me these days and it is NOT a high performance language, just a
'comfortable' language like perl. and where will you find folks
experienced with Vax-Basic's little gotcha's?
Fortran... ho hum
Cobol... proabbly the best match for Dibol
Pascal... Clean language, but how many programmers are available out
there?
My knee-jerk reaction is 'C'... you can write bad code in any
language.
Good luck!
Hope this helps some,
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting
ultr...@gmail.com
Ask synergy to give you a break on the licensing ...
they are sometimes flexible for small companies ...
also there have been several dibol shops who have
used vest successfully ...
I would buy a DS10L from island for 200.00 and
try vest first ... it probably will work and its free ...
Richard B. Gilbert
> Let me start by saying, this is _not_ meant to start a war over
> programming languages. I'm after honest, technical answers.
>
> I've done some work for a small company who happens to use some custom
> software, written largely in DIBOL, with the rest in MACRO. The custom
> forms editor generates additional MACRO code and DIBOL "include" files.
>
> They've been using a single VAX system with an HSD30 for storage. The
> system runs rather slowly at times and this both frustrates the users
> and probably causes some customers to consider other suppliers. The
> system has been tuned many times, without any appreciable improvement.
>
mistuned to start with, the best you can hope for is to squeeze out the
last ten percent in performance!
> I would like to propose they move to an AlphaServer, however since
> DIBOL is not available for Alpha, the standard answer would be Synergy
> DBL. Since Synergy charges for a runtime license, this is a show
> stopper. They would be looking at more than $20,000 for Synergy DBL
> alone.
>
> I did mention that CHARON-VAX might be a possibility, but I'm not a
> huge fan of subjecting a stable operating system to running atop
> something much less stable. (Too bad CHARON-VAX is not an emulator
> running on bare metal.)
>
> Now to the meat of my question. If a person was interested in moving
> code from DIBOL to another language (on OpenVMS), what language would
> be the best choice? Keep these details in mind:
> A runtime license cost isn't going to fly.
Just about ANY language except Gnu C is going to require a license that
costs money! AFAIK there is no such thing as Gnu COBOL!
> The language will need to support RMS file types (since indexed,
> relative and sequential files are used.)
> Calls to subroutines written in MACRO will need to work like they would
> with DIBOL.
> The language would need to support "include" files.
>
> Somebody will probably ask how many lines of code there are to convert.
> I'm going to guess between 300,000 and 350,000, but don't hold me to
> it.
>
> The routines directly written in MACRO have previously been ported to
> the Alpha processor, so as to MACRO, I'd only need to be sure I
> continued to generate correct code.
>
> A certain number of the DIBOL programs comprise the forms editor and
> support applications, which I would port first. I'd like to start down
> the correct road first. The languages which I first thought would meet
> the requirements are FORTRAN, BASIC, Pascal, and COBOL. This doesn't
> strictly rule out others, and it would seem prudent to choose a
> language which is also supported on Itanium.
>
> I await your wisdom.
You didn't say what model VAX they were using. Some were painfully
slow, others were much faster. Knowing the Model of the VAX, we might
be able to suggest a substantially faster machine. A faster machine
might very well require more "License Units"! OTOH, rewriting 350,000
lines of code in a new language, supported on the Alpha and/or Itanic,
is probably going to cost seven to ten man years of effort.
The other approach, the one that you asked about; is another language.
You can code just about anything, in just about any language! Languages
have both strengths and weaknesses. The language that was great for
doing Fourier Transforms would have to be bent out of shape to write
accounts receivable and vice versa of course.
The only widely available languages that might be close to DIBOL (a
language I know almost nothing about) are COBOL and PL/1. I believe
that PL/1 is available for Alpha; I don't know if it's available for Itanic.
I think that, if you cost this out carefully, you may find that a
$20,000 license is small change compared to the rest of it!
Arne Vajhøj
> Just about ANY language except Gnu C is going to require a license that
> costs money! AFAIK there is no such thing as Gnu COBOL!
Java, Perl, Python etc. are also free.
But may not be a good choice for the task (RMS, Macro-32 etc.).
Arne
Tad Winters
news:Xns9A409E8123299st...@199.45.49.11:
Perhaps I should mention that this is VMS V7.1. There are up to 150
concurrent users. The worst time is usually between 8 and 10 in the
morning, when many reports are being run in batch in addition to
interactive use. There are 120 detached processes performing (or waiting
to perform) specific application functions. The system is also running
MultiNet V4.4. I'd love to get this all upgraded, but there's no way
that would fly without guaranteed significant performance improvement.
If upgrading is the way to go, then it seems like it would be best to
make as much a jump as possible.
Thanks.
Richard B. Gilbert
Is there some reason why some of these reports couldn't be run overnight
instead of from 8 AM to 10 AM??
Tad Winters
And one more thing. This is a VAX 4000-600A.
Tad Winters
news:47AFC674...@comcast.net:
> Tad Winters wrote:
>> Tad Winters <stafford.no....@verizon.net> wrote in
>> news:Xns9A409E8123299st...@199.45.49.11:
>>
>> Perhaps I should mention that this is VMS V7.1. There are up to
>> 150 concurrent users. The worst time is usually between 8 and 10
>> in the morning, when many reports are being run in batch in
>> addition to interactive use. <snip>
>
> Is there some reason why some of these reports couldn't be run
> overnight instead of from 8 AM to 10 AM??
>
I believe these vary from day to day. We're talking about reports having
to do with Accounts Payable, Accounts Receivable, General Ledger and
their very customized Distribution Management. If they planned ahead,
they could request the reports be run overnight, but this is a group of
order takers and warehouse people. Most of their work is reaction to
orders being placed. The few who could help by planning are those who
work the accounting applications and those who do purchasing.
This is certainly worth a try.
Thanks.
Tad Winters
>
> You didn't say what model VAX they were using. Some were painfully
> slow, others were much faster. Knowing the Model of the VAX, we
> might be able to suggest a substantially faster machine. A faster
> machine might very well require more "License Units"! OTOH,
> rewriting 350,000 lines of code in a new language, supported on the
> Alpha and/or Itanic, is probably going to cost seven to ten man
> years of effort.
>
> The other approach, the one that you asked about; is another
> language. You can code just about anything, in just about any
> language! Languages have both strengths and weaknesses. The
> language that was great for doing Fourier Transforms would have to
> be bent out of shape to write accounts receivable and vice versa of
> course.
>
> The only widely available languages that might be close to DIBOL (a
> language I know almost nothing about) are COBOL and PL/1. I believe
> that PL/1 is available for Alpha; I don't know if it's available for
> Itanic.
>
> I think that, if you cost this out carefully, you may find that a
> $20,000 license is small change compared to the rest of it!
>
The last pricing I saw on a one user compiler license was $1995. That's
a far better price than $20,000.
I know this could take a lot of hours, but if I could convert the
smallest application, I think I could motivate someone else to help the
in the process. This would be good experience for similar work at
another company, which isn't having any performance problems, but would
like the comfort of having easily replaced hardware in the case of a
disaster.
Jerry
<stafford.no.spam.winte...@verizon.net> wrote:
> A certain number of the DIBOL programs comprise the forms editor and
> support applications, which I would port first. I'd like to start down
> the correct road first. The languages which I first thought would meet
> the requirements are FORTRAN, BASIC, Pascal, and COBOL.
I've used FORTRAN, BASIC and Pascal in short term projects only. I
can't say much about them.
After being a COBOL and C programmer for years, I worked a few years
with DIBOL/DBL, so I can only comment on those languages. I used to
joke that DIBOL was a language with all the power of COBOL with the
ease of use of C.
For straight forward business applications COBOL is probably the
easiest to learn and maintain. You can use copylibs instead of
includes. COBOL does have its limitations compared to C but it pretty
much can do anything that DIBOL can do.
> Since Synergy charges for a runtime license, this is a show
> stopper. They would be looking at more than $20,000 for Synergy DBL
> alone.
...
> Somebody will probably ask how many lines of code there are to convert.
> I'm going to guess between 300,000 and 350,000, but don't hold me to
> it.
On the other hand, from a business view, this doesn't make sense. The
time and effort it would take to rewrite 300K lines of DIBOL to
another language makes $20K look like small stuff. Just to let you
know, for close to 10 years, I've been doing budget estimates and
project management solely on migration work. $20K is a mere fraction
of the cost of this type of migration. You've got some tough choices
ahead.
Good luck, though.
Bob Willard
>>>They've been using a single VAX system with an HSD30 for storage.
>>>The system runs rather slowly at times and this both frustrates the
>>>users and probably causes some customers to consider other
>>>suppliers. The system has been tuned many times, without any
>>>appreciable improvement.
>>>
>>>I would like to propose they move to an AlphaServer, however since
>>>DIBOL is not available for Alpha, the standard answer would be
>>>Synergy DBL. Since Synergy charges for a runtime license, this is
>>>a show stopper. They would be looking at more than $20,000 for
>>>Synergy DBL alone.
>>>
>>>I did mention that CHARON-VAX might be a possibility, but I'm not a
>>>huge fan of subjecting a stable operating system to running atop
>>>something much less stable. (Too bad CHARON-VAX is not an emulator
>>>running on bare metal.)
>
> And one more thing. This is a VAX 4000-600A.
1.Try a faster VAX
2.Try more RAM
3.Try a SMP VAX and/or a cluster
4.Try faster storage, esp. RAID0 and/or 15K RPM SCSI HDs
I suspect that a concurrent batch DIBOL workload is I/O intensive,
rather than CPU intensive, so souping up the storage would be my
first priority. But, measuring the workload attributes to find
the bottleneck(s) would be smarter than relying on my long-distance
crystal ball.
Unless the VAX 4000 is maxed out, adding RAM is the simplest and
cheapest hardware improvement you can make. Regardless of the
long-term solution you pursue, I'd add RAM for short-term relief
if possible.
You can buy a hell of a lot of second-hand VAXen for less than the
cost of a team of porters, esp. porters with VMS and DIBOL creds.
--
Cheers, Bob
Richard B. Gilbert
If some of these reports are periodic; e.g. every day, every Friday,
etc, they could be handled as self submitting batch jobs. You might
benefit from a "clever" batch scheduler such as JAMS. Using JAMS you
can say "every Friday except holidays" and the job will be run that way.
Another possible solution is to buy another VAX 4000-600 and cluster the
two. You could have one grinding out reports while the other handled
order taking, accounts receivable, etc.
Bill Gunshannon
Hein RMS van den Heuvel <heinvand...@gmail.com> writes:
>
> Pascal... Clean language, but how many programmers are available out
> there?
At least one.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Bill Gunshannon
Bill Gunshannon
And I just watched two lightly used, perfectly functional VAX 7000's
get hauled to the dump. You could have had them for the cost of a
rental truck. :-(
Bill Gunshannon
Considering the stability of the operation and the desire to minimize
costs, this seems like the best suggestion yet. I would go one further
and suggest at least two more VAX 4000-600's for even better performance
and eliminating the chance that you would drop back to just the one
system shopuild anything go wrong. I would imagine VAX 4000 are still
available on the cheap. I have three and have never paid for any of them.
Richard B. Gilbert
Yeah! It used to be known as "Performance Management". A few of us old
fogies still remember! Instead of paying the hardware and licensing
costs for a faster machine, work the old one harder! There's no point
in letting it loaf from 6:00 PM to 6:00 AM.
FrankS
a) The cheapest solution may be to upgrade from a 4000-600A to either
a -700A or -705A. Both of those -7xxA systems were faster than the
-600A, yet had the same license rating. You should be able to find
them at various used system resellers. Make sure you max out the
memory if you go that route.
Similarly, upgrade the HSD30 to an HSD50. You didn't mention what
disk cabinet the HSD30 is in. If it's an RA450 then I believe the
HSD50 will just slide in. That will give you 6 SCSI channels instead
of 3 so you can spread the I/O a bit, and the controller itself is
faster. You would also want to max out the cache on the HSD (128mb,
if I remember correctly).
b) Clustering the 4000-600A with another VAX probably isn't a good
solution because you'd have to find and buy VAXcluster licenses. HP
may still sell them, but the cost for two nodes may be more than the
Synergy license.
c) For an Alpha solution you'd have to get the VMS Base license, an
unlimited user license, and any other licenses that are on the VAX
that need to be transferred. Because of HP's licensing policies you
can only get the Base license from an HP authorized reseller and it
must be sold with the Alpha system. Don't forget that you'd need a
license for whichever language compiler you decide to use. (The
assumption is that you will be looking for valid licenses and not
using other methods to get VMS licenses onto the Alpha.)
While you can get DSSI for an Alpha system you'd probably want to
switch to fiber. That introduces other costs of moving the data from
the HSD array to an HSG array. The HSG80 controllers and cabinets are
cheap enough on eBay or other sources, and even disk drives in the
blue Storageworks caddies are fairly inexpensive. But it all adds up.
d) The biggest cost factor as others have pointed out is your time in
converting the applications from DIBOL to any other language. You
might be able to use TPU to create an automated solution, but I'm not
familiar enough with DIBOL syntax to know how feasible that would be.
Still, testing is going to add up in billable hours, unless you're
doing this pro-bono.
e) If you do decide to go the migration route then consider
Integrity. From what I can remember the lowest priced Integrity with
licenses, media, and cabinetry lists at $5k. HP will likely provide
discounts on trade-up licenses from the VAX which will lower that cost
somewhat.
You can try VESTing the DIBOL compiler to Alpha, then AEST it to
Integrity. If it works you've saved yourself a bundle on migration
costs. Otherwise the work involved in translating the DIBOL to
another language is not going to change whether you're moving to Alpha
or Integrity.
f) The performance gains to be had when going from a VAX 4000-600A +
DSSI to a DS10L (or practically any Alpha) + fiber are significant.
Likewise for a switch to Integrity. It would be well worth the $20k
investment, in my opinion, to stick with the DIBOL environment. You
might not put as much money into your own pocket because the migration
effort isn't as complicated as rewriting to another language, but your
customer would be a lot happier.
Bill Gunshannon
FrankS <sapi...@noesys.com> writes:
> On Feb 10, 6:34 pm, Tad Winters
> <stafford.no.spam.winte...@verizon.net> wrote:
>> I await your wisdom.
>
> Integrity.
I have a question regarding this scheme that just occured to me.
If you have old applications that originated on a VAX and have
been VESTed to Alpha (and then, perhaps, AESTed to Itanium) does
this not leave you stuck keeping, maintaining and paying licensing
for a VAX as well in the event problems occur with the program or
some form of upgrade needs to be made to the application?
Jeffrey H. Coffield
Basic or Cobol would be my choice, in that order. We have done a number
of conversions from other systems to OpenVMS as well as upgrades. One
approach that has been successful on a couple of those is to write code
converters that get 90 to 95% of the standard code converted and then
tackle the rest by hand.
If you would like to discuss this in more detail, including us possibly
helping you in the conversion, please call me at (949) 650-0526.
Jeff Coffield
www.digitalsynergyinc.com
Tad Winters
news:61b01fF...@mid.individual.net:
[..snip..]
>
> And I just watched two lightly used, perfectly functional VAX 7000's
> get hauled to the dump. You could have had them for the cost of a
> rental truck. :-(
>
> bill
>
Pennsylvania to Oregon would have been quite the trip. Their current
system (actually 2, with 1 acting as their stand-by) is below grade (like
their entire operation) in a room about 10' by 10', 3 line printers,
built-in cabinets on one wall and boxes of paper lining another wall. I
can't say I've seen a VAX 7000 in person, but I suspect there would have
been space, cooling and power issues to address.
Just 2 days ago, the most IT person in that company asked me about
putting what they have in racks, since a water main had broken just a
block away (down hill) in the last week, which caused flooding for the
adjacent businesses.
Another interesting fact is the "computer room" is carpetted.
Bill Gunshannon
Tad Winters <stafford.no....@verizon.net> writes:
> bill...@cs.uofs.edu (Bill Gunshannon) wrote in
> news:61b01fF...@mid.individual.net:
>
> [..snip..]
>>
>> And I just watched two lightly used, perfectly functional VAX 7000's
>> get hauled to the dump. You could have had them for the cost of a
>> rental truck. :-(
>>
>> bill
>>
>
> Pennsylvania to Oregon would have been quite the trip.
True, but a real bargain once oyu discount what a VAX 7000 actually costs.
> Their current
> system (actually 2, with 1 acting as their stand-by) is below grade (like
> their entire operation) in a room about 10' by 10', 3 line printers,
> built-in cabinets on one wall and boxes of paper lining another wall.
I've worked for people like that. Sometimes the best idea is to just
wash your hands and walk away. (It took 3 major data lossdes here before
they finally agreed we should have a tape drive fast enough and with the
capacity to do real regular backups.)
> I
> can't say I've seen a VAX 7000 in person, but I suspect there would have
> been space, cooling and power issues to address.
Very likely. :-) Think of the size of a walk-in fridge. Only hotter.
> Just 2 days ago, the most IT person in that company asked me about
> putting what they have in racks, since a water main had broken just a
> block away (down hill) in the last week, which caused flooding for the
> adjacent businesses.
Dependingon how far below grade that might not help much. :-)
> Another interesting fact is the "computer room" is carpetted.
That comes as no surprise as I have seen companies that sell raised
floor tiles that are carpet. As long as it is anti-static and the
dust get's vacuumed out of it regularly not really a problem. But,
I would imagine it is merely bargain-basement carpet from the local
outlet store.
Richard B. Gilbert
> bill...@cs.uofs.edu (Bill Gunshannon) wrote in
> news:61b01fF...@mid.individual.net:
>
> [..snip..]
>
>>And I just watched two lightly used, perfectly functional VAX 7000's
>>get hauled to the dump. You could have had them for the cost of a
>>rental truck. :-(
>>
>>bill
>>
>
>
> Pennsylvania to Oregon would have been quite the trip. Their current
> system (actually 2, with 1 acting as their stand-by) is below grade (like
> Another interesting fact is the "computer room" is carpetted.
Unusual but by no means impossible. You can buy "anti-static" carpet
for such purposes. You can even buy raised floor panels with carpet
topping. I don't recall ever having seen such panels or a carpeted
computer room but at least one company tried to sell me such a thing.
I don't even want to think about keeping a carpeted computer room clean!
FrankS
> I have a question regarding this scheme that just occured to me.
> If you have old applications that originated on a VAX and have
> been VESTed to Alpha (and then, perhaps, AESTed to Itanium) does
> this not leave you stuck keeping, maintaining and paying licensing
> for a VAX as well in the event problems occur with the program or
> some form of upgrade needs to be made to the application?
Honestly, after I posted that I realized a similar issue: the VAX
license needed to run the DIBOL compiler might not be loadable on
either Alpha or Integrity OpenVMS. Worth trying, though.
Certainly, using VEST/AEST on any application for which you don't have
the source code leaves you stuck at the version you're running, as far
as upgrades. In the case of the DIBOL compiler, though, I don't think
that's a concern. :-)
Wilm Boerhout
> I did mention that CHARON-VAX might be a possibility, but I'm not a
> huge fan of subjecting a stable operating system to running atop
> something much less stable. (Too bad CHARON-VAX is not an emulator
> running on bare metal.)
Having read up on this thread, an weighing the possible cost and risk of
all different kinds of ports/migrations, I seriously think you are
robbing your customer of the best possible solution: CHARON-VAX.
Mind you, although my company resells CHARON-VAX products, I will not
benefit from this particular deal, or any deal in your geography. I have
implemented this product (and CHARON-AXP) many times in heavy production
environments, and it (and Windows alongside it) has never failed me (or
my customers). Windows is really only used in the installation and
program load stages. When it's running, it's in the processor L2 cache,
with Windows running beside in another processor. Windows *is*
remarkably stable when it's not used. Services may be stopped and
disabled, and especially when you don't connect the Windows instance to
any network, it will run for months/quarters/years without intervention.
No license issues, instant spectacular performance improvement, only
disadvantage: up and running in the time it takes to do a
backup/restore. Not free though, but well within your apparent budget.
So, set religion aside, and do what's best for your customer.
--
Wilm Boerhout |
Zwolle, | - 'My memory's fine!'
The Netherlands | - 'But you keep forgetting your mistakes!'
remove OLD PAINT to reply | - 'Exactly!'
Peter Weaver
> I did mention that CHARON-VAX might be a possibility, but I'm not a
> huge fan of subjecting a stable operating system to running atop
> something much less stable. (Too bad CHARON-VAX is not an emulator
> running on bare metal.)
OK, I am a CHARON-VAX reseller, but I need to point out that CHARON-VAX and
CHARON-AXP on Windows are very stable. I have many customers who are true
VMS bigots running CHARON-VAX and CHARON-AXP and they are happy that the
boxes are as stable or even more stable than the old hardware. You can run
CHARON as an appliance and turn off everything that Windows does not need,
even turn off the IP stack so Windows can not talk to anything on the
Ethernet. If Windows is not allowed to see the network then it is extremely
stable.
Contact your nearest CHARON-VAX reseller (or me if you there is nobody in
driving distance of your customer, I usually only sell to customers in
Canada just because of the issues dealing across a border but I would be
happy to help) and give CHARON-VAX a try. In the end you will get a faster
CPU, faster memory and faster disk I/O without any changes except maybe some
physical disk names. I have customers who went from VAX 4000 machines to
CHARON-VAX and had batch jobs run in minutes rather than hours.
Peter Weaver
www.weaverconsulting.ca
CHARON-VAX CHARON-AXP DataStream Reflection PreciseMail HP Commercial
Hardware
Bob Gezelter
> Let me start by saying, this is _not_ meant to start a war over
> programming languages. I'm after honest, technical answers.
>
> I've done some work for a small company who happens to use some custom
> software, written largely in DIBOL, with the rest in MACRO. The custom
> forms editor generates additional MACRO code and DIBOL "include" files.
>
> They've been using a single VAX system with an HSD30 for storage. The
> system runs rather slowly at times and this both frustrates the users
> and probably causes some customers to consider other suppliers. The
> system has been tuned many times, without any appreciable improvement.
>
> I would like to propose they move to an AlphaServer, however since
> DIBOL is not available for Alpha, the standard answer would be Synergy
> DBL. Since Synergy charges for a runtime license, this is a show
> stopper. They would be looking at more than $20,000 for Synergy DBL
> alone.
>
> huge fan of subjecting a stable operating system to running atop
> something much less stable. (Too bad CHARON-VAX is not an emulator
> running on bare metal.)
>
> code from DIBOL to another language (on OpenVMS), what language would
> be the best choice? Keep these details in mind:
> A runtime license cost isn't going to fly.
> The language will need to support RMS file types (since indexed,
> relative and sequential files are used.)
> Calls to subroutines written in MACRO will need to work like they would
> with DIBOL.
> The language would need to support "include" files.
>
> Somebody will probably ask how many lines of code there are to convert.
> I'm going to guess between 300,000 and 350,000, but don't hold me to
> it.
>
> The routines directly written in MACRO have previously been ported to
> the Alpha processor, so as to MACRO, I'd only need to be sure I
> continued to generate correct code.
>
> A certain number of the DIBOL programs comprise the forms editor and
> support applications, which I would port first. I'd like to start down
> the correct road first. The languages which I first thought would meet
> the requirements are FORTRAN, BASIC, Pascal, and COBOL. This doesn't
> strictly rule out others, and it would seem prudent to choose a
> language which is also supported on Itanium.
>
> I await your wisdom.
Tad,
For porting, it depends on the style of code. If you want integrated
(non-custom) support for access to indexed and other files, you are
probably limited to BASIC, FORTRAN, and COBOL. It is not inherantly
difficult to access keyed files from C/C++, but it will be in the
nature of a non-integrated add-in (or in the case of C++, probably a
class).
Hoiwever, before I go deep into porting the code, I would invest some
effort to tuning the system. Having been involved in tuning many such
systems over the years, I always caution clients that performance
improvements can almost always be achieved with far less effort than
porting to a new language. Often, significant results can be achieved
with a relatively small scale consulting project (days to a week or
so). It is not possible to make blanket assurances, but that has been
my overwhelming experience. In any event, porting 300,000 lines of
code is going to be a non-trivial project, and the performance work is
less expensive by orders of magnitude (e.g., 1% - 5% of a conversion
project). [Disclosure: My firm does provide services in this area, as
well as tools development ].
Peak load performance problems are often relatively straightforward to
address, at far less cost.
Charon-VAX is also, if I recall correctly, available on OpenVMS-Alpha/
Itanium for VAX emulation, that may be another possibility (as would
the use of one of the freeware emulators).
I hope that the above is helpful. If I have been unclear, please let
me know.
- Bob Gezelter, http://www.rlgsc.com
Tad Winters
abbaec...@d4g2000prg.googlegroups.com:
VESTing the compiler itself? Wouldn't it still create a VAX object file?
If VESTing the application, I'd plan on maintaining a little MicroVAX,
like a 3100, for code changes. For that matter, maybe just use a virtual
VAX for compiling DIBOL code. Where do I get the tools to VEST a
program? (I assume this must run on Alpha.) And the VESTing tool is
free, isn't it?
Wilm Boerhout
[snip]
> Charon-VAX is also, if I recall correctly, available on OpenVMS-Alpha/
> Itanium for VAX emulation, that may be another possibility (as would
> the use of one of the freeware emulators).
On Alpha, yes, Itanium, no. Not so spectacular performance improvement
on readily available / cheap Alpha's though.
You cannot legally transfer your VMS licenses to SIMH or another
freeware emulator.
FrankS
<stafford.no.spam.winte...@verizon.net> wrote:
> VESTing the compiler itself? Wouldn't it still create a VAX object file?
Not necessarily. Of course, I haven't tried this so it's all
theoretical and maybe it won't work at all. However, I would expect
that if it did work the Alpha versions of shareable images the
compiler relied on would generate Alpha code.
On Feb 11, 2:18 pm, Tad Winters
<stafford.no.spam.winte...@verizon.net> wrote:
> Where do I get the tools to VEST a
> program? (I assume this must run on Alpha.) And the VESTing tool is
> free, isn't it?
Yes, it runs on Alpha, and it's free from HP at this URL ...
Bob Gezelter
Tad,
Even though I am a great believer in the use of VEST and AEST as
tools, I do not think that I would recommend this path without a good
deal of study. Debugging problems in this environment (VESTed compiler
generating VAX code that is then VESTed and possibly AESTed to produce
the actual executable image) would be a challenge. I would more look
to using VEST/AEST as I illustrated in my "Strategies for Migrating
from Alpha and VAX systems to HP Integrity Servers on OpenVMS",
accessible from http://www.rlgsc.com/publications/vmstechjournal/migrationstrategies.html
Arne Vajhøj
> In article <cbe43c7c-e1b3-49b0...@c23g2000hsa.googlegroups.com>,
> Hein RMS van den Heuvel <heinvand...@gmail.com> writes:
>> Pascal... Clean language, but how many programmers are available out
>> there?
>
> At least one.
Pascal was a very widely used language for learning
programming in the golden VAX days. I think a lot
of VMS people will know Pascal. It may be a bit rusty
for some, but some say that it is like driving a bicycle.
Arne
Bob Koehler
> In article <d37051ee-2f93-4700...@s8g2000prg.googlegroups.com>,
> FrankS <sapi...@noesys.com> writes:
>> On Feb 10, 6:34 pm, Tad Winters
>> <stafford.no.spam.winte...@verizon.net> wrote:
>>> I await your wisdom.
>>
>> You can try VESTing the DIBOL compiler to Alpha, then AEST it to
>> Integrity.
>
> I have a question regarding this scheme that just occured to me.
> If you have old applications that originated on a VAX and have
> been VESTed to Alpha (and then, perhaps, AESTed to Itanium) does
> this not leave you stuck keeping, maintaining and paying licensing
> for a VAX as well in the event problems occur with the program or
> some form of upgrade needs to be made to the application?
You have to maintain a VAX to run the compiler. Charon-VAX or simh
would do, so you don't have to maintain VAX hardware.
Maintaing VAX hardware isn't all that difficult when you can buy
replacements cheap.
Bob Koehler
> Unusual but by no means impossible. You can buy "anti-static" carpet
> for such purposes. You can even buy raised floor panels with carpet
> topping. I don't recall ever having seen such panels or a carpeted
> computer room but at least one company tried to sell me such a thing.
> I don't even want to think about keeping a carpeted computer room clean!
We had a carpeted raised floor in one computer room. It kept the
noise from the 11/70 and 11/785 down. Their updraft cooling
kept the carpet clean. We still have computer filter problems in
that room, long after the 11/70 and 11/785 have been removed.
Bob Koehler
>
> VESTing the compiler itself? Wouldn't it still create a VAX object file?
>
Yes, it would still create a VAX object file. And the command entry
in DCLTABLES won't VEST, IIRC, so you'ld have to extract it (try
getting the VERB utility), and enter it into the Alpha by hand.
The LINKER on Alpha will operate as a cross linker, but you'll have
to drag all the VAX object and image libraries over to where they
can be picked up while cross linking on the Alpha.
Then the resulting VAX image would have to be VESTed.
All a bit of a pain compared to running Charon-VAX or simh.
ultr...@gmail.com
<stafford.no.spam.winte...@verizon.net> wrote:
> Tad Winters <stafford.no.spam.winte...@verizon.net> wrote innews:Xns9A409E8123299st...@199.45.49.11:
> concurrent users. The worst time is usually between 8 and 10 in the
> morning, when many reports are being run in batch in addition to
> to perform) specific application functions. The system is also running
> MultiNet V4.4. I'd love to get this all upgraded, but there's no way
> that would fly without guaranteed significant performance improvement.
> If upgrading is the way to go, then it seems like it would be best to
> make as much a jump as possible.
>
> - Show quoted text -
you have two inexpensive options ...
1. we ran DIBOL on a vaxstation 4000-90 and 4000-96 for years
on vms 6.2 and it ran very well for allour accounting apps ...
So go out on the second hand market or even Ebay and BUY
a vaxstation 4000-9x ...
2. Buy s DS10L from island computer and put 7.1-2 vms on it
and VEST from the vax (which for development purposes can
be replaced with a vaxstation VLC for CHEAP) to the alpha
vms 7.1 ds10l box (which is also cheap) ... like I said I know
of several DIBOL shops in the past that succesfully used vest
to take dibol apps from 7.1 vax to 7.1 alpha ...
Either solution above would NOT cost $20,000 ... if would probably
cost more like $2,000 ...
Bill Gunshannon
I was thinking more along the lines of cost as this is a real business
application. You have to factor in the cost of the hardware (or the
emulator) and licenses for yet another system just to keep that old
DIBOL application running.
Bill Gunshannon
Actually, I learned Pascal while in a production environment in order
to write serious applications for an LSI-11/02 based micro. It was
many years after that before I first saw it in use in academia.
Oh yeah, I became so enthraled with Pascal that even now I spend a
good deal of time examining and playing with Pascal Compilers and
systems.
John Reagan
> For porting, it depends on the style of code. If you want integrated
> (non-custom) support for access to indexed and other files, you are
> probably limited to BASIC, FORTRAN, and COBOL. It is not inherantly
> difficult to access keyed files from C/C++, but it will be in the
> nature of a non-integrated add-in (or in the case of C++, probably a
> class).
Not to divert the topic, but Pascal has just as good support for indexed
and relative files as the langauges listed above. Well, you can't
CREATE a file with segmented keys from Pascal without resorting to a
USERACTION routine, but you can open an existing file and even use FINDK
to lookup a record.
--
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company
Tad Winters
news:fotat3$tf1$1...@usenet01.boi.hp.com:
> Bob Gezelter wrote:
>
>> For porting, it depends on the style of code. If you want
>> integrated (non-custom) support for access to indexed and other
>> files, you are probably limited to BASIC, FORTRAN, and COBOL. It is
>> not inherantly difficult to access keyed files from C/C++, but it
>> will be in the nature of a non-integrated add-in (or in the case of
>> C++, probably a class).
>
> Not to divert the topic, but Pascal has just as good support for
> indexed and relative files as the langauges listed above. Well, you
> can't CREATE a file with segmented keys from Pascal without
> resorting to a USERACTION routine, but you can open an existing file
> and even use FINDK to lookup a record.
>
It seems like DIBOL was quite a good language. Why did Digital drop it
with the move to Alpha?
Hank Vander Waal
It IS a great language.
They did not drop it - they farmed it out to some one who was still
developing it. One less thing for them to worry about
It is now DBL and runs on all kinds of platforms.
Larry Kilgallen
> Bob Gezelter wrote:
>
>> For porting, it depends on the style of code. If you want integrated
>> (non-custom) support for access to indexed and other files, you are
>> probably limited to BASIC, FORTRAN, and COBOL. It is not inherantly
>> difficult to access keyed files from C/C++, but it will be in the
>> nature of a non-integrated add-in (or in the case of C++, probably a
>> class).
>
> Not to divert the topic, but Pascal has just as good support for indexed
> and relative files as the langauges listed above. Well, you can't
> CREATE a file with segmented keys from Pascal without resorting to a
> USERACTION routine, but you can open an existing file and even use FINDK
> to lookup a record.
DEC/Compaq/HP Ada forces one to specify a FDL string to do that,
but after getting accustomed to it that is not such a bad approach
if your rate of file creation is sufficiently low that overhead
from parsing the FDL string is not an issue.
Stanley F. Quayle
>
> Not necessarily. Of course, I haven't tried this so it's all
> theoretical and maybe it won't work at all.
Of course it would. How would the VEST'd compiler "know" it's supposed to generate
Alpha, Itanium, or Power PC instructions??
You'd have to VEST the result of the compiler to get something that runs on Alpha, too.
> However, I would expect that if it did work the Alpha versions of shareable
> images the compiler relied on would generate Alpha code.
There's no shareable image that generates Alpha or any other kind of code. There's a
back-end tool called GEM that most VMS compilers use, but it's not something that you can
just use.
--Stan Quayle
Quayle Consulting Inc.
----------
Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
8572 North Spring Ct., Pickerington, OH 43147 USA
stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
"OpenVMS, when downtime is not an option"
Stanley F. Quayle
> And I just watched two lightly used, perfectly functional VAX 7000's
> get hauled to the dump.
"Lightly used", but certainly not "light".
It seems a shame, though. Some should at least parted them out first...
Stanley F. Quayle
Paying for licenses?
I encounter customers all the time that don't know that HP owns VMS. They're certainly
not paying anyone license fees for their VAX.
Bill Gunshannon
"Stanley F. Quayle" <inf...@stanq.com> writes:
>> this not leave you stuck keeping, maintaining and paying licensing for a VAX
>
> Paying for licenses?
>
> I encounter customers all the time that don't know that HP owns VMS. They're certainly
> not paying anyone license fees for their VAX.
>
Not surprised, but some people actually don't believe in stealing
software. I woould be willing to bet that there are a lot of
commercial VMS systems running with Hobbyist PAKs.
Bill Gunshannon
>> And I just watched two lightly used, perfectly functional VAX 7000's
>> get hauled to the dump.
>
> "Lightly used", but certainly not "light".
>
> It seems a shame, though. Some should at least parted them out first...
>
I offered them here for nothing. I offered them in other places for
free. As a last resort I put them on Ebay. I sold one for $100.
Al Kossow asked to have one CPU for his collection (which I sent him).
Don't really know what else I could have done. I kept them hanging
around for more than a year trying to avoid just dumping them. Sad,
really......
FrankS
> There's no shareable image that generates Alpha or any other kind of code. There's a
> back-end tool called GEM that most VMS compilers use, but it's not something that you can
> just use.
I don't think it was too much of a stretch to guess that the GEM
functions common to all compilers would be located in a shareable
image. Since, to my knowledge, GEM generates the object files then
the Alpha version of the GEM code would generate Alpha objects with
Alpha instructions.
If you VEST the DIBOL compiler and are able to mate it to the Alpha
GEM routines then one could expect it to produce Alpha code. It
wouldn't surprise me if some of Digital's earliest efforts at porting
to Alpha involved new GEM code with VESTed compilers.
And I did say it was all theoretical and that I hadn't actually tried
it. Not knowing if the GEM entry points are the same between Alpha &
VAX (I would think they are) or how they are packaged (shareable or
linked in with each compiler) I thought I left my comments fairly open-
ended and full of the necessary disclaimers.
FrankS
> I offered them here for nothing. I offered them in other places for
> free. As a last resort I put them on Ebay. I sold one for $100.
I know of four VAX 7640s that may become available by the end of the
year, if not sooner. They will likely be sold by the pound to a
computer systems liquidator.
If somebody is creating a VAX 7600 museum to complement the MicroVAX
II museum in Israel then maybe we'll find a better home for this
stuff. :-)
Malcolm Dunnett
> Not surprised, but some people actually don't believe in stealing
> software. I woould be willing to bet that there are a lot of
> commercial VMS systems running with Hobbyist PAKs.
>
I'd take that bet if there was any way to prove it one way or the
other. Personally I doubt there's "a lot" of that going on. For one
thing there aren't "a lot" of commercial VMS systems out there (compared
to Windows or Linux). An organization sophisticated enough to recognize
the value of VMS probably is sophisticated enough to realize the risk
they could be at by running pirate software.
I would bet that the percentage of VMS systems running with dodgy
software licensing is several orders of magnitude below the percentage
of Windows systems that are improperly licenses.
VMS licenses are actually pretty cheap these days (at least for the
"foundation" level). If you can afford an Itanium box from HP you can
probably afford the VMS license.
I believe that what the OP was actually saying was that there are
many VAX sites running older versions of VMS that they aren't paying
support fees on anymore ( which is perfectly legal as the licenses are
perpetual ).
Tom Linden
How about the computer history museum in San Jose? I think I know someone
who might be interested, drop me a note offline.
--
PL/I for OpenVMS
www.kednos.com
Richard B. Gilbert
> In article <47B2C5F8.23...@infovax.stanq.com>,
> "Stanley F. Quayle" <inf...@stanq.com> writes:
>
>>>this not leave you stuck keeping, maintaining and paying licensing for a VAX
>>
>>Paying for licenses?
>>
>>I encounter customers all the time that don't know that HP owns VMS. They're certainly
>>not paying anyone license fees for their VAX.
>>
>
>
> Not surprised, but some people actually don't believe in stealing
> software. I woould be willing to bet that there are a lot of
> commercial VMS systems running with Hobbyist PAKs.
>
And some of us bought systems with licenses included!
Richard B. Gilbert
A support contract on modern equipment is anything but cheap.
Supporting antiques usually costs extra!
Bill Gunshannon
Malcolm Dunnett <not...@spammers.are.scum> writes:
> Bill Gunshannon wrote:
>
>> Not surprised, but some people actually don't believe in stealing
>> software. I woould be willing to bet that there are a lot of
>> commercial VMS systems running with Hobbyist PAKs.
>>
>
> I'd take that bet if there was any way to prove it one way or the
> other. Personally I doubt there's "a lot" of that going on. For one
> thing there aren't "a lot" of commercial VMS systems out there (compared
> to Windows or Linux).
I guess "a lot" is rather subjective. 10 VMS sites doing it would be a
lot more relative to the number of legitimate VMS sites than 10,000 MS
sites relative to the number of MS systems.
> An organization sophisticated enough to recognize
> the value of VMS probably is sophisticated enough to realize the risk
> they could be at by running pirate software.
You would think that, but my experience is quite different. I have spent
a lot of time and effort convincing people here that they can't buy one
copy of a program and then install it on every machine in site.
>
> I would bet that the percentage of VMS systems running with dodgy
> software licensing is several orders of magnitude below the percentage
> of Windows systems that are improperly licenses.
Again, it probably depends on your interpretation of "commercial use".
I had a lot of people tell me that I should have just been using a
hobbyist license for the machines I set up for the students to play
with. That is certainly not the way I see it and I never did it.
Same thing with the PDP-11's I set up. There is no hobbyist or edu
program for them and still I had dozens of people telling me to just
go ahead and do it. Software piracy is a bigger problem than many
people want to admit and it is not limited to MS products.
>
> VMS licenses are actually pretty cheap these days (at least for the
> "foundation" level). If you can afford an Itanium box from HP you can
> probably afford the VMS license.
But we are not talking about Itaniums, we are talking about VAX.
>
> I believe that what the OP was actually saying was that there are
> many VAX sites running older versions of VMS that they aren't paying
> support fees on anymore ( which is perfectly legal as the licenses are
> perpetual ).
Not the way I read it: "Paying for licenses?
I encounter customers all the time that don't know
that HP owns VMS. They're certainly not paying anyone
license fees for their VAX."
Hard to interpret that as anything short of running VAX without
a valid license.
Stanley F. Quayle
> Not the way I read it: "Paying for licenses?
> I encounter customers all the time that don't know
> that HP owns VMS. They're certainly not paying anyone
> license fees for their VAX."
>
> Hard to interpret that as anything short of running VAX without
> a valid license.
What I meant was that the licenses that came with their VAX, good forever, stay good for,
well, forever.
Stanley F. Quayle
> I don't think it was too much of a stretch to guess that the GEM
> functions common to all compilers would be located in a shareable
> image. Since, to my knowledge, GEM generates the object files then
> the Alpha version of the GEM code would generate Alpha objects with
> Alpha instructions.
You could ask Tom Linden of Kednos. He now owns the PI/I compiler, which is available
for VAX and Alpha. It uses GEM.
That's also the reason that PI/I isn't available for Itanium -- GEM changed and HP hasn't
released the API.
> If you VEST the DIBOL compiler and are able to mate it to the Alpha
> GEM routines then one could expect it to produce Alpha code.
Sounds like a lot of work compared to running CHARON-VAX [Shameless Plug Alert (tm) I am
a CHARON reseller]. In a couple of days, he'd be done. Not all customers are up to
reverse-engineering something like a compiler.
Bob Koehler
>
> I don't think it was too much of a stretch to guess that the GEM
> functions common to all compilers would be located in a shareable
> image. Since, to my knowledge, GEM generates the object files then
> the Alpha version of the GEM code would generate Alpha objects with
> Alpha instructions.
The contents of, and use of, the GEM back end is not consistent
across compilers. The concept and much of the implementation is
the same.
Bill Gunshannon
>> Not the way I read it: "Paying for licenses?
>> I encounter customers all the time that don't know
>> that HP owns VMS. They're certainly not paying anyone
>> license fees for their VAX."
>>
>> Hard to interpret that as anything short of running VAX without
>> a valid license.
>
> What I meant was that the licenses that came with their VAX, good forever, stay good for,
> well, forever.
OK, I stand corrected. I guess I have seen so much violation of IP
rights I have just become too cynical.
Dan Allen
> -----Original Message-----
> From: Stanley F. Quayle [mailto:inf...@stanq.com]
> Sent: Wednesday, February 13, 2008 12:36 PM
> To: Info...@Mvb.Saic.Com
> Subject: Re: VMS license fees?
>
> On 13 Feb 2008 at 17:02, Bill Gunshannon wrote:
> > Not the way I read it: "Paying for licenses?
> > I encounter customers all the time
> that don't know
> > that HP owns VMS. They're
> certainly not paying anyone
> > license fees for their VAX."
> >
> > Hard to interpret that as anything short of running VAX without a
> > valid license.
>
> What I meant was that the licenses that came with their VAX,
> good forever, stay good for, well, forever.
>
> --Stan Quayle
> Quayle Consulting Inc.
>
Indeed. I have a file cabinet drawer full of license PAKS originally purchased
for an 11/780 in the early eighties (including a host of unlimited VMS and
layerd product licenses) that were transferred as part of an Alpha upgrade and
are still good. Too bad there's no interest in the Alpha aside from me....
Dan
JF Mezei
>
> Not surprised, but some people actually don't believe in stealing
> software. I woould be willing to bet that there are a lot of
> commercial VMS systems running with Hobbyist PAKs.
I don't think so. Your presumption would assume that there would have
been new customers who started to use VMS since the hobbyisty programme
was started and who would have decided to use those licences "illegally".
I would think that almost all customers are long tike VMS customers who
have had their licences for a very long time even if they no longer pay
for the support fees.
Where hobbyist may be "abused" are those legitimate shops needing a new
licence to compile some freeware utility etc and being unable to reach
Digital to buy such licence, they go the way of hobbyist.
Wilm Boerhout
> And some of us bought systems with licenses included!
If you bought them new, that's OK. If you bought'm second hand, (VAX or
Alpha), it's only OK for the base OS license + "hardware attached"
software (Category 1 software). All other licenses are not transferable
outside of the first owner legal entity (relicensing), although they are
transferable within the original legal entity (redesignation).
Relicensing is not free where it is permitted. Written permission from
HP required in all cases.
Software License Policy
http://licensing.hp.com/swl/view.slm?page=xfer
I'm not sure whether HP staff does enforce this policy, well, then
again, I'm sure they don't. When I was a Digital employee in the 80's,
everyone selling second hand knew this. It was enforced then.
--
Wilm Boerhout |
Zwolle, | - 'My memory's fine!'
The Netherlands | - 'But you keep forgetting your mistakes!'
remove OLD PAINT to reply| - 'Exactly!'
JF Mezei
> If you VEST the DIBOL compiler and are able to mate it to the Alpha
> GEM routines then one could expect it to produce Alpha code. It
> wouldn't surprise me if some of Digital's earliest efforts at porting
> to Alpha involved new GEM code with VESTed compilers.
Did any VAX compilers use GEM ?
Doug Phillips
<stafford.no.spam.winte...@verizon.net> wrote:
> John Reagan <john.rea...@hp.com> wrote innews:fotat3$tf1$1...@usenet01.boi.hp.com:
To echo Hank Vander Waal, DBL is DIBOL for the post-VAX era. At the
time of the Alpha port, Synergex (or was it still DISC then?) had
extended DBL to a higher level, while still keeping DIBOL
compatibility, and they were going to port DBL to Alpha anyway. DEC
likely decided that their own resources would be better utilized in
other areas.
Someone only familiar with DEC DIBOL should not harshly judge Synery/
DE (the modern name) by that standard any more than someone who hasn't
used VMS since early VAX should prejudge todays VMS by that
experience.
Beyond setting up the user environment as needed with any platform
change, moving from DIBOL to the Synergy product on VMS usually
involves little more than compile, rebuild your libraries and link
your apps. Then, you can play with all of the fancy new stuff
(Synergex offers training, too.)
We still have some apps running today that started life on
CTS-300/500, then met DBL on TSX+, and moved to VAX and Alpha with
little more effort than that. And, don't overlook the DIBOL features
you take for granted, like the built-in understanding and support of
RMS records/files and the convenience of the Message Manager, that
you'll need to "bolt-on" to most other languages.
Like HVW said, too, DBL can move to non-VMS platforms easier than most
languages. If your stuff is overly hard-coded with VMS specifics then
that would be a handicap for other languages, too. But, even if it is,
DBL might have a built-in subroutine or function that you could use
instead without having to reinvent your own or find a third-party
substitute.
On non-RMS platforms, DBL has a built-in file/record system that to
the programmer looks pretty much like RMS (even has RFA's.) We ported
an entire accounting system to Windows in only a few weeks. All of the
data files were stripped to sequential, copied over, and we used their
utilities to reload them. The first time we did this we were amazed at
how easy it was. It isn't 100% simple, but it's 99.99% easier than
converting that much code to any other language I know of.
Porting everything to a new language sounds like a programmers idea of
fun, but what's it really going to cost the business?
JF Mezei
> Sounds like a lot of work compared to running CHARON-VAX [Shameless Plug Alert (tm) I am
> a CHARON reseller]. In a couple of days, he'd be done. Not all customers are up to
> reverse-engineering something like a compiler.
From a hardware point of view, you are correct. Since Alpha is no longer
developped, it is just as dead as VAX so there is no real point to
migrate VAX to Alpha.
The one big difference however is that VMS is now sigificantly more
advanced on Alpha than on VAX, so moving to Alpha does give you many
software advantages. If not for that one application, it gives you for
oither applications.
If VMS were still developped on VAX, then the Charron solution would be
the best.
Now, if VMS development has been scaled down to a point where progress
is minimal from the point of view of the user/programmer, then the gap
between VAX-VMS and Alpha-VMS will stop growing. (aka: if new version of
VMS are made onlyto support new HP hardware, this doesn't change the
value of vMS to the user/programmer).
Bill Gunshannon
JF Mezei <jfmezei...@vaxination.ca> writes:
> Bill Gunshannon wrote:
>>
>> Not surprised, but some people actually don't believe in stealing
>> software. I woould be willing to bet that there are a lot of
>> commercial VMS systems running with Hobbyist PAKs.
>
> I don't think so. Your presumption would assume that there would have
> been new customers who started to use VMS since the hobbyisty programme
> was started and who would have decided to use those licences "illegally".
No, no such presumption. It would include someone who needs another
machine to test something and they are only going to need it for a
month or two, so........
>
> I would think that almost all customers are long tike VMS customers who
> have had their licences for a very long time even if they no longer pay
> for the support fees.
Seems like you are making suppositions, too.
>
> Where hobbyist may be "abused" are those legitimate shops needing a new
> licence to compile some freeware utility etc and being unable to reach
> Digital to buy such licence, they go the way of hobbyist.
And how is this any differnt than what I said up above? Not being
able to contact HP to buy a license does not change the legal or
moral responsibility to have a legitimate license in place before
using a machine for business purposes. Believe it or not, the
dificulty or inability to contact Mentec was the most common reason
given for running PDP-11's without valid licenses.
Tom Linden
<w6OLD.PAI...@planet.nl> wrote:
> on 13-2-2008 17:38 Richard B. Gilbert wrote...
>
>> And some of us bought systems with licenses included!
>
> If you bought them new, that's OK. If you bought'm second hand, (VAX or
> Alpha), it's only OK for the base OS license + "hardware attached"
> software (Category 1 software). All other licenses are not transferable
> outside of the first owner legal entity (relicensing), although they are
> transferable within the original legal entity (redesignation).
> Relicensing is not free where it is permitted. Written permission from
> HP required in all cases.
>
> Software License Policy
> http://licensing.hp.com/swl/view.slm?page=xfer
>
> I'm not sure whether HP staff does enforce this policy, well, then
> again, I'm sure they don't. When I was a Digital employee in the 80's,
> everyone selling second hand knew this. It was enforced then.
>
As a matter of law if you are aware of a violation and don't act to enforce
your rights you may abdicate them
Tom Linden
no
Stanley F. Quayle
> No, no such presumption. It would include someone who needs another
> machine to test something and they are only going to need it for a
> month or two, so........
DSPP members get VMS licenses for free, including VAX ones...
--Stan Quayle
Quayle Consulting Inc.
----------
Bill Gunshannon
>> No, no such presumption. It would include someone who needs another
>> machine to test something and they are only going to need it for a
>> month or two, so........
>
> DSPP members get VMS licenses for free, including VAX ones...
>
What does DSPP membership cost?
ultr...@gmail.com
<stafford.no.spam.winte...@verizon.net> wrote:
> John Reagan <john.rea...@hp.com> wrote innews:fotat3$tf1$1...@usenet01.boi.hp.com:
>
> > Bob Gezelter wrote:
>
> >> For porting, it depends on the style of code. If you want
> >> integrated (non-custom) support for access to indexed and other
> >> files, you are probably limited to BASIC, FORTRAN, and COBOL. It is
> >> not inherantly difficult to access keyed files from C/C++, but it
> >> will be in the nature of a non-integrated add-in (or in the case of
> >> C++, probably a class).
>
> > Not to divert the topic, but Pascal has just as good support for
> > indexed and relative files as the langauges listed above. Well, you
> > can't CREATE a file with segmented keys from Pascal without
> > resorting to a USERACTION routine, but you can open an existing file
> > and even use FINDK to lookup a record.
>
> It seems like DIBOL was quite a good language. Why did Digital drop it
> with the move to Alpha?
because of $$$$$$$$$$$$$$$$$$$$$$$$$$$$$
and they was stupid to do so ... the port would have been easy
and they lost a lot of business because of it, i.e. MCBA ...
DIBOL was a one time license multiple user solution unlike
synergy ... now synergy has many more features that takes
DIBOL to a whole other level, but those features are not free ...
MCBA was responsible for the huge DIBOL market with all
their accounting packages and there where many others
small companies because of that which began using it to
develop other packages such as legal software I used to
modify before ...
DEC pulled the rug from under them and synergy was unwilling
to give them a license break and MCBA ported to cobol and
cost DEC a lot of customers ... another stupid move on DECs
part ...
and DIBOL is superior to cobol, basic, pascal or any other
3GL ... going to those is a step backwards ...
ultr...@gmail.com
>
> - Show quoted text -
functionality is not the issue ... COST is ...
there are many small businesses with vax DIBOL packages
from many companies who cannot afford to spend $10,000+
dollars to go to synergy ... and unless synergy gives a price
break, they will loose these small customers which is exactly
the stupid move DEC made ...
call synergy first to try to get a price break, if not look at
at vaxstation 4000-96 or vest from vax to alpha ...
DO NOT PORT to something else which would cost a lot
more money ...
solutions exist ...
Bill Gunshannon
bill...@cs.uofs.edu (Bill Gunshannon) writes:
> In article <47B30415.23...@infovax.stanq.com>,
> "Stanley F. Quayle" <inf...@stanq.com> writes:
>> On 13 Feb 2008 at 18:48, Bill Gunshannon wrote:
>>> No, no such presumption. It would include someone who needs another
>>> machine to test something and they are only going to need it for a
>>> month or two, so........
>>
>> DSPP members get VMS licenses for free, including VAX ones...
>>
>
> What does DSPP membership cost?
Nevermind. I eventually found it (but it wan't easy or obvious.)
Of course, there are other requirements that would make my example
above not qualify anyway. So we're back to: someone who needs
another machine to test something and they are only going to need
it for a month or two, so........ :-)
Wilm Boerhout
[snip]
> Where hobbyist may be "abused" are those legitimate shops needing a new
> licence to compile some freeware utility etc and being unable to reach
> Digital to buy such licence, they go the way of hobbyist.
No excuses in my country. It is still possible (and not very difficult
either) for me and my customers to buy VMS licenses (the old Q*-*****-**
scheme). VAX as well as Alpha. Whether you like the price for your
VAX/DEC/HP C compiler is another thing...
--
Wilm Boerhout Zwolle, NL
remove OLD PAINT from return address to reply
Wilm Boerhout
> DSPP members get VMS licenses for free, including VAX ones...
Yes, but not to run their *own* business applications on. If you want to
sell email services using your Alpha as a server, DSPP licensing is not
enough. Demo purposes, OK.
Doug Phillips
> On Feb 13, 1:45 pm, Doug Phillips <dphil...@netscape.net> wrote
> > On Feb 12, 6:33 pm, Tad Winters
>
>
> > Porting everything to a new language sounds like a programmers idea of
> > fun, but what's it really going to cost the business?
>
>
How much will it cost to duplicate the functionality? I can't separate
the two in my mind. Maybe you can. Like someone who hangs around here
is fond of saying: The choices are good, fast and cheap; pick two.
> there are many small businesses with vax DIBOL packages
> from many companies who cannot afford to spend $10,000+
> dollars to go to synergy
An operation with 150 interactive users likely has annual revenue of
at least $10M - $20M/year. A company running an old VAX for all of
their mission-critical has likely not spent their industry average
percentage of income on IT for years, and has become "spoiled."
Sometimes reality sucks.
> ... and unless synergy gives a price
> break, they will loose these small customers which is exactly
> the stupid move DEC made ...
>
> call synergy first to try to get a price break,
Or at least get an actual number that could be used for cost analysis.
> if not look at
> at vaxstation 4000-96 or vest from vax to alpha ...
>
Both short-sighted choices, IMO, if the future is of any concern. The
old saw "penny wise and pound foolish" comes to mind.
> DO NOT PORT to something else which would cost a lot
> more money ...
If cost is the only factor, or the company doesn't expect to be around
for long, then they shouldn't do much of anything. If things are
working fine except for a few high-load times, then some job
rescheduling might be enough.
> solutions exist ...
and it's usually better to pick a good one.
Tad Winters
news:95285ad2-9ac4-4042...@d70g2000hsb.googlegroups.com:
> On Feb 12, 6:33 pm, Tad Winters
> <stafford.no.spam.winte...@verizon.net> wrote:
>> It seems like DIBOL was quite a good language. Why did Digital
>> drop it with the move to Alpha?
>
>
> To echo Hank Vander Waal, DBL is DIBOL for the post-VAX era. At the
> time of the Alpha port, Synergex (or was it still DISC then?) had
It was still DISC.
> extended DBL to a higher level, while still keeping DIBOL
> compatibility, and they were going to port DBL to Alpha anyway. DEC
> likely decided that their own resources would be better utilized in
> other areas.
So they decided that it was better to give someone else the business
rather than compete. That's an interesting way to do business.
>
> Someone only familiar with DEC DIBOL should not harshly judge
> Synery/ DE (the modern name) by that standard any more than someone
> who hasn't used VMS since early VAX should prejudge todays VMS by
> that experience.
"harshly judge"? Who's doing that?
>
> Beyond setting up the user environment as needed with any platform
> change, moving from DIBOL to the Synergy product on VMS usually
> involves little more than compile, rebuild your libraries and link
> your apps. Then, you can play with all of the fancy new stuff
> (Synergex offers training, too.)
With the move of some other code from DIBOL to DBL, there were a number
of things that didn't just compile. I remember one item was the
DISPLAY statements which didn't work with field attributes. Also, the
SLICE subroutine that was included in DIBOL was absent in DBL.
Strangely, some other programmer put in some conditional compilation
statements to avoid calling it under DBL. When I found it later, I
just wrote a SLICE subroutine to accomplish the task. (It was only a
few lines of code.)
>
> We still have some apps running today that started life on
> CTS-300/500, then met DBL on TSX+, and moved to VAX and Alpha with
> little more effort than that. And, don't overlook the DIBOL features
> you take for granted, like the built-in understanding and support of
> RMS records/files and the convenience of the Message Manager, that
> you'll need to "bolt-on" to most other languages.
We had a customer who used TSX+ and DBL. We also had one on RSTS (I
think) in which we had to carefully craft the linking of the code
because of 32K code segments.
We definite use the Message Manager. I hadn't really considered that.
To address that use, I guess I'd have to write a replacement. Yikes,
that sounds like a whole lot more work.
>
> Like HVW said, too, DBL can move to non-VMS platforms easier than
> most languages. If your stuff is overly hard-coded with VMS
> specifics then that would be a handicap for other languages, too.
> But, even if it is, DBL might have a built-in subroutine or function
> that you could use instead without having to reinvent your own or
> find a third-party substitute.
If the goal was to change platforms, I would prefer to not carry the
old code along. I'd rather just look at the old functionality and
write from scratch.
>
> On non-RMS platforms, DBL has a built-in file/record system that to
> the programmer looks pretty much like RMS (even has RFA's.) We
> ported an entire accounting system to Windows in only a few weeks.
> All of the data files were stripped to sequential, copied over, and
> we used their utilities to reload them. The first time we did this
> we were amazed at how easy it was. It isn't 100% simple, but it's
> 99.99% easier than converting that much code to any other language I
> know of.
>
> Porting everything to a new language sounds like a programmers idea
> of fun, but what's it really going to cost the business?
I'm not sure I'd call it fun, but it is an excuse to create what I
would consider better code, exchanging cryptic variable name for one
with clear meaning, moving away from the idea that a particular
variable has to be used for completely different purposes, just to save
memory, allowing the applications to make use of the full size of
screen when terminals (emulators) have move than 24 rows and/or 80
columns, etc.
Richard B. Gilbert
>
>
>
>>-----Original Message-----
>>From: Stanley F. Quayle [mailto:inf...@stanq.com]
>>Sent: Wednesday, February 13, 2008 12:36 PM
>>To: Info...@Mvb.Saic.Com
>>Subject: Re: VMS license fees?
>>
>>On 13 Feb 2008 at 17:02, Bill Gunshannon wrote:
>>
>>>Not the way I read it: "Paying for licenses?
>>> I encounter customers all the time
>>
>>that don't know
>>
>>> that HP owns VMS. They're
>>
>>certainly not paying anyone
>>
>>> license fees for their VAX."
>>>
>>>Hard to interpret that as anything short of running VAX without a
>>>valid license.
>>
>>What I meant was that the licenses that came with their VAX,
>>good forever, stay good for, well, forever.
>>
>>--Stan Quayle
>>Quayle Consulting Inc.
>>
>
>
> Indeed. I have a file cabinet drawer full of license PAKS originally purchased
> for an 11/780 in the early eighties (including a host of unlimited VMS and
> layerd product licenses) that were transferred as part of an Alpha upgrade and
> are still good. Too bad there's no interest in the Alpha aside from me....
I think your dates are a little off Dan. In 1984 there were licenses
but no License PAKs. You did need a software "patch" to enable DECnet
but that was not the same thing as a PAK.
Paper license PAKs came along a couple of years later!
Doug Phillips
If you remember, MCBA was bought out and it was the new owners who
tried to force the customer-base to either buy their package or find
another solution. That software carried a very high price and many
companies bailed rather than cough up the often $100K or so for the
"upgrade" to stay with the new owners -- who were known to be, um,
less concerned about customer support than one might desire.
Near the end, MCBA had a large presence in the DISC/DBL world, maybe
even larger than in DEC DIBOL.
> and DIBOL is superior to cobol, basic, pascal or any other
> 3GL ... going to those is a step backwards ...
Well, DBL (Synergy/DE) is, IMO anyway. Actual DIBOL was nice and quite
easy to learn and code, but other languages were gaining capabilities
that DIBOL didn't have. Synergy/DE, on the other hand, has some really
great features that are not "built-in" to most other languages.
Richard B. Gilbert
> on 13-2-2008 17:38 Richard B. Gilbert wrote...
>
>> And some of us bought systems with licenses included!
>
>
> If you bought them new, that's OK. If you bought'm second hand, (VAX or
> Alpha), it's only OK for the base OS license + "hardware attached"
> software (Category 1 software). All other licenses are not transferable
> outside of the first owner legal entity (relicensing), although they are
> transferable within the original legal entity (redesignation).
> Relicensing is not free where it is permitted. Written permission from
> HP required in all cases.
I bought from a dealer and the machine was new. This was back in the
late 1990's when the AlphaStation 200 went EOL.
VAXman-
> "Stanley F. Quayle" <inf...@stanq.com> writes:
>> On 13 Feb 2008 at 18:48, Bill Gunshannon wrote:
>>> No, no such presumption. It would include someone who needs another
>>> machine to test something and they are only going to need it for a
>>> month or two, so........
>>
>> DSPP members get VMS licenses for free, including VAX ones...
>>
>
>What does DSPP membership cost?
If you have to ask Bill, you can't afford it. ;)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
VAXman-
1987/88 time frame when VMS V5.0 and the LMF were introduced.
Doug Phillips
<stafford.no.spam.winte...@verizon.net> wrote:
> Doug Phillips <dphil...@netscape.net> wrote innews:95285ad2-9ac4-4042...@d70g2000hsb.googlegroups.com:
>
> > On Feb 12, 6:33 pm, Tad Winters
> > <stafford.no.spam.winte...@verizon.net> wrote:
> >> It seems like DIBOL was quite a good language. Why did Digital
> >> drop it with the move to Alpha?
>
> > To echo Hank Vander Waal, DBL is DIBOL for the post-VAX era. At the
> > time of the Alpha port, Synergex (or was it still DISC then?) had
>
> It was still DISC.
That's what I thought, but I didn't look it up.
>
> > extended DBL to a higher level, while still keeping DIBOL
> > compatibility, and they were going to port DBL to Alpha anyway. DEC
> > likely decided that their own resources would be better utilized in
> > other areas.
>
> So they decided that it was better to give someone else the business
> rather than compete. That's an interesting way to do business.
>
Yea, bean-counters tend to look at cost-benefit kinds of things. DIBOL
wasn't really making enough money to justify the cost of porting it to
compete with DBL, which was a "better" DIBOL.
So, once DISC bought out Softbol and DEC handed them the Alpha, DISC
had a monopoly on the language. I think that fact more than any other
ticked some people off and caused them to bail.
>
>
> > Someone only familiar with DEC DIBOL should not harshly judge
> > Synery/ DE (the modern name) by that standard any more than someone
> > who hasn't used VMS since early VAX should prejudge todays VMS by
> > that experience.
>
> "harshly judge"? Who's doing that?
>
My mistake.
>
>
> > Beyond setting up the user environment as needed with any platform
> > change, moving from DIBOL to the Synergy product on VMS usually
> > involves little more than compile, rebuild your libraries and link
> > your apps. Then, you can play with all of the fancy new stuff
> > (Synergex offers training, too.)
>
> With the move of some other code from DIBOL to DBL, there were a number
> of things that didn't just compile. I remember one item was the
> DISPLAY statements which didn't work with field attributes. Also, the
> SLICE subroutine that was included in DIBOL was absent in DBL.
> Strangely, some other programmer put in some conditional compilation
> statements to avoid calling it under DBL. When I found it later, I
> just wrote a SLICE subroutine to accomplish the task. (It was only a
> few lines of code.)
>
The screen attributes were something I'd forgotten about. All of our
screen I/O was done (or was *supposed* to be done:-) in subroutines,
though, and those were simple to convert. The compiler uncovered the
few "stragglers" and that forced us to clean things up. Not even a
days worth of work if I recall.
I don't recall ever using SLICE so that was not a problem. ISTR, now
that you've mentioned those, there were a few other minor differences
that were easy to fix or just needed a DBLOPT setting. We'd probably
done most of the work when we took the code to TSX, which was before
we ever saw a VAX.
>
>
> > We still have some apps running today that started life on
> > CTS-300/500, then met DBL on TSX+, and moved to VAX and Alpha with
> > little more effort than that. And, don't overlook the DIBOL features
> > you take for granted, like the built-in understanding and support of
> > RMS records/files and the convenience of the Message Manager, that
> > you'll need to "bolt-on" to most other languages.
>
> We had a customer who used TSX+ and DBL. We also had one on RSTS (I
> think) in which we had to carefully craft the linking of the code
> because of 32K code segments.
Overlays. Yuck. Bad memories. The need for linking overlays was one of
the reasons our code was so modular, though, and that made many things
easier to port. Our code was no where near as "modular" (if that's the
word) as the MCBA stuff, though. Their code was hard to deal with, and
we inherited a few of their abandoned sites to support. Most we
converted to our stuff for near-cost just to get away from maintaining
that ####. Some we lost to merger or acquisition, but some of those
sites are still around today running on VMS (not exactly using the
same old code, though:-)
> We definite use the Message Manager. I hadn't really considered that.
> To address that use, I guess I'd have to write a replacement. Yikes,
> that sounds like a whole lot more work.
>
SO many things we've come to take for granted;-)
>
>
> > Like HVW said, too, DBL can move to non-VMS platforms easier than
> > most languages. If your stuff is overly hard-coded with VMS
> > specifics then that would be a handicap for other languages, too.
> > But, even if it is, DBL might have a built-in subroutine or function
> > that you could use instead without having to reinvent your own or
> > find a third-party substitute.
>
> If the goal was to change platforms, I would prefer to not carry the
> old code along. I'd rather just look at the old functionality and
> write from scratch.
>
More fun. Much more time. Much more $$$.
>
>
> > On non-RMS platforms, DBL has a built-in file/record system that to
> > the programmer looks pretty much like RMS (even has RFA's.) We
> > ported an entire accounting system to Windows in only a few weeks.
> > All of the data files were stripped to sequential, copied over, and
> > we used their utilities to reload them. The first time we did this
> > we were amazed at how easy it was. It isn't 100% simple, but it's
> > 99.99% easier than converting that much code to any other language I
> > know of.
>
> > Porting everything to a new language sounds like a programmers idea
> > of fun, but what's it really going to cost the business?
>
> I'm not sure I'd call it fun, but it is an excuse to create what I
> would consider better code, exchanging cryptic variable name for one
> with clear meaning, moving away from the idea that a particular
> variable has to be used for completely different purposes, just to save
> memory, allowing the applications to make use of the full size of
> screen when terminals (emulators) have move than 24 rows and/or 80
> columns, etc.
Cleaning up variable names and spaghetti code and such might be good,
and porting to a different language will mean finding new ways to do
some things anyway. The temptation to "fix" or "improve" too many
things, though, means going "off-script." Debugging gets more
difficult because the new stuff no longer follows the old flow and if
something doesn't work you have to determine if the bug was in the
original logic and has now decided to surface, or was caused by an
"improvement." Been there. I've had better results porting the logic
"feature for feature," noting where I'd make any significant changes,
making allowances in the code and implementing them after the new code
has been tested and proven sound. Each to his own, though:-)
I've become so accustomed to the power of DBL that using any other
language for business apps seems painful, so I guess I am a bit biased.
8^O
FrankS
> What I meant was that the licenses that came with their VAX, good forever, stay good for,
> well, forever.
I don't remember what the license policies were back when Digital was
issuing them. Current HP policy is that the license you buy is good
for the version you buy, and nothing else. In order to install new
versions you must be on a software support contract which gives you
the "right to new versions" (RTNV).
So, if you buy an OpenVMS Base license today at the current version
(v8.3-1H1) and don't get a software support contract then you are not
allowed to upgrade, say, to v8.4 when it is issued. You can continue
to run v8.3-1H1 forever, though.
FrankS
> No, no such presumption. It would include someone who needs another
> machine to test something and they are only going to need it for a
> month or two, so........
HP can and does issue temporary licenses. I would think they're a bit
tight-fisted about them and probably don't do it unless you're on a
support contract.
Tad Winters
[..snip..]
> I've become so accustomed to the power of DBL that using any other
> language for business apps seems painful, so I guess I am a bit
> biased. 8^O
>
So you're still coding in DBL? If I could find some more companies in my
area in need of someone to maintain their DBL code, I'd be pretty happy.
The 2 companies I do occasional work for right now just ask for minor
changes or minor new features. The last "large" projects were
implementing faxing of invoices (a failure since they counted on using a
VOIP line), emailing invoices (CSV file created and transferred to a *nix
box at an ISP to be converted to PDF), and parsing a tab delimited file,
received via ftp from an ISP hosted web server, into an order.
Richard B. Gilbert
DEC's policy was the same!
Tom Linden
wrote:
> Well, DBL (Synergy/DE) is, IMO anyway. Actual DIBOL was nice and quite
> easy to learn and code, but other languages were gaining capabilities
> that DIBOL didn't have. Synergy/DE, on the other hand, has some really
> great features that are not "built-in" to most other languages.
Like what?
ultr...@gmail.com
<stafford.no.spam.winte...@verizon.net> wrote:
goldfax and dibol work together
ultr...@gmail.com
<stafford.no.spam.winte...@verizon.net> wrote:
goldfax and dibol work together quite well ... T1s fail as well as
other
IP based solutions, but good old copper lines are solid for fax
uptime ...
why not run their own web server? purveyor/wasd and dibol/dcl as
script languages work terrific ...
txt2pdf runs under perl on vms ... they could create their own pdfs
on vms and send them out as attachments with pmdf ... and vms
makes the perfect mail server with precisemail antispam and sophos
antivirus along with Mark Daniels soymail webmail freeware ...
sounds like they need to hire a dibol/vms person full time to
put everything under their own roof ... letting your business
be run by other companies is a bad situation ...
vms does not get viruses or trojans or hacked either ...
they are on the perfect os to do everything in house
inexpensively ... why are they not taking advantage
of it ...
Doug Phillips
> On Wed, 13 Feb 2008 13:45:46 -0800, Doug Phillips <dphil...@netscape.net>
> wrote:
>
> > Well, DBL (Synergy/DE) is, IMO anyway. Actual DIBOL was nice and quite
> > easy to learn and code, but other languages were gaining capabilities
> > that DIBOL didn't have. Synergy/DE, on the other hand, has some really
> > great features that are not "built-in" to most other languages.
>
> Like what?
Not easy to answer here, so you'll have to look for yourself:
We are no longer a reseller, and receive no rewards for promoting it,
but we do have a lot of DBL code running in enough places to provide a
major percentage of our income. So anyone interested in Synergy/DE
should contact Synergex directly. They're good people and while I
haven't always agreed with the direction they've taken, I appreciate
the fact that they do have a good product and do care about their
customers.
I guess I could likewise ask: What does PL/I offer that Synergy/DE
doesn't? - except you asked first:-)
Larry Kilgallen
> I don't think it was too much of a stretch to guess that the GEM
> functions common to all compilers would be located in a shareable
> image.
It might not be much of a stretch, but it is not true.
> It
> wouldn't surprise me if some of Digital's earliest efforts at porting
> to Alpha involved new GEM code with VESTed compilers.
The actual approach was building cross compilers on VAX.
Tad Winters
news:918112b7-97c1-452a...@s13g2000prd.googlegroups.com:
> On Feb 13, 7:49 pm, Tad Winters
> <stafford.no.spam.winte...@verizon.net> wrote:
>> Doug Phillips <dphil...@netscape.net> wrote
>> innews:eebcffae-f4a5-4df2...@s12g2000prg.googlegroups
>> .com:
>>
>> [..snip..]
>>
>> > I've become so accustomed to the power of DBL that using any
>> > other language for business apps seems painful, so I guess I am a
>> > bit biased. 8^O
>>
>> So you're still coding in DBL? If I could find some more companies
>> in my area in need of someone to maintain their DBL code, I'd be
>> pretty happy. The 2 companies I do occasional work for right now
>> just ask for minor changes or minor new features. The last "large"
>> projects were implementing faxing of invoices (a failure since they
>> counted on using a VOIP line), emailing invoices (CSV file created
>> and transferred to a *nix box at an ISP to be converted to PDF),
>> and parsing a tab delimited file, received via ftp from an ISP
>> hosted web server, into an order.
>
> goldfax and dibol work together quite well ... T1s fail as well as
> other
> IP based solutions, but good old copper lines are solid for fax
> uptime ...
I suggested looking at other faxing software before the project
started, but the lead said he wanted to stick with what he'd used
before.
> why not run their own web server? purveyor/wasd and dibol/dcl as
> script languages work terrific ...
The system is already overloaded.
> txt2pdf runs under perl on vms ... they could create their own pdfs
> on vms and send them out as attachments with pmdf ... and vms
> makes the perfect mail server with precisemail antispam and sophos
> antivirus along with Mark Daniels soymail webmail freeware ...
I looked into txt2pdf and wanted to use it, but I couldn't get them to
make the necessary changes with their ISP, i.e. MX record for their IP
address, DNS IP addresses for the VMS system to do lookups for sending
email and preferably letting the VMS system do zone transfers (to be a
secondary.)
PMDF would be more software on an already overloaded system, more
money, and would require them to open port 25 on their firewall. Since
they're managing the firewall themselves, I don't think I could get
them to do it. Also, anti-spam would be more load and more money.
> sounds like they need to hire a dibol/vms person full time to
> put everything under their own roof ... letting your business
> be run by other companies is a bad situation ...
Once again, more money. Someone else mentioned they must not be
spending enough, based on what their revenues must be for having 150
concurrent users. I don't know what their revenues are, though I could
look, since I have access to their system, but it's not my business.
If I really need to know, I'll ask. If it's only to tell them they're
not spending enough, then it's just as easy to tell them what is called
for in the industry.
ultr...@gmail.com
<stafford.no.spam.winte...@verizon.net> wrote:
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
put pmdf on a separate DS10L ... they only cost $200
plus memory and disks from island ... a ds10l is cheap
and would make a great mailserver or webserver ...
you do not have to run everything on one system ...
alphas are cheap enough to load balance with
multiple systems ...
ds20e systems were on ebay for $800 last year ...
for $1500 you could have bought another 667mhz
cpu card and 4gb mem ... just last week there was
an es40 with 4 833mhz cpus for only $3000 ...
can't they afford $200 for another alpha?
ultr...@gmail.com
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
why have IP and be afraid of using it?
have they ever heard of internal networks?
vms doesn't get viruses or trojans or hacked when properly
configured ... they are not getting the most out of their vms
investment ... how are these guys even in business if they
are afraid to use IP? tell them just to go back to phones
and paper and just manually fax stufff ... unbelievable ...
ultr...@gmail.com
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
put the vms mail or web servers outside of the useless
firewall ...
vms does not need no firewall ... it is its own firewall!
have they ever heard of captive accounts, acls?
vms configured properly is better than any firewall
they could ever buy ... sounds like someone does not
know what they are doing ...
ultr...@gmail.com
>
> - Show quoted text -
then with your vms mailserver front end outside the firewall,
you connect your internal vms box with decnet and
MCR NCP SET NODE node ACCESS OUTGOING
and even if you let someone on the mail or web server,
you could get to that box with decnet but they could
never log on to your internal system ...
so lets recap ...
putting a $200 ds10l as your mail server outside of that
useless firewall using mail accounts that only had
mailbox privs would be TOTALLY secure ... and you
could download Mark Daniels WASD webserver and
SOYMAIL webmail and have FREE webmail!
putting PURVEYOR/WASD on a $200 ds10l outside the
firewall would allow them to have their web apps run
using dibol/dcl scripts and then update or access the
web data from an internal alpha over a ONE WAY
decnet connection ...
and purveyor runs on alpha or vax ...
it this simple and cheap enough? and if you have a vax
internally you could run an alpha for the mail/web stuff
and VEST develop you dibol scripts on the vax and VEST
them over to run on the alpha mail/web server ... so you
would not even have to buy synergy dbl ...
what a totally secure, cheap, virus free, unhackable and
simple solution ...
now if you could only find someone at these companies
who could understand it ...
John Reagan
> On Feb 13, 10:00 am, "Stanley F. Quayle" <info...@stanq.com> wrote:
>
>>There's no shareable image that generates Alpha or any other kind of code. There's a
>>back-end tool called GEM that most VMS compilers use, but it's not something that you can
>>just use.
>
>
> I don't think it was too much of a stretch to guess that the GEM
> functions common to all compilers would be located in a shareable
> the Alpha version of the GEM code would generate Alpha objects with
> Alpha instructions.
>
> If you VEST the DIBOL compiler and are able to mate it to the Alpha
> GEM routines then one could expect it to produce Alpha code. It
> wouldn't surprise me if some of Digital's earliest efforts at porting
> to Alpha involved new GEM code with VESTed compilers.
>
> it. Not knowing if the GEM entry points are the same between Alpha &
> VAX (I would think they are) or how they are packaged (shareable or
> linked in with each compiler) I thought I left my comments fairly open-
> ended and full of the necessary disclaimers.
1) GEM doesn't exist on VAX. There is no COMMON VAX code generator
shared by all the compilers. Some compilers share the VCG (or at least
variants of it), but many VAX compilers (BLISS, FORTRAN, Pascal, COBOL,
perhaps BASIC) have their own unique VAX code generators. I have no
idea what the original VAX DIBOL compiler used as a code generator.
2) The interface to GEM isn't just an API. It is a large set of data
structures (intermediate language, symbol tables, etc.) and several
dozen "callbacks" from GEM back into the language frontend.
3) GEM is not packaged as a shareable. Compiler teams only get it in
object form and a set of headers. It is not available for general use.
4) While GEM tries to isolate system-specific details from the compiler
front-end (file I/O, command line processing, etc.), compiler front-ends
still need to have specific code for certain calling standard issues.
--
John Reagan
OpenVMS Pascal/Macro-32/COBOL Project Leader
Hewlett-Packard Company
Stanley F. Quayle
> HP can and does issue temporary licenses. I would think they're a bit
> tight-fisted about them and probably don't do it unless you're on a
> support contract.
Gosh, I get them for clients easily from my VMS Ambassador. And they never have support
contracts...
--Stan Quayle
Quayle Consulting Inc.
----------
Stanley F. Quayle, P.E. N8SQ Toll free: 1-888-I-LUV-VAX
8572 North Spring Ct., Pickerington, OH 43147 USA
stan-at-stanq-dot-com http://www.stanq.com/charon-vax.html
"OpenVMS, when downtime is not an option"