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

Author

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

Frederico Fonseca

2006-06-17, 7:55 am

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

2006-06-17, 7:55 am

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 Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
>http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
>----= East and West-Coast Server Farms - Total Privacy via Encryption =----

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

Pete Dashwood

2006-06-17, 7:55 am

"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

Pete Dashwood

2006-06-17, 7:55 am

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

[color=darkred]

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).
[color=darkred]
> 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.

HeyBub

2006-06-17, 7:55 am

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,..."

Frederico Fonseca

2006-06-17, 7:55 am

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

Frederico Fonseca

2006-06-17, 7:55 am

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

[color=darkred]
>
>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? :-)
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 was
>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

Hello2006go@126.com

2006-06-17, 7:55 am

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

Michael Mattias

2006-06-17, 7:55 am

"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[color=darkred]
....[color=darkred]
> 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

Frederico Fonseca

2006-06-17, 7:55 am

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

Frederico Fonseca

2006-06-17, 7:55 am

On Tue, 13 Jun 2006 13:15:53 -0600, Jeff Campbell <n8wxs@arrl.net>
wrote:

>Frederico Fonseca wrote:
>
>The file names are different. Isn't that relevant? How does the "license.dat"
>file get created? (And what does it contain?) The ".lic" file appears to be the
>development license key, while the "License.dat" file seems to be the deployment
>license key. Correct? My assumption would be that the install script for your
>application must copy or create the "License.dat" file, at installation time,
>in the same directory as the newly installed copy of the .OCX file.
Incorrect. The message I mentioned here was just an example. On this
particular control it open a message window with a "thanks for trying
our software" and with a timer (incremental). What happens when a
control is found unlincensed is up to the control designer. Some do
pretty things others just return with "not licensed".

Sorry if I wasnt more clear on this, but did not consider this to be
an important aspect of this problem.

>
>
>I was incorrect above. IClassFactory and IClassFactory2 are *interfaces*
>defined by COM. Their *implementations* are coded in the class object, ie,
>your ActiveX component, not the COM library. The COM library will call the
>implemented code when an instance of the ActiveX object is created at runtime.
IClassFactory and IClassFactory2 are classes implemented by the
ActiveX controls. Inherited from COM for sure, but still locally
implemented. See below.
>
>
>Not possible. I might use a trapdoor algorithm to compute a license key,
>while another developer might use one or more registry values to store a
>precomputed license key. Another developer might use a file 8-) to store
>the key. The control's IClassFactory2 code would have to be implementation
>unique to handle these and any other possible license methods. No two
>controls will necessarily do it the *same* way.
You still do not understand how the IClassFactory2 works. I will try
to explain this to you.

IClassFactory2 is an extension of IClassFactory.
This extension enables a class factory executing on a licensed machine
to provide a license key that can be used later to create an object
instance on an unlicensed machine. Such considerations are important
for objects like controls that are used to build applications on a
licensed machine. Subsequently, the application built must be able to
run on an unlicensed machine. The license key gives only that one
client application the right to instantiate objects through
IClassFactory2 when a full machine license does not exist.

They have the following methods.
IClassFactory
CreateInstance
Creates an uninitialized object.
LockServer
Locks object application open in memory.

IClassFactory2
GetLicInfo -
Fills a LICINFO structure with information on the licensing
capabilities of this class factory.
RequestLicKey
Creates and returns a license key that the caller can save and use
later in calls to IClassFactory2::CreateInstanceLic.
CreateInstanceLic
Creates an instance of the licensed object given a license key from
IClassFactory2::RequestLicKey.

To instantiate the component within your client application, first try
to instantiate the object directly with IClassFactory::CreateInstance.
If CreateInstance succeeds, the second machine is licensed for the
component and objects can be created at will. If CreateInstance fails
with the return code CLASS_E_NOTLICENSED, the only way to create the
object is to pass the run-time key to the
IClassFactory2::CreateInstanceLic method. CreateInstanceLic verifies
the key and creates the object if the key is valid.

In this way, an application built with components (such as controls)
can run on a machine that has no other license—only the client
application containing the run-time license is allowed to create the
component objects in question.

