Fujitsu support - need help - Netcobol for windows and licensed controls.

Hi all,


I have a question that so far I have been unable to solve, and either
someone here has a solution for it, or I would like to have someone
with an active maintenance contract with them to pose this question to
them.

Situation
Power COBOL V7, 3rd party OCX control, properly licensed.

When run in test machine it gets a message box appears saying "file
License.dat is not found. License Agreement can not be completed"
If we copy the ".lic" file into the same folder as the supplied
activeX .OCX then it works fine, but this is obviously ilegal to do,
as it is basically distibuiting the development license.

From what I have found so far it seems that FJ is not implementing the
functionality of IClassfactory2 interface which is the method many
ActiveX controls use to determine if the control is being distributed
from a legal copy of the software, and I have been unable to find a
way to "fix" this from within POWERCobol.

So has anyone using FJ v7 been able to use a 3rd party control that
requires a license info to be supplied to the control? if so how did
you solve the problem?

If someone can post this question to FJ directly I can supply more
details, including a demo project, slthoug this is realy not
necessary, as I just add the control to the project, no code required,
and when using the standard power/netcobol installer to a new machine
it does not work, e.g. gives the license message.


Regards

Frederico Fonseca


Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

On Sun, 11 Jun 2006 23:26:48 -0600, Jeff Campbell <n8wxs@arrl.net>
wrote:

>Frederico Fonseca wrote: 
>
>This is true because the IClassFactory2 methods are implemented by the
>windows COM library, not PowerCOBOL. The .OCX you are using invokes these
>methods, not PowerCOBOL.
>
>The .OCX you are using may not allow 'runtime' license deployment on a
>'development' licensed machine. The .OCX developer should have information
>on the licensing requirements.
IClassFactory2 IS the method used to create objects that require a
license key/string to be supplied to the said object so they can
verify they are valid. Other methods include supplying a property on
the object, or supplying a ".lic" file that is only used for runtime
validation and not development.

>
snip
>
>Jeff Campbell
>n8wxs@arrl.net
>
>----== Posted via mcse.ms - Unlimited-Unrestricted-Secure Usenet News
==----
>http://www.mcse.ms The #1 Newsgroup Service in the World! 120,000+ Ne
wsgroups
>----= East and West-Coast Server Farms - Total Privacy via Encryption =----


Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
 news:2dro829m8g8tgkuare8v02ljfj8j2cr6rk@
4ax.com...
> Hi all,
>
>
> I have a question that so far I have been unable to solve, and either
> someone here has a solution for it, or I would like to have someone
> with an active maintenance contract with them to pose this question to
> them.
>
> Situation
> Power COBOL V7, 3rd party OCX control, properly licensed.
>
> When run in test machine it gets a message box appears saying "file
> License.dat is not found. License Agreement can not be completed"
> If we copy the ".lic" file into the same folder as the supplied
> activeX .OCX then it works fine, but this is obviously ilegal to do,
> as it is basically distibuiting the development license.
>
> From what I have found so far it seems that FJ is not implementing the
> functionality of IClassfactory2 interface which is the method many
> ActiveX controls use to determine if the control is being distributed
> from a legal copy of the software, and I have been unable to find a
> way to "fix" this from within POWERCobol.
>
> So has anyone using FJ v7 been able to use a 3rd party control that
> requires a license info to be supplied to the control? if so how did
> you solve the problem?
>
> If someone can post this question to FJ directly I can supply more
> details, including a demo project, slthoug this is realy not
> necessary, as I just add the control to the project, no code required,
> and when using the standard power/netcobol installer to a new machine
> it does not work, e.g. gives the license message.
>
>
> Regards
>
> Frederico Fonseca
>
>
> Frederico Fonseca
> ema il: frederico_fonseca at syssoft-int.com

"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
 news:2f4q82t0n3vadc2epu2385uk4jfh52i2a4@
4ax.com...
> On Sun, 11 Jun 2006 23:26:48 -0600, Jeff Campbell <n8wxs@arrl.net>
> wrote:
> 

It may not be as illegal as you think. The supplier may have no problem with
you doing this. Talk to them.

 

Jeff is correct and there is nothing Fujitsu can do about your problem. It
is down to the third party supplier to provide a run time license file (or
not).
 
> IClassFactory2 IS the method used to create objects that require a
> license key/string to be supplied to the said object so they can
> verify they are valid. Other methods include supplying a property on
> the object, or supplying a ".lic" file that is only used for runtime
> validation and not development.

No, it is only a CONVENTION and nobody writing COM controls HAS to implement
that interface (I don't). I would contact the supplier and explain the
problem. If they require validation through that interface, they should
provide a method which implements it. If they don't, then it is fair to ask
them how the component is to be validated at run time.

They may require you to do it directly using the COM library. Whichever way
you look at it, it is hardly a Fujitsu problem.

PowerCOBOL is simply a container just like any other COM container. If you
placed this component on a server side page, would you complain to Microsoft
because ASP was unable to instantiate it? :-)

Fujitsu cannot possibly know how every third party supplier is going to
require run time validation.(If they require it at all...)

(In my experience many suppliers don't require it, and there is nothing to
stop anyone re-usng their component once it is registered on a client
system. (Of course, the majority of clients are not developers and probably
don't have an Object Browser readily available to find out the methods and
properties...). Also, most clients would not even be aware the component was
there once they had installed the application.)

I honestly believe your best option here is to communicate with the
supplier.

Pete.

Frederico Fonseca wrote:
> Hi all,
>
>
> I have a question that so far I have been unable to solve, and either
> someone here has a solution for it, or I would like to have someone
> with an active maintenance contract with them to pose this question to
> them.

=====
Wouldn't do any good. Eleven days ago I submitted a bug report. Just today I
received:

"Hello Jerry,

"Our technical support team has reveiwed the support incident that you
submited and have come to the decision that since the problem does not
happen in V8, we will not be able to offer you a resolution to your problem
with the V6.1.

"Since your credit card has already been charged, our accouting department
will be issuing a refund to your credit card in the next day or so.

"Regards,..."

On Mon, 12 Jun 2006 17:36:50 -0500, "HeyBub" <heybubNOSPAM@gmail.com>
wrote:

>Frederico Fonseca wrote: 
>
>=====
>Wouldn't do any good. Eleven days ago I submitted a bug report. Just today 
I
>received:
>
>"Hello Jerry,
>
>"Our technical support team has reveiwed the support incident that you
>submited and have come to the decision that since the problem does not
>happen in V8, we will not be able to offer you a resolution to your problem
>with the V6.1.
>
>"Since your credit card has already been charged, our accouting department
>will be issuing a refund to your credit card in the next day or so.
>
>"Regards,..."
>

Not surprising.
I had my share of problems with them and thats why I did not renew my
maintenance last December.




Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

On Mon, 12 Jun 2006 22:04:14 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>
>"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
> news:2f4q82t0n3vadc2epu2385uk4jfh52i2a4@
4ax.com... 
>
>It may not be as illegal as you think. The supplier may have no problem wit
h
>you doing this. Talk to them.
I read the license they supply, then I spoke with them, then several
emails were exchanged with them regarding the technicalities, and ONLY
after all other venues were exhausted I did post in CLC asking for
help.

>
> 
>
>Jeff is correct and there is nothing Fujitsu can do about your problem. It
>is down to the third party supplier to provide a run time license file (or
>not).
> 
Incorrect for both Jeff and Pete.

IClassFactory is implemented within COM that part is correct, but it
is up to the container to allow for the available licensing controls
in order to allow controls to be added to it. Although the ActiveX
control does not NEED to use the IClassFactory it does need to
implement it (at least in C++). It is up to the container to see if it
is implemented and if required by the control then he (the container)
should use it.


 
>
>No, it is only a CONVENTION and nobody writing COM controls HAS to implemen
t
>that interface (I don't). I would contact the supplier and explain the
>problem. If they require validation through that interface, they should
>provide a method which implements it. If they don't, then it is fair to ask
>them how the component is to be validated at run time.
>
>They may require you to do it directly using the COM library. Whichever way
>you look at it, it is hardly a Fujitsu problem.
>
>PowerCOBOL is simply a container just like any other COM container. If you
>placed this component on a server side page, would you complain to Microsof
t
>because ASP was unable to instantiate it? :-)
I didn't, but others did. And note that a component is not the same
thing as an ActiveX Control.

>
>Fujitsu cannot possibly know how every third party supplier is going to
>require run time validation.(If they require it at all...)
as I said this validation is a subset of the IClassFactory (which FJ
DOES implement), and it is a subset used to validate licensing. Once
it is implemented correctly by any container, it will work with ALL
third party controls used within that container.

>
>(In my experience many suppliers don't require it, and there is nothing to
>stop anyone re-usng their component once it is registered on a client
>system. (Of course, the majority of clients are not developers and probably
>don't have an Object Browser readily available to find out the methods and
>properties...). Also, most clients would not even be aware the component wa
s
>there once they had installed the application.)
My experience (although not with FJ COBOL) is MANY suppliers do
require a runtime license, and most of them do implement it using only
the mentioned class. The fact that most "clients" do not notice that
they have available a illegal license of a piece of software will not
prevent BSA (or whatever similar legal entities available on your
country) from processing your company should it be found in 100 of
your computers, as supplying the ".lic" without proper authorization
would amount to piracy.

>
>I honestly believe your best option here is to communicate with the
>supplier.
>
>Pete.
>
Not really. Best option would be for FJ to have this implemented
(which it seems they have not), and the second one would be for
someone that has gone through this problem to post the solution here
or by private email.
Note that I may now have found a solution but will not be testing this
until tomorrow (1 AM now, bed time).

If I am correct I will be happy to share the solution with anyone that
needs it.

And for clarification , V8 also has the same problem (just tried it).


Regards

Frederico Fonseca


Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Exchange lots of mouse moves and clicks for a single key press!
Significantly improve working speed by using shortcuts (hot keys).
Avoid Repetitive Strain Injury!

EnergyKey   http://www30.webSamba.com/SmartStudio

"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
 news:vdur82t3r9nph697p9niom5s5qui350320@
4ax.com...
> On Mon, 12 Jun 2006 17:36:50 -0500, "HeyBub" <heybubNOSPAM@gmail.com>
> wrote: 
problem 
...
> Not surprising.
> I had my share of problems with them and thats why I did not renew my
> maintenance last December.

Sheesh, if it's a known bug in that version,  isn't the 'resolution'
simply, "that is a known error in v6.1. It is fixed in v8. The workaround is
<whatever it is, even if the workaround is "no workaround">.  ????. Why the
'review' and 'decision?'

"We're not even going to look at it because it's not the current version" is
not a resolution, unless that version has been explicity de-supported.
(Which may be the case here, I just don't know. But if that is that case,
seems to me the polite and professional response should be simply "we are
unable to review your problem because this version was desupported as of
month, year").

Support is probably the the principal reason I upgrade my development
software at all.  I usually don't need the new features and by the time the
upgrades are available I've found workarounds for any bugs (which,
fortunately, are very rare)......

..But I've found 'tech support' from any vendor for any product with a
version other than the version released last w is uniformly crummy and
the so-called "answer" is always "upgrade."

MCM

On Tue, 13 Jun 2006 12:39:09 GMT, "Michael Mattias"
<michael.mattias@gte.net> wrote:

>"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
> news:vdur82t3r9nph697p9niom5s5qui350320@
4ax.com... 
>problem 
>... 
>
>Sheesh, if it's a known bug in that version,  isn't the 'resolution'
>simply, "that is a known error in v6.1. It is fixed in v8. The workaround i
s
><whatever it is, even if the workaround is "no workaround">.  ????. Why the
>'review' and 'decision?'
>
>"We're not even going to look at it because it's not the current version" i
s
>not a resolution, unless that version has been explicity de-supported.
>(Which may be the case here, I just don't know. But if that is that case,
>seems to me the polite and professional response should be simply "we are
>unable to review your problem because this version was desupported as of
>month, year").
>
>Support is probably the the principal reason I upgrade my development
>software at all.  I usually don't need the new features and by the time the
>upgrades are available I've found workarounds for any bugs (which,
>fortunately, are very rare)......
>
>..But I've found 'tech support' from any vendor for any product with a
>version other than the version released last w is uniformly crummy and
>the so-called "answer" is always "upgrade."
>
>MCM
Hum.

With FJ the same attitude applies to the supported version also.
Long before V8 was out I had a problem with their OWN SUPPLIED method
of accessing Excel.

Their attitude was "it works fine with me so its your problem". No
sugestion of how to solve a problem, no supply of a new control with
some type of logging that would enable them to see where the problem
was.

It got to a point where I refused to speak with one particular member
of their support team, as his attitude would always be like this, even
when I proved him wrong several times.


Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com