On 2022-10-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 10/12/22 09:05, Simon Clubley wrote:
>>
>>
>> Unfortunately, when architectures are changed not all packages make it
>> across to the new architecture.
>
> And the result is the loss of even more customers. How many can VMS
> afford to loose?

None. VSI are marketing to existing users, which is a fixed-size market.

There's no way that a completely new customer who has never seen VMS before
will move to VMS for the first time in 2022/2023.

>>
>> For example, VAXELN was abandoned when the move to Alpha occurred and
>> it looks like there will be no Ada compiler for x86-64 VMS.
>
> That's just silly. VAXELN was tied to the VAX architecture it would
> have been abandoned no matter what architecture VMS moved to.
>

Exactly. It's a perfect example of something that would be left behind.

Compilers are another good example. Because of the changes required to
compilers to move to another architecture, that's another language that
might not be available on the new architecture and hence a set of users
with their own applications written in that language which are left
without any viable path to move to the new architecture.

>>
>> The question is, just how major are the packages that are being lost ?
>
> How major they are is dependent on the user, none of them are really
> major to VSI.
>

They are if it stops a noticable number of sites from moving to x86-64 VMS.

>> Oracle Classic is a major example of something that has been lost, but
>> that's tied to VMS in general, not just x86-64 VMS.
>>
>> There's been no negative comments about Rdb recently, so I assume that
>> is still on course for release on x86-64 VMS. Of course, if Rdb wasn't
>> released for x86-64 VMS then that would be a very serious blow to VSI's
>> plans.
>
> A database is the least serious of these problems. VSI could easily
> (well, maybe not easily) decide that Postgres was going to be the VMS
> database just like RDB was, at one time, a DEC product. It is easily
> a suitable replacement for either Oracle or RDB. Just suffers from NIH
> syndrome.
>

So you think you can replace RDB with Postgres just like that in an
application ?

VSI have done some work here IIRC, but that's still going to be one hell
of a compatibility layer to avoid having to rewrite existing programs and
alter existing database operational procedures.

If they have to rewrite their applications using Postgres, then that's
another chunk of users that may just decide to run the Postgres application
on Linux instead.

>>
>> So the question is, of the other packages Marc uses, how many of them
>> are in general use within the VMS user base as a whole ?
>
> Doesn't really matter if the loss of these means they can't or won't
> move forward on VMS.
>

Exactly.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 10/12/2022 12:22 PM, Bill Gunshannon wrote:
> On 10/12/22 10:03, Dave Froble wrote:
>> On 10/12/2022 5:03 AM, Marc Van Dyck wrote:
>>> on 11/10/2022, Arne Vajhøj supposed :
>>>> On 10/11/2022 11:27 AM, Dave Froble wrote:
>>>>> On 10/11/2022 9:00 AM, Simon Clubley wrote:
>>>>>> On 2022-10-11, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
>>>>>>> The lack of attention to third party software editors is in my opinion
>>>>>>> even worse than that.
>>>>>> If so, I am surprised at that. I thought VSI were in communication with
>>>>>> the various third-party software developers. Are you saying that is not
>>>>>> happening ?
>>>>>
>>>>> Not sure what Marc is looking for. I've gotten ISV stuff from VSI. No
>>>>> problem. However if Marc is looking for VSI to get involved in any way with
>>>>> marketing and sales of 3rd party software, I'm thinking VSI is fully tasked
>>>>> with their own issues. Can't do everything.
>>>>
>>>> I agree.
>>>>
>>>> VSI got a good ISV program.
>>>>
>>>> I have no reason to doubt that VSI is working with major
>>>> third party software vendors.
>>>>
>>>> Oracle DB (Oracle Classic) client kit was obviously a
>>>> disappointment, but VSI can't force Oracle to do anything.
>>>>
>>>> VSI does not have resources to offer engineering
>>>> support to the smaller third party software vendors.
>>>>
>>>> Given the industry landscape and VSI's size, then I think
>>>> they are doing what they can.
>>>>
>>>> Arne
>>>
>>> Most of the software packages that we are using today won't be ported
>>> to X86. That includes, but is not limited to, Oracle Classic client,
>>> the old Polycenter products (now owned by Broadcom), the $Universe
>>> multi-platform scheduler, Axway Transfer CFT, etc. We're going to have
>>> to find replacements for all that, and review all our home grown apps
>>> to use them. So for us, no the VSI ISV program is not particularly good.
>>> And I do not see any reason why we should consider ourselves as an
>>> exception.
>>>
>>
>> It would seem to me that the current owners of the mentioned software would be
>> responsible for porting their software, not VSI.
>
> I don't see where they have any responsibility to port it one way or the
> other. Of course, neither does VSI.
>
>>
>> Have you asked these entities to provide their software on x86 VMS? Selling
>> their products and services is what they are about, isn't it? If not, then I
>> for one do not understand what they consider their business. If they would
>> desire to port their software, the ISV program would provide them with the
>> capability.
>
> And if they see the cost as far too much more than the expected ROI?
>
>>
>> If the owners of the mentioned software products decline to port them to x86
>> VMS, then that perhaps is business opportunities for other vendors.
>>
>> I fail to understand why you might consider this a problem with the VSI ISV
>> program.
>>
>
> Yeah, I see that, too. But I also see it as yet another nail in
> the VMS coffin as more and more people decide moving forward is
> not really worth their effort.
>
> Question Dave. If VSI had decided not to port or continue support
> for VMS BASIC would you have ported to another language or OS in
> order to keep your customers running? Would you see taking on such
> a task as your responsibility?

That would raise several questions. But to first answer your question, who else
would or could port the apps to another environment? It would be the software
owner's responsibility.

As to whether is would be advisable to port to another language and environment,
it would depend on the economics of the question. Would the customers be
willing to finance the work? Would the vendor be able to perform the work? I
may have mentioned before, Erik: 80, Dave: 76, Bill: 72, ...

However the last bit is rather specific, and the general question isn't. It is
a needs and economic issue. Can something else do the job? Does the job need
to be done?

You like to refer to nails and coffins. VSI is providing the means to continue
to use VMS. That's all they can do. What others do is their own business, and
could affect the viability of VSI.

I have to wonder if the general entitlement mentality that seems to be so
widespread isn't happening with such issues as raised by the OP. Back in the
day, if one needed something, one found or produced it. When a software vendor
noticed a business opportunity they sought to pursue that opportunity. Seems
now some want everything handed to them. Seems some software vendors want
customers to use what they offer, not to produce what the customer asks for.

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

On 2022-10-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> Question Dave. If VSI had decided not to port or continue support
> for VMS BASIC would you have ported to another language or OS in
> order to keep your customers running? Would you see taking on such
> a task as your responsibility?
>

David also has a problem in that he has his own in-house database
written in Macro-32.

If he had decided to instead run his applications under an Alpha emulator,
he still has the problem of responding to external factors such as new
variants of communications protocols and other issues such as handling new
security vulnerabilities (that latter one would be important as far as
auditors are concerned).

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-10-12, Dave Froble <davef@tsoft-inc.com> wrote:
>
> I have to wonder if the general entitlement mentality that seems to be so
> widespread isn't happening with such issues as raised by the OP. Back in the
> day, if one needed something, one found or produced it. When a software vendor
> noticed a business opportunity they sought to pursue that opportunity. Seems
> now some want everything handed to them. Seems some software vendors want
> customers to use what they offer, not to produce what the customer asks for.
>

Nothing to do with entitlement in this case, but with the expectations
of customer management (amongst others).

In a world of standard solutions, and with lots of people available to
operate/program those solutions, anything to do with VMS needs to be
as friction-free as possible (including moving to another architecture),
or, in the eyes of those customer managers, VMS becomes something that
needs to be replaced with a standard solution that the management can
easily find new employees for as required.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 10/12/22 13:30, Simon Clubley wrote:
> On 2022-10-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 10/12/22 09:05, Simon Clubley wrote:
>>>
>>>
>>> Unfortunately, when architectures are changed not all packages make it
>>> across to the new architecture.
>>
>> And the result is the loss of even more customers. How many can VMS
>> afford to loose?
>
> None. VSI are marketing to existing users, which is a fixed-size market.
>
> There's no way that a completely new customer who has never seen VMS before
> will move to VMS for the first time in 2022/2023.
>
>>>
>>> For example, VAXELN was abandoned when the move to Alpha occurred and
>>> it looks like there will be no Ada compiler for x86-64 VMS.
>>
>> That's just silly. VAXELN was tied to the VAX architecture it would
>> have been abandoned no matter what architecture VMS moved to.
>>
>
> Exactly. It's a perfect example of something that would be left behind.
>
> Compilers are another good example. Because of the changes required to
> compilers to move to another architecture, that's another language that
> might not be available on the new architecture and hence a set of users
> with their own applications written in that language which are left
> without any viable path to move to the new architecture.
>
>>>
>>> The question is, just how major are the packages that are being lost ?
>>
>> How major they are is dependent on the user, none of them are really
>> major to VSI.
>>
>
> They are if it stops a noticable number of sites from moving to x86-64 VMS.
>
>>> Oracle Classic is a major example of something that has been lost, but
>>> that's tied to VMS in general, not just x86-64 VMS.
>>>
>>> There's been no negative comments about Rdb recently, so I assume that
>>> is still on course for release on x86-64 VMS. Of course, if Rdb wasn't
>>> released for x86-64 VMS then that would be a very serious blow to VSI's
>>> plans.
>>
>> A database is the least serious of these problems. VSI could easily
>> (well, maybe not easily) decide that Postgres was going to be the VMS
>> database just like RDB was, at one time, a DEC product. It is easily
>> a suitable replacement for either Oracle or RDB. Just suffers from NIH
>> syndrome.
>>
>
> So you think you can replace RDB with Postgres just like that in an
> application ?
No, not "just like that". But at least an alternative could exist
and not with someone with no interest in VMS controlling the strings.

>
> VSI have done some work here IIRC, but that's still going to be one hell
> of a compatibility layer to avoid having to rewrite existing programs and
> alter existing database operational procedures.

Using a compatibility layer and trying to make PostGres look like
RDB (or Oracle) would be a major mistake. Better to bite the bullet
and move into the current century. I have never used RDB (I have
used Oracle) but I assume it supports EXEC SQL and the usual SQL
syntax. If so, moving could be fairly easy. If not, could be a
problem. Of course, probably also depends on the language being used.
But, long term, it's a better idea than the status quo.

>
> If they have to rewrite their applications using Postgres, then that's
> another chunk of users that may just decide to run the Postgres application
> on Linux instead.

If they have to rely on the whims of someone with no real interest
in VMS to maintain their future, that's not so good either.

>
>>>
>>> So the question is, of the other packages Marc uses, how many of them
>>> are in general use within the VMS user base as a whole ?
>>
>> Doesn't really matter if the loss of these means they can't or won't
>> move forward on VMS.
>>
>
> Exactly.
>
> Simon.
>

bill

On 10/12/2022 5:03 AM, Marc Van Dyck wrote:
> on 11/10/2022, Arne Vajhøj supposed :
>> On 10/11/2022 11:27 AM, Dave Froble wrote:
>>> On 10/11/2022 9:00 AM, Simon Clubley wrote:
>>>> On 2022-10-11, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> wrote:
>>>>> The lack of attention to third party software editors is in my opinion
>>>>> even worse than that.
>>>> If so, I am surprised at that. I thought VSI were in communication with
>>>> the various third-party software developers. Are you saying that is not
>>>> happening ?
>>>
>>> Not sure what Marc is looking for.  I've gotten ISV stuff from VSI.
>>> No problem.  However if Marc is looking for VSI to get involved in
>>> any way with marketing and sales of 3rd party software, I'm thinking
>>> VSI is fully tasked with their own issues.  Can't do everything.
>>
>> I agree.
>>
>> VSI got a good ISV program.
>>
>> I have no reason to doubt that VSI is working with major
>> third party software vendors.
>>
>> Oracle DB (Oracle Classic) client kit was obviously a
>> disappointment, but VSI can't force Oracle to do anything.
>>
>> VSI does not have resources to offer engineering
>> support to the smaller third party software vendors.
>>
>> Given the industry landscape and VSI's size, then I think
>> they are doing what they can.
>
> Most of the software packages that we are using today won't be ported
> to X86. That includes, but is not limited to, Oracle Classic client,
> the old Polycenter products (now owned by Broadcom), the $Universe
> multi-platform scheduler, Axway Transfer CFT, etc. We're going to have
> to find replacements for all that, and review all our home grown apps
> to use them. So for us, no the VSI ISV program is not particularly good.
> And I do not see any reason why we should consider ourselves as an
> exception.

What you describe is definitely not good.

Software is necessary for an OS.

If software does not get ported from VMS Alpha and VMS I64 to
VMS x86-64, then VSI has a problem.

But the question is *why* are they not porting.

Is it cost and service provided of VSI ISV program? (that seems very
unlikely to me)

Is it lack of awareness of VMS x86-64 or lack of faith in the
future of VMS? VSI could do something about that.

Is it too few VMS customers to pay for the port? Very little
to do about that short term.

Is it corporate decisions to drop anything that is not Linux
or Windows? Probably also very little to do about that - the
world is as the world is.

Arne

PS: New ISV's considering to port to VMS (let us be optimizstic!) have
a few additional concerns like supported language versions and
libraries available, but those should not impact those
already on VMS.

On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
> On 10/12/22 13:30, Simon Clubley wrote:
>> On 2022-10-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> On 10/12/22 09:05, Simon Clubley wrote:
>>>> There's been no negative comments about Rdb recently, so I assume that
>>>> is still on course for release on x86-64 VMS. Of course, if Rdb wasn't
>>>> released for x86-64 VMS then that would be a very serious blow to VSI's
>>>> plans.
>>>
>>> A database is the least serious of these problems.  VSI could easily
>>> (well, maybe  not easily) decide that Postgres was going to be the VMS
>>> database just like RDB was, at one time, a DEC product.  It is easily
>>> a suitable replacement for either Oracle or RDB.  Just suffers from NIH
>>> syndrome.
>>
>> So you think you can replace RDB with Postgres just like that in an
>> application ?
> No, not "just like that".  But at least an alternative could exist
> and not with someone with no interest in VMS controlling the strings.
>
>> VSI have done some work here IIRC, but that's still going to be one hell
>> of a compatibility layer to avoid having to rewrite existing programs and
>> alter existing database operational procedures.
>
> Using a compatibility layer and trying to make PostGres look like
> RDB (or Oracle) would be a major mistake. Better to bite the bullet
> and move into the current century.

It is a tradeoff.

There are benefits from doing things the standard way instead of
doing it the compatibility way.

But there are also huge cost of changing the client applications.

>   I have never used RDB (I have
> used Oracle) but I assume it supports EXEC SQL and the usual SQL
> syntax.  If so, moving could be fairly easy.  If not, could be a
> problem.  Of course, probably also depends on the language being used.

It will indeed depend on the language and the API used.

embedded SQL/C => relative easy (PgSQL has precompiler)

embedded SQL/Cobol => maybe easy (an open source precompiler supposedly
exist and work)

embedded SQL/Pascal, Fortran ... => major rewrite (precompilers are not
available)

modules/any language => major rewrite (concept not available)

SQL Services/C => major rewrite (API not available)

JDBC/Java, ... => easy

JPA/Java, ... => easy

DB API 2.0/Python => easy

On top of that problem there is always the risk of non-standard
SQL (stored procedures are notoriously problematic to port).

Arne

On 10/12/2022 1:17 PM, Simon Clubley wrote:
> On 2022-10-12, Dave Froble <davef@tsoft-inc.com> wrote:
>> It would seem to me that the current owners of the mentioned software would be
>> responsible for porting their software, not VSI.
>
> That's a very, very, short-sighted view David.
>
> Operating systems exist to run applications. Without those applications,
> the operating system means nothing.

True.

> DEC understood this, which is why you used to have the old Software handbooks.

If the missing piece of the puzzle is just that then VSI could
easily create the web based equivalent.

> It is very strongly in VSI's interest to help vendors port their applications
> to x86-64 VMS.
>
> Unfortunately, VSI's limited resources means they can't help as many
> people as it would be beneficial to help.

They can't. And they probably shouldn't. And other vendors don't.

Arne

On 10/12/2022 10:27 AM, Bill Gunshannon wrote:
> On 10/12/22 09:05, Simon Clubley wrote:
>> There's been no negative comments about Rdb recently, so I assume that
>> is still on course for release on x86-64 VMS. Of course, if Rdb wasn't
>> released for x86-64 VMS then that would be a very serious blow to VSI's
>> plans.
>
> A database is the least serious of these problems.  VSI could easily
> (well, maybe  not easily) decide that Postgres was going to be the VMS
> database just like RDB was, at one time, a DEC product.  It is easily
> a suitable replacement for either Oracle or RDB.  Just suffers from NIH
> syndrome.

Databases are usually one of the most expensive pieces to
change.

Unless the client applications has been written specifically to
not be tied a specific database, then there are client application
changes.

There is the data conversion.

There is the OPS & DBA procedures and training.

And everything need to be tested.

Arne

On 10/12/2022 5:33 PM, Arne Vajhøj wrote:
> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>> Using a compatibility layer and trying to make PostGres look like
>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>> and move into the current century.
>
> It is a tradeoff.
>
> There are benefits from doing things the standard way instead of
> doing it the compatibility way.
>
> But there are also huge cost of changing the client applications.
>
>>                                  I have never used RDB (I have
>> used Oracle) but I assume it supports EXEC SQL and the usual SQL
>> syntax.  If so, moving could be fairly easy.  If not, could be a
>> problem.  Of course, probably also depends on the language being used.
>
> It will indeed depend on the language and the API used.
>
> embedded SQL/C => relative easy (PgSQL has precompiler)
>
> embedded SQL/Cobol => maybe easy (an open source precompiler supposedly
> exist and work)
>
> embedded SQL/Pascal, Fortran ... => major rewrite (precompilers are not
> available)

Also note that moving to the current century implies
moving from embedded SQL even if a precompiler is available.

Embedded SQL is a 80's & 90's technology.

Not what would be chosen if starting from scratch today.

Arne

Den 2022-10-12 kl. 23:43, skrev Arne Vajhøj:
> On 10/12/2022 5:33 PM, Arne Vajhøj wrote:
>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>> Using a compatibility layer and trying to make PostGres look like
>>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>>> and move into the current century.
>>
>> It is a tradeoff.
>>
>> There are benefits from doing things the standard way instead of
>> doing it the compatibility way.
>>
>> But there are also huge cost of changing the client applications.
>>
>>>                                  I have never used RDB (I have
>>> used Oracle) but I assume it supports EXEC SQL and the usual SQL
>>> syntax.  If so, moving could be fairly easy.  If not, could be a
>>> problem.  Of course, probably also depends on the language being used.
>>
>> It will indeed depend on the language and the API used.
>>
>> embedded SQL/C => relative easy (PgSQL has precompiler)
>>
>> embedded SQL/Cobol => maybe easy (an open source precompiler supposedly
>> exist and work)
>>
>> embedded SQL/Pascal, Fortran ... => major rewrite (precompilers are not
>> available)
>
> Also note that moving to the current century implies
> moving from embedded SQL...

To what?

> even if a precompiler is available.
>
> Embedded SQL is a 80's & 90's technology.
>
> Not what would be chosen if starting from scratch today.
>
> Arne
>
>

On 10/12/2022 5:45 PM, Jan-Erik Söderholm wrote:
> Den 2022-10-12 kl. 23:43, skrev Arne Vajhøj:
>> On 10/12/2022 5:33 PM, Arne Vajhøj wrote:
>>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>>> Using a compatibility layer and trying to make PostGres look like
>>>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>>>> and move into the current century.
>>>
>>> It is a tradeoff.
>>>
>>> There are benefits from doing things the standard way instead of
>>> doing it the compatibility way.
>>>
>>> But there are also huge cost of changing the client applications.
>>>
>>>>                                  I have never used RDB (I have
>>>> used Oracle) but I assume it supports EXEC SQL and the usual SQL
>>>> syntax.  If so, moving could be fairly easy.  If not, could be a
>>>> problem.  Of course, probably also depends on the language being used.
>>>
>>> It will indeed depend on the language and the API used.
>>>
>>> embedded SQL/C => relative easy (PgSQL has precompiler)
>>>
>>> embedded SQL/Cobol => maybe easy (an open source precompiler
>>> supposedly exist and work)
>>>
>>> embedded SQL/Pascal, Fortran ... => major rewrite (precompilers are
>>> not available)
>>
>> Also note that moving to the current century implies
>> moving from embedded SQL...
>
> To what?

ORM
standard API (like ODBC, JDBC, DB API 2.0 etc.)
database specific API (for PGSQL that means libpq*)

*) libpq is already ported to VMS - https://vmssoftware.com/products/libpq/

Arne

On 10/12/2022 5:50 PM, Arne Vajhøj wrote:
> On 10/12/2022 5:45 PM, Jan-Erik Söderholm wrote:
>> Den 2022-10-12 kl. 23:43, skrev Arne Vajhøj:
>>> On 10/12/2022 5:33 PM, Arne Vajhøj wrote:
>>>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>>>> Using a compatibility layer and trying to make PostGres look like
>>>>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>>>>> and move into the current century.
>>>>
>>>> It is a tradeoff.
>>>>
>>>> There are benefits from doing things the standard way instead of
>>>> doing it the compatibility way.
>>>>
>>>> But there are also huge cost of changing the client applications.
>>>>
>>>>>                                  I have never used RDB (I have
>>>>> used Oracle) but I assume it supports EXEC SQL and the usual SQL
>>>>> syntax.  If so, moving could be fairly easy.  If not, could be a
>>>>> problem.  Of course, probably also depends on the language being used.
>>>>
>>>> It will indeed depend on the language and the API used.
>>>>
>>>> embedded SQL/C => relative easy (PgSQL has precompiler)
>>>>
>>>> embedded SQL/Cobol => maybe easy (an open source precompiler
>>>> supposedly exist and work)
>>>>
>>>> embedded SQL/Pascal, Fortran ... => major rewrite (precompilers are
>>>> not available)
>>>
>>> Also note that moving to the current century implies
>>> moving from embedded SQL...
>>
>> To what?
>
> ORM
> standard API (like ODBC, JDBC, DB API 2.0 etc.)
> database specific API (for PGSQL that means libpq*)
>
> *) libpq is already ported to VMS - https://vmssoftware.com/products/libpq/

One obvious caveat: some languages are not well supported by these.

Arne

Den 2022-10-12 kl. 23:50, skrev Arne Vajhøj:
> On 10/12/2022 5:45 PM, Jan-Erik Söderholm wrote:
>> Den 2022-10-12 kl. 23:43, skrev Arne Vajhøj:
>>> On 10/12/2022 5:33 PM, Arne Vajhøj wrote:
>>>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>>>> Using a compatibility layer and trying to make PostGres look like
>>>>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>>>>> and move into the current century.
>>>>
>>>> It is a tradeoff.
>>>>
>>>> There are benefits from doing things the standard way instead of
>>>> doing it the compatibility way.
>>>>
>>>> But there are also huge cost of changing the client applications.
>>>>
>>>>>                                  I have never used RDB (I have
>>>>> used Oracle) but I assume it supports EXEC SQL and the usual SQL
>>>>> syntax.  If so, moving could be fairly easy.  If not, could be a
>>>>> problem.  Of course, probably also depends on the language being used.
>>>>
>>>> It will indeed depend on the language and the API used.
>>>>
>>>> embedded SQL/C => relative easy (PgSQL has precompiler)
>>>>
>>>> embedded SQL/Cobol => maybe easy (an open source precompiler supposedly
>>>> exist and work)
>>>>
>>>> embedded SQL/Pascal, Fortran ... => major rewrite (precompilers are not
>>>> available)
>>>
>>> Also note that moving to the current century implies
>>> moving from embedded SQL...
>>
>> To what?
>
> ORM
> standard API (like ODBC, JDBC, DB API 2.0 etc.)
> database specific API (for PGSQL that means libpq*)
>
> *) libpq is already ported to VMS - https://vmssoftware.com/products/libpq/
>
> Arne
>

OK. That works when you have a central database engine/server to
send the request to. There is no such database engine/server in Rdb.

All database "work" is done within the user process. Well, apart from
some management routines, automatic backups and such. But all normal
data manipulations are done in each user process.

So there are no IPC or network latencys to concider.
DLM coordinate accesses/locks and such.

On 10/12/2022 1:48 PM, Simon Clubley wrote:
> On 2022-10-12, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> I have to wonder if the general entitlement mentality that seems to be so
>> widespread isn't happening with such issues as raised by the OP. Back in the
>> day, if one needed something, one found or produced it. When a software vendor
>> noticed a business opportunity they sought to pursue that opportunity. Seems
>> now some want everything handed to them. Seems some software vendors want
>> customers to use what they offer, not to produce what the customer asks for.
>>
>
> Nothing to do with entitlement in this case, but with the expectations
> of customer management (amongst others).
>
> In a world of standard solutions, and with lots of people available to
> operate/program those solutions, anything to do with VMS needs to be
> as friction-free as possible (including moving to another architecture),
> or, in the eyes of those customer managers, VMS becomes something that
> needs to be replaced with a standard solution that the management can
> easily find new employees for as required.

I do not worship at the alter of "standard solutions" ...

Yes, for some things, they work well. However, for most of my work in IT
solutions, I've been involved in projects where the demands of the job defined
the solution(s). All too often, that required specific solutions.

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

On 10/12/2022 6:02 PM, Jan-Erik Söderholm wrote:
> Den 2022-10-12 kl. 23:50, skrev Arne Vajhøj:
>> On 10/12/2022 5:45 PM, Jan-Erik Söderholm wrote:
>>> Den 2022-10-12 kl. 23:43, skrev Arne Vajhøj:
>>>> On 10/12/2022 5:33 PM, Arne Vajhøj wrote:
>>>>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>>>>> Using a compatibility layer and trying to make PostGres look like
>>>>>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>>>>>> and move into the current century.
>>>>>
>>>>> It is a tradeoff.
>>>>>
>>>>> There are benefits from doing things the standard way instead of
>>>>> doing it the compatibility way.
>>>>>
>>>>> But there are also huge cost of changing the client applications.
>>>>>
>>>>>>                                  I have never used RDB (I have
>>>>>> used Oracle) but I assume it supports EXEC SQL and the usual SQL
>>>>>> syntax.  If so, moving could be fairly easy.  If not, could be a
>>>>>> problem.  Of course, probably also depends on the language being
>>>>>> used.
>>>>>
>>>>> It will indeed depend on the language and the API used.
>>>>>
>>>>> embedded SQL/C => relative easy (PgSQL has precompiler)
>>>>>
>>>>> embedded SQL/Cobol => maybe easy (an open source precompiler
>>>>> supposedly exist and work)
>>>>>
>>>>> embedded SQL/Pascal, Fortran ... => major rewrite (precompilers are
>>>>> not available)
>>>>
>>>> Also note that moving to the current century implies
>>>> moving from embedded SQL...
>>>
>>> To what?
>>
>> ORM
>> standard API (like ODBC, JDBC, DB API 2.0 etc.)
>> database specific API (for PGSQL that means libpq*)
>>
>> *) libpq is already ported to VMS -
>> https://vmssoftware.com/products/libpq/
>>
>> Arne
>
> OK. That works when you have a central database engine/server to
> send the request to. There is no such database engine/server in Rdb.
>
> All database "work" is done within the user process. Well, apart from
> some management routines, automatic backups and such. But all normal
> data manipulations are done in each user process.
>
> So there are no IPC or network latencys to concider.
> DLM coordinate accesses/locks and such.

The database access API and "network database" vs Rdb
"semi-embedded database" are really independent.

VMS Cobol embedded SQL to Rdb use "semi-embedded database" approach.

VMS Cobol embedded SQL to Oracle Classic use "network database" approach.

Java native JDBC driver to Rdb use "semi-embedded database" approach.

Java thin JDBC driver to Rdb use "network database" approach.

Arne

On 10/12/22 17:33, Arne Vajhøj wrote:
> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>> On 10/12/22 13:30, Simon Clubley wrote:
>>> On 2022-10-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>> On 10/12/22 09:05, Simon Clubley wrote:
>>>>> There's been no negative comments about Rdb recently, so I assume that
>>>>> is still on course for release on x86-64 VMS. Of course, if Rdb wasn't
>>>>> released for x86-64 VMS then that would be a very serious blow to
>>>>> VSI's
>>>>> plans.
>>>>
>>>> A database is the least serious of these problems.  VSI could easily
>>>> (well, maybe  not easily) decide that Postgres was going to be the VMS
>>>> database just like RDB was, at one time, a DEC product.  It is easily
>>>> a suitable replacement for either Oracle or RDB.  Just suffers from NIH
>>>> syndrome.
>>>
>>> So you think you can replace RDB with Postgres just like that in an
>>> application ?
>> No, not "just like that".  But at least an alternative could exist
>> and not with someone with no interest in VMS controlling the strings.
>>
>>> VSI have done some work here IIRC, but that's still going to be one hell
>>> of a compatibility layer to avoid having to rewrite existing programs
>>> and
>>> alter existing database operational procedures.
>>
>> Using a compatibility layer and trying to make PostGres look like
>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>> and move into the current century.
>
> It is a tradeoff.
>
> There are benefits from doing things the standard way instead of
> doing it the compatibility way.
>
> But there are also huge cost of changing the client applications.

Maybe and maybe not as much as you think. Granted, most of my
experience doing it has been with COBOL but I have been able to
take programs using databases from other systems and moved them
quite easily. I would love to have someone send me a COBOL
program that uses RDB just for a look-see.

>
>>                                  I have never used RDB (I have
>> used Oracle) but I assume it supports EXEC SQL and the usual SQL
>> syntax.  If so, moving could be fairly easy.  If not, could be a
>> problem.  Of course, probably also depends on the language being used.
>
> It will indeed depend on the language and the API used.
>
> embedded SQL/C => relative easy (PgSQL has precompiler)
>
> embedded SQL/Cobol => maybe easy (an open source precompiler supposedly
> exist and work)
>
> embedded SQL/Pascal, Fortran ... => major rewrite (precompilers are not
> available)

Yes, but I would imagine given the two existing pre-compilers coming
up with one for Pascal and Fortran would not be all that difficult.
Of course, I would wonder how many people there are still using Pascal
and Fortran for database applications. :-)

>
> modules/any language => major rewrite (concept not available)
>
> SQL Services/C => major rewrite (API not available)
>
> JDBC/Java, ... => easy
>
> JPA/Java, ... => easy
>
> DB API 2.0/Python => easy
>
> On top of that problem there is always the risk of non-standard
> SQL (stored procedures are notoriously problematic to port).

bill

On 10/12/22 17:43, Arne Vajhøj wrote:
> On 10/12/2022 5:33 PM, Arne Vajhøj wrote:
>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>> Using a compatibility layer and trying to make PostGres look like
>>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>>> and move into the current century.
>>
>> It is a tradeoff.
>>
>> There are benefits from doing things the standard way instead of
>> doing it the compatibility way.
>>
>> But there are also huge cost of changing the client applications.
>>
>>>                                  I have never used RDB (I have
>>> used Oracle) but I assume it supports EXEC SQL and the usual SQL
>>> syntax.  If so, moving could be fairly easy.  If not, could be a
>>> problem.  Of course, probably also depends on the language being used.
>>
>> It will indeed depend on the language and the API used.
>>
>> embedded SQL/C => relative easy (PgSQL has precompiler)
>>
>> embedded SQL/Cobol => maybe easy (an open source precompiler
>> supposedly exist and work)
>>
>> embedded SQL/Pascal, Fortran ... => major rewrite (precompilers are
>> not available)
>
> Also note that moving to the current century implies
> moving from embedded SQL even if a precompiler is available.
>
> Embedded SQL is a 80's & 90's technology.
>
> Not what would be chosen if starting from scratch today.

Don't know why not. Most of the COBOL/Oracle sites I am aware of
are all EXEC SQL embedded programming.

bill

On 10/12/2022 6:59 PM, Bill Gunshannon wrote:
> On 10/12/22 17:43, Arne Vajhøj wrote:
>> Also note that moving to the current century implies
>> moving from embedded SQL even if a precompiler is available.
>>
>> Embedded SQL is a 80's & 90's technology.
>>
>> Not what would be chosen if starting from scratch today.
>
> Don't know why not.  Most of the COBOL/Oracle sites I am aware of
> are all EXEC SQL embedded programming.

How many of those code bases was *started* this century?

Arne

On 10/12/2022 6:58 PM, Bill Gunshannon wrote:
> On 10/12/22 17:33, Arne Vajhøj wrote:
>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>> Using a compatibility layer and trying to make PostGres look like
>>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>>> and move into the current century.
>>
>> It is a tradeoff.
>>
>> There are benefits from doing things the standard way instead of
>> doing it the compatibility way.
>>
>> But there are also huge cost of changing the client applications.
>
> Maybe and maybe not as much as you think.  Granted, most of my
> experience doing it has been with COBOL but I have been able to
> take programs using databases from other systems and moved them
> quite easily.  I would  love to have someone send me a COBOL
> program that uses RDB just for a look-see.

Cobol embedded SQL is probably one of the more portable. But it is
not supported by PostgreSQL project itself.

An extremely simple Cobol embedded SQL to Rdb example:
https://www.vajhoej.dk/arne/articles/vmsdb.html#rdb_cob_emb

>>>                                  I have never used RDB (I have
>>> used Oracle) but I assume it supports EXEC SQL and the usual SQL
>>> syntax.  If so, moving could be fairly easy.  If not, could be a
>>> problem.  Of course, probably also depends on the language being used.
>>
>> It will indeed depend on the language and the API used.
>>
>> embedded SQL/C => relative easy (PgSQL has precompiler)
>>
>> embedded SQL/Cobol => maybe easy (an open source precompiler
>> supposedly exist and work)
>>
>> embedded SQL/Pascal, Fortran ... => major rewrite (precompilers are
>> not available)
>
> Yes, but I would imagine given the two existing pre-compilers coming
> up with one for Pascal and Fortran would not be all that difficult.

Maybe not. But so far it has not been done.

> Of course, I would wonder how many people there are still using Pascal
> and Fortran for database applications.  :-)

VMS applications are done in many languages. I would expect some
to exist. VSI seems to expect that as well since SQLRelay come
with API examples in Fortram, Pascal and Basic (besides Cobol, C
and C++).

Arne

On 10/12/22 17:40, Arne Vajhøj wrote:
> On 10/12/2022 10:27 AM, Bill Gunshannon wrote:
>> On 10/12/22 09:05, Simon Clubley wrote:
>>> There's been no negative comments about Rdb recently, so I assume that
>>> is still on course for release on x86-64 VMS. Of course, if Rdb wasn't
>>> released for x86-64 VMS then that would be a very serious blow to VSI's
>>> plans.
>>
>> A database is the least serious of these problems.  VSI could easily
>> (well, maybe  not easily) decide that Postgres was going to be the VMS
>> database just like RDB was, at one time, a DEC product.  It is easily
>> a suitable replacement for either Oracle or RDB.  Just suffers from NIH
>> syndrome.
>
> Databases are usually one of the most expensive pieces to
> change.
>
> Unless the client applications has been written specifically to
> not be tied a specific database, then there are client application
> changes.
>
> There is the data conversion.
>
> There is the OPS & DBA procedures and training.
>
> And everything need to be tested.
>

And the alternative is to sit around and wait until someone pulls
the rug out from under your operation. How much of this do VMS
people need to see before they start planning ahead?

bill

On 10/12/2022 8:04 PM, Bill Gunshannon wrote:
> On 10/12/22 17:40, Arne Vajhøj wrote:
>> On 10/12/2022 10:27 AM, Bill Gunshannon wrote:
>>> On 10/12/22 09:05, Simon Clubley wrote:
>>>> There's been no negative comments about Rdb recently, so I assume that
>>>> is still on course for release on x86-64 VMS. Of course, if Rdb wasn't
>>>> released for x86-64 VMS then that would be a very serious blow to VSI's
>>>> plans.
>>>
>>> A database is the least serious of these problems.  VSI could easily
>>> (well, maybe  not easily) decide that Postgres was going to be the VMS
>>> database just like RDB was, at one time, a DEC product.  It is easily
>>> a suitable replacement for either Oracle or RDB.  Just suffers from NIH
>>> syndrome.
>>
>> Databases are usually one of the most expensive pieces to
>> change.
>>
>> Unless the client applications has been written specifically to
>> not be tied a specific database, then there are client application
>> changes.
>>
>> There is the data conversion.
>>
>> There is the OPS & DBA procedures and training.
>>
>> And everything need to be tested.
>
> And the alternative is to sit around and wait until someone pulls
> the rug out from under your operation.  How much of this do VMS
> people need to see before they start planning ahead?

I agree that it is generally good to plan ahead. And when something
is officially declared EOL then it is time to act.

But in the specific case then Rdb is still promised for VMS x86-64
and VMS PostgreSQL is not even released, so planning that one may be
premature.

Arne

On 10/12/22 19:22, Arne Vajhøj wrote:
> On 10/12/2022 6:58 PM, Bill Gunshannon wrote:
>> On 10/12/22 17:33, Arne Vajhøj wrote:
>>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>>> Using a compatibility layer and trying to make PostGres look like
>>>> RDB (or Oracle) would be a major mistake. Better to bite the bullet
>>>> and move into the current century.
>>>
>>> It is a tradeoff.
>>>
>>> There are benefits from doing things the standard way instead of
>>> doing it the compatibility way.
>>>
>>> But there are also huge cost of changing the client applications.
>>
>> Maybe and maybe not as much as you think.  Granted, most of my
>> experience doing it has been with COBOL but I have been able to
>> take programs using databases from other systems and moved them
>> quite easily.  I would  love to have someone send me a COBOL
>> program that uses RDB just for a look-see.
>
> Cobol embedded SQL is probably one of the more portable. But it is
> not supported by PostgreSQL project itself.

No, but this is the Open Source world. A need arose and someone
rushed in to fill it. And it works quite well.

>
> An extremely simple Cobol embedded SQL to Rdb example:
>   https://www.vajhoej.dk/arne/articles/vmsdb.html#rdb_cob_emb

I saw nothing in there that would not compile using ESQL and GnuCOBOL
with PostGres. Even the module stuff (which I am not familiar with)
could be set up to work with PostGres rather than RDB in maybe an hour.

>
>>>>                                  I have never used RDB (I have
>>>> used Oracle) but I assume it supports EXEC SQL and the usual SQL
>>>> syntax.  If so, moving could be fairly easy.  If not, could be a
>>>> problem.  Of course, probably also depends on the language being used.
>>>
>>> It will indeed depend on the language and the API used.
>>>
>>> embedded SQL/C => relative easy (PgSQL has precompiler)
>>>
>>> embedded SQL/Cobol => maybe easy (an open source precompiler
>>> supposedly exist and work)
>>>
>>> embedded SQL/Pascal, Fortran ... => major rewrite (precompilers are
>>> not available)
>>
>> Yes, but I would imagine given the two existing pre-compilers coming
>> up with one for Pascal and Fortran would not be all that difficult.
>
> Maybe not. But so far it has not been done.

Probably because there has been no need to do it yet. I have seen
no evidence that it would be needed on VMS but is any OS is still
using now obscure legacy languages it would be on VMS. :-)

>
>> Of course, I would wonder how many people there are still using Pascal
>> and Fortran for database applications.  :-)
>
> VMS applications are done in many languages. I would expect some
> to exist. VSI seems to expect that as well since SQLRelay come
> with API examples in Fortram, Pascal and Basic (besides Cobol, C
> and C++).

What, no Ada?

bill

On 10/12/22 13:36, Dave Froble wrote:
> On 10/12/2022 12:22 PM, Bill Gunshannon wrote:
>> On 10/12/22 10:03, Dave Froble wrote:
>>> On 10/12/2022 5:03 AM, Marc Van Dyck wrote:
>>>> on 11/10/2022, Arne Vajhøj supposed :
>>>>> On 10/11/2022 11:27 AM, Dave Froble wrote:
>>>>>> On 10/11/2022 9:00 AM, Simon Clubley wrote:
>>>>>>> On 2022-10-11, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be>
>>>>>>> wrote:
>>>>>>>> The lack of attention to third party software editors is in my
>>>>>>>> opinion
>>>>>>>> even worse than that.
>>>>>>> If so, I am surprised at that. I thought VSI were in
>>>>>>> communication with
>>>>>>> the various third-party software developers. Are you saying that
>>>>>>> is not
>>>>>>> happening ?
>>>>>>
>>>>>> Not sure what Marc is looking for.  I've gotten ISV stuff from
>>>>>> VSI.  No
>>>>>> problem.  However if Marc is looking for VSI to get involved in
>>>>>> any way with
>>>>>> marketing and sales of 3rd party software, I'm thinking VSI is
>>>>>> fully tasked
>>>>>> with their own issues.  Can't do everything.
>>>>>
>>>>> I agree.
>>>>>
>>>>> VSI got a good ISV program.
>>>>>
>>>>> I have no reason to doubt that VSI is working with major
>>>>> third party software vendors.
>>>>>
>>>>> Oracle DB (Oracle Classic) client kit was obviously a
>>>>> disappointment, but VSI can't force Oracle to do anything.
>>>>>
>>>>> VSI does not have resources to offer engineering
>>>>> support to the smaller third party software vendors.
>>>>>
>>>>> Given the industry landscape and VSI's size, then I think
>>>>> they are doing what they can.
>>>>>
>>>>> Arne
>>>>
>>>> Most of the software packages that we are using today won't be ported
>>>> to X86. That includes, but is not limited to, Oracle Classic client,
>>>> the old Polycenter products (now owned by Broadcom), the $Universe
>>>> multi-platform scheduler, Axway Transfer CFT, etc. We're going to have
>>>> to find replacements for all that, and review all our home grown apps
>>>> to use them. So for us, no the VSI ISV program is not particularly
>>>> good.
>>>> And I do not see any reason why we should consider ourselves as an
>>>> exception.
>>>>
>>>
>>> It would seem to me that the current owners of the mentioned software
>>> would be
>>> responsible for porting their software, not VSI.
>>
>> I don't see where they have any responsibility to port it one way or the
>> other.  Of course, neither does VSI.
>>
>>>
>>> Have you asked these entities to provide their software on x86 VMS?
>>> Selling
>>> their products and services is what they are about, isn't it?  If
>>> not, then I
>>> for one do not understand what they consider their business.  If they
>>> would
>>> desire to port their software, the ISV program would provide them
>>> with the
>>> capability.
>>
>> And if they see the cost as far too much more than the expected ROI?
>>
>>>
>>> If the owners of the mentioned software products decline to port them
>>> to x86
>>> VMS, then that perhaps is business opportunities for other vendors.
>>>
>>> I fail to understand why you might consider this a problem with the
>>> VSI ISV
>>> program.
>>>
>>
>> Yeah, I see that, too.  But I also see it as yet another nail in
>> the VMS coffin as more and more people decide moving forward is
>> not really worth their effort.
>>
>> Question Dave.  If VSI had decided not to port or continue support
>> for VMS BASIC would you have ported to another language or OS in
>> order to keep your customers running?  Would you see taking on such
>> a task as your responsibility?
>
> That would raise several questions.  But to first answer your question,
> who else would or could port the apps to another environment?  It would
> be the software owner's responsibility.

You keep saying "responsibility". But what I am saying is beyond what
current versions that have been licensed/purchased they actually have
no responsibility at all. And that was my point.

>
> As to whether is would be advisable to port to another language and
> environment, it would depend on the economics of the question.  Would
> the customers be willing to finance the work?  Would the vendor be able
> to perform the work?  I may have mentioned before, Erik: 80, Dave: 76,
> Bill: 72, ...

And the same applies to the products that we just learned are not
moving forward to x86-64 VMS.

>
> However the last bit is rather specific, and the general question
> isn't.  It is a needs and economic issue.  Can something else do the
> job?  Does the job need to be done?

Sadly, that falls on Marc's shoulders with, I imagine, very little
he can do about it.

>
> You like to refer to nails and coffins.  VSI is providing the means to
> continue to use VMS.  That's all they can do.  What others do is their
> own business, and could affect the viability of VSI.

As has been stated before (even recently in this thread) no one
buys an OS for the OS. They buy it for the applications. If the
applications disappear, how long will the OS survive?

>
> I have to wonder if the general entitlement mentality that seems to be
> so widespread isn't happening with such issues as raised by the OP.
> Back in the day, if one needed something, one found or produced it.
> When a software vendor noticed a business opportunity they sought to
> pursue that opportunity.  Seems now some want everything handed to
> them.  Seems some software vendors want customers to use what they
> offer, not to produce what the customer asks for.

Depends on which side of the fence your standing.

As a side note, although that ship has sailed and I don't see any
way back, this was a very strong argument for the days when businesses
wrote their own applications and didn't rely on people with no vested
interest in your survival.

bill

On 10/12/22 20:09, Arne Vajhøj wrote:
> On 10/12/2022 8:04 PM, Bill Gunshannon wrote:
>> On 10/12/22 17:40, Arne Vajhøj wrote:
>>> On 10/12/2022 10:27 AM, Bill Gunshannon wrote:
>>>> On 10/12/22 09:05, Simon Clubley wrote:
>>>>> There's been no negative comments about Rdb recently, so I assume that
>>>>> is still on course for release on x86-64 VMS. Of course, if Rdb wasn't
>>>>> released for x86-64 VMS then that would be a very serious blow to
>>>>> VSI's
>>>>> plans.
>>>>
>>>> A database is the least serious of these problems.  VSI could easily
>>>> (well, maybe  not easily) decide that Postgres was going to be the VMS
>>>> database just like RDB was, at one time, a DEC product.  It is easily
>>>> a suitable replacement for either Oracle or RDB.  Just suffers from NIH
>>>> syndrome.
>>>
>>> Databases are usually one of the most expensive pieces to
>>> change.
>>>
>>> Unless the client applications has been written specifically to
>>> not be tied a specific database, then there are client application
>>> changes.
>>>
>>> There is the data conversion.
>>>
>>> There is the OPS & DBA procedures and training.
>>>
>>> And everything need to be tested.
>>
>> And the alternative is to sit around and wait until someone pulls
>> the rug out from under your operation.  How much of this do VMS
>> people need to see before they start planning ahead?
>
> I agree that it is generally good to plan ahead. And when something
> is officially declared EOL then it is time to act.

EOL time may be too late, depending on the complexity of the
application.

>
> But in the specific case then Rdb is still promised for VMS x86-64
> and VMS PostgreSQL is not even released, so planning that one may be
> premature.

Thus the reason I mentioned VSI adopting it just as DEC owned RDB
for all those years. Or maybe an ISV? :-)

bill