The IClassFactory2 interface supports flexibility in licensing
schemes. For example, the server implementor can encrypt license keys
in the component for added security. Server implementers can also
enable or disable levels of functionality in their objects by
providing different license keys for different functions. For example,
one key might allow a base level of functionality while another allows
basic and advanced functionality, and so on.

So this interface is only use to get the license information while on
the development machine (RequestLicKey). This is suplied in a
bitestring that the container MUST store if so required by the
component. The component can just implement the IClassFactory2 to say
that "no license is required", and as such the standard
IClassFactory::CreateInstance will work.
Or it may required a license, and if he (the Control) has choosen to
implement this with the IClassFactory2 method, then he will expect
this license (as retrieved by the RequestLicKey method) to be supplied
as part of the IClassFactory2::CreateInstanceLic method.

It is up to the Control to decide the content of that license string.
For example on the case of the control I am using it is a simple
readble string associated with the control name. Others, as mentioned
above, can supply an encrypted string.

There is a lot more information on the web about this implementation.
Please feel free to google for it (or www.microsoft.com)

>
>
>So, it's not PowerCOBOL related. 8-) 8-)
No. Its is PowerCOBOL related, as they do not, apparently, implement
the IClassFactory2 methoed of creating objects. Although it is not
mandatory, it is highly advisable, as not implementing it just limits
the number of third party controls that can be used with the product.
>
>
>Jeff Campbell
>n8wxs@arrl.net
>
>----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
>http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
>----= East and West-Coast Server Farms - Total Privacy via Encryption =----

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

Pete Dashwood

2006-06-17, 7:55 am

"Frederico Fonseca" <real-email-in-msg-spam@email.com> wrote in message
news:akqt825r0reartbmglo1f7sjrfhfuccogc@
4ax.com...
> On Tue, 13 Jun 2006 12:39:09 GMT, "Michael Mattias"
> <michael.mattias@gte.net> wrote:
>
> 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.
>
Sadly, I had the same experience with Fujitsu support some years back and
have never used them since. They HAD some people who really knew their stuff
but they fired them. It is a pity because the products are really very good.

In the case you outlined above, Frederico, I can understand how someone in
support would feel it was your problem. (Any time a problem cannot be
duplicated support tend to move on, and I s'pose you can't really blame
them...they are more interested in solving cases they have a chance of
solving :-)) BUT, there is no excuse for rudeness, and the very least they
could have done would be to take your project and have a look at it. (there
was a time when they used to do that...)

I had a case where I was implementing something on a customer site and the
application PowerCOBOL COM controls started producing meaningless dialog
boxes when they were accessed remotely, that were undocumented anywhere,
and which Fujitsu USA were unable to explain. Their 'solution' was to send
it to Japan and wait around 6 w

s... I rewrote the components using
NetCOBOL and it all worked fine. But I have never forgotten the stress and
long hours...neither have I forgiven them :-)

Your problem with Excel sounds like an Automation server one. I have used
Fujitsu to access MS ACCESS and MS EXCEL without problem, so it does work,
but there must have been something in your environment that prevented it.
You'd think they'd pick up your project and find it, if for no other reason
than to show that their product was OK...

I reckon they shot themselves in the foot with several things:

1. 'Downsizing' the base of people they had who knew what they were doing.
(Consequently, their tech support became laughable. The last time I used
support I was having problems with their notorious version 6 Installer and
the advice I got was from someone who had used the VB installer, so told me
the details of that process. I scrapped the Installer and wrote my own,
using components and WSH. It isn't as elegant as I would like, but it does
the job.)

2. Going to that crazy license validation system where you have to log in to
their server. (I know they weren't the only ones, but they simply didn't
listen to the comments made at the time. I still hate having to transfer my
COBOL environment when I buy a new notebook...It is a stupid fiddly process
and it doesn't stop piracy anyway.)

3. Most of all, NOT LISTENING!

I still think their products are, for the most part, excellent, but if you
are likely to need support, best avoided.

Pete.

(PS I know I've blown any chance I ever had of getting support from them by
making this post, but I've managed to get by without it for several years
now and it is interesting how inventive you become when you know you HAVE to
solve something :-))

Sponsored Links