For Programmers: Free Programming Magazines  


Home > Archive > Cobol > September 2006 > Conversion from MF Cobol to.....









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Conversion from MF Cobol to.....
MeneerKK

2006-08-14, 9:55 pm

Hello,

We are currently running MF-Cobol on a Unix machine but the machine has to
be replace.
We decided to replace it with a HP-Server with Linux.
We were however amazed at the price MF asks for the new development and
application server so we started to look around.

Uptill now I've selected NetCobol and AcuCobol.

What I was wandering, has anyone here done a conversion from MF Cobol to
another compiler?

Tia
MeneerKK
James J. Gavan

2006-08-14, 9:55 pm

MeneerKK wrote:
> Hello,
>
> We are currently running MF-Cobol on a Unix machine but the machine has to
> be replace.
> We decided to replace it with a HP-Server with Linux.
> We were however amazed at the price MF asks for the new development and
> application server so we started to look around.
>
> Uptill now I've selected NetCobol and AcuCobol.
>
> What I was wandering, has anyone here done a conversion from MF Cobol to
> another compiler?
>
> Tia
> MeneerKK



Frankly whichever way you go at it, conversion from X to Y is never a
trivial matter, for LIVE systems. There are two approaches :-

(a) Convert as is, making *NO* changes - see below - then you can
compare the results between X to Y

(b) This is the tempting one. While you are converting you think about
'enhancing', i.e. adding some spiffy features to revised applications.
Inevitably this will result in a longer drawn out process because you
are now having to test the new features.

Using (a) - Depending on what you are using for database, screening etc.
you can still run up against problems. Example, I had an old version of
DOS RM/COBOL (COBOL '74), which I thought I would convert to DOS V 3 M/F
COBOL. If it's '74 it should work, shouldn't it, no matter which
compiler I convert it to. Compiles were fine, until I hit the Screen
Section and each RM Screen statement got flagged as an error. Had I had
screening as separate programs, back then, then it might have been
easier to handle, substituting M/F Screen programs for R/M Screen
programs. I simply just rewrote and got into item (b) above.

Unfortunately whether it is AcuCOBOL or F/J NetCOBOL I don't think you
can get a 'freebie' to test against. So suggestion, select say 3 to 4
'tricky' programs, and having decided which compiler you want to use,
tell the vendor you aren't going to play unless they run your 4 programs
against their compiler and return to you the compile results.

Do you use any M/F specific features or extensions - then you should be
aware of these and give them great thought in your conversion plan.

I just hit this one to-day about an hour ago. I had to go for a medical
to qualify for renewal of my driver's licence. My GP, who is a
computer freak, and the only pen he tends to hold is a light pen, was
bemoaning his problems. He uses an extremely sophisticated piece of
software that records his billings and submits to government for
reimbursement etc, plus edging towards the 'paperless society' all his
documents per patient are scanned so he can bring them up on screen. He
claims the software cost $millions to develop; he joined the board of
directors as a technical adviser.

Now the company has been sold to another software house, who have given
the system he knew the heave ho, and substituted their own. First off -
database conversion - which the new folks did provide; he didn't
elaborate but he incurred additional costs. He claims the new
application is pitiful and the scanning feature is abysmal. Nearly
forgot; for the new application he has had to buy new servers.

With one receptionist, $23 per hour and now an assistant at $15 per hour
to handle increased data input workload - their wages are gobbling up
what he can make per hour !

(Silly doctor. Go get a new system ! He can't can he ? He's in a
Catch-22 situation locked into a system where costs would be prohibitive
to switch to a brand new application).


Jimmy
Richard

2006-08-14, 9:55 pm


MeneerKK wrote:

> We are currently running MF-Cobol on a Unix machine but the machine has to
> be replace.
> We decided to replace it with a HP-Server with Linux.
> We were however amazed at the price MF asks for the new development and
> application server so we started to look around.
>
> Uptill now I've selected NetCobol and AcuCobol.
>
> What I was wandering, has anyone here done a conversion from MF Cobol to
> another compiler?


NetCobol for Linux does not have X/Open Accept Display (ADIS) nor
Screen section. It does have ANSI ACCEPT/DISPLAY.

That is, there is no ACCEPT/DISPLAY field/screen AT position nnnn or
similar.

For interactive terminal systems you would need to use Flexus SP2 for
Unix/Linux which is a good thing to use anyway but is not like SCREEN
SECTION or ADIS.

If the Cobol system is batch based or Web based/CGI then it should be
convertable quite easily.

I have done conversions from MF ADIS to SP2 (well, almost rewrites
actually) to MF and to NetCobol for Linux with the same source code
running with both compilers. I have also done CGI based systems that
run with both compilers on several systems.

AcuCobol may be easier to convert to if it is ADIS/SCREEN SECTION but
this does have run-time costs while Fujitsu has free run-times.

HeyBub

2006-08-14, 9:55 pm

MeneerKK wrote:
> Hello,
>
> We are currently running MF-Cobol on a Unix machine but the machine
> has to be replace.
> We decided to replace it with a HP-Server with Linux.
> We were however amazed at the price MF asks for the new development
> and application server so we started to look around.
>
> Uptill now I've selected NetCobol and AcuCobol.
>
> What I was wandering, has anyone here done a conversion from MF Cobol
> to another compiler?


But Linux is free! Long-live open source! Microsoft is the spawn of Satan!
Think Green! Go Hybrid!

So what if if costs a few thousand, you'll make this a better world!

On a more practical matter, get HP to pay for the new MF compiler, else no
deal. What, you say? The compiler costs more than the server?

Oh well, it's for the children.


Richard

2006-08-15, 3:55 am


James J. Gavan wrote:

> Unfortunately whether it is AcuCOBOL or F/J NetCOBOL I don't think you
> can get a 'freebie' to test against.


I have had a time limited demo/test version from Acu and I know that
Fujitsu will give out a time limited license for NetCobol for Linux.

> So suggestion, select say 3 to 4
> 'tricky' programs, and having decided which compiler you want to use,
> tell the vendor you aren't going to play unless they run your 4 programs
> against their compiler and return to you the compile results.


I doubt that many vendors will do that for free. The compilers are just
not expensive enough to cover the time required to do that on a
speculative basis.

> Now the company has been sold to another software house, who have given
> the system he knew the heave ho, and substituted their own. First off -
> database conversion - which the new folks did provide; he didn't
> elaborate but he incurred additional costs. He claims the new
> application is pitiful and the scanning feature is abysmal. Nearly
> forgot; for the new application he has had to buy new servers.


> With one receptionist, $23 per hour and now an assistant at $15 per hour
> to handle increased data input workload - their wages are gobbling up
> what he can make per hour !
>
> (Silly doctor. Go get a new system ! He can't can he ? He's in a
> Catch-22 situation locked into a system where costs would be prohibitive
> to switch to a brand new application).


That is how proprietry systems are holding their customers to ransom -
by controlling access to their data. In order to access his own data he
must use the system, and now must use the replacement, and presumably
must pay each year or the system will stop working.

One needs to read license terms closely to ensure that they are
perpetual and not reliant on the whims of the vendor or his remaining
in business. The implication of the above was that it was not an option
for the doctor to remain using the old system and have independent
support.

DRM is a major move to remove freedoms and to enforce recurring fees
rather than perpetual use. If you don't pay the annual or monthly
subscription then everything you bought will stop working.

It seems that Microsoft is moving down that path too. Many corporates
need to continue to pay the 'select' subs because they traded their
perpetual licences for expiring ones that they have received little
for.

The answer is to put your data into formats that are accessible from
many systems. SQL should be used so that it can be accessed using
freely available PostgreSQL or MySQL (or Firebird or other FOSS).
Documents should be stored in the newly developed ISO ODF rather than
undocumented and changing proprietry formats that are locked into one
vendor.

Frederico Fonseca

2006-08-15, 3:55 am

On 14 Aug 2006 16:55:01 -0700, "Richard" <riplin@Azonic.co.nz> wrote:

>
>MeneerKK wrote:
>
>
>NetCobol for Linux does not have X/Open Accept Display (ADIS) nor
>Screen section. It does have ANSI ACCEPT/DISPLAY.
>
>That is, there is no ACCEPT/DISPLAY field/screen AT position nnnn or
>similar.
>
>For interactive terminal systems you would need to use Flexus SP2 for
>Unix/Linux which is a good thing to use anyway but is not like SCREEN
>SECTION or ADIS.
>
>If the Cobol system is batch based or Web based/CGI then it should be
>convertable quite easily.
>
>I have done conversions from MF ADIS to SP2 (well, almost rewrites
>actually) to MF and to NetCobol for Linux with the same source code
>running with both compilers. I have also done CGI based systems that
>run with both compilers on several systems.
>
>AcuCobol may be easier to convert to if it is ADIS/SCREEN SECTION but
>this does have run-time costs while Fujitsu has free run-times.

Just to add to this.

Fujitsu may have free runtimes, but it has a sub-standard technical
support. I would avoid them if possible

All other COBOL prividers should also include RM/COBOL from Liant.
Both have runtime charges, and as ACUCOBOL's ones are not published
you will need to contact both companies with your specific situation
and ask them the prices for development and runtime for your
particular situation. BE SURE to explain it very clearly in terms of
what type of accees to the server you need. e.g. is it a webshop with
customers accessing the COBOL server through the WEB? or is is a more
old fashioned application with all users on the LAN?


Liant sales support will help you with your converstion, and will most
probably be able to supply you with a demo compiler that you can use.

Work involved on the conversion will depend on what type of
instructions you use on your program, whether you have E-SQL, and on
other things.


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

2006-08-15, 3:55 am

MeneerKK schrieb:

> Hello,
>
> We are currently running MF-Cobol on a Unix machine but the machine has to
> be replace.
> We decided to replace it with a HP-Server with Linux.
> We were however amazed at the price MF asks for the new development and
> application server so we started to look around.
>
> Uptill now I've selected NetCobol and AcuCobol.
>
> What I was wandering, has anyone here done a conversion from MF Cobol to
> another compiler?
>
> Tia
> MeneerKK


Hello MeneerKK,

it is no secret that MF is asking for "some" money, for both the
development environment as well as for the runtime system.

As you have seen, the Cobol code is one issue to look at, there are
however others like terminal I/O and database/files to look into.

Check out Open Cobol, this is a Cobol implementation that will "set you
free" from future licensing requirements. Some adaptions will most
likely be required and you're missing a similar source level debugging
feature.

Forget asking the server manufacturer for help, they have handed the
Cobol support over to MF and MF is asking you to purchase their new
Server Express products, normal business.

Regards HansJ

MeneerKK

2006-08-15, 3:55 am


HansJ schreef:

> MeneerKK schrieb:
>
>
> Hello MeneerKK,
>
> it is no secret that MF is asking for "some" money, for both the
> development environment as well as for the runtime system.
>


To explain this kind of money I will have to adjust my definition of
"some" ;))

> As you have seen, the Cobol code is one issue to look at, there are
> however others like terminal I/O and database/files to look into.
>


All the screen I/O is luckely situated in one program. The only one
that uses specific MF-coding.

In answer to others.
For NetCobol we will be using the NetCobol for Windows which has
Accept/Display.
Currently the NetCobol vendor is doing a Proof of concept for us.

> Check out Open Cobol, this is a Cobol implementation that will "set you
> free" from future licensing requirements. Some adaptions will most
> likely be required and you're missing a similar source level debugging
> feature.
>


I will certainly have a look at those as well.

> Forget asking the server manufacturer for help, they have handed the
> Cobol support over to MF and MF is asking you to purchase their new
> Server Express products, normal business.
>


For the price MF asks we can buy some 14 new HP servers.

--

MeneerKK





> Regards HansJ


MeneerKK

2006-08-15, 7:55 am


James J. Gavan schreef:

> MeneerKK wrote:
< conversion blabble scrapped>[color=darkred]
>
> Frankly whichever way you go at it, conversion from X to Y is never a
> trivial matter, for LIVE systems. There are two approaches :-
>
> (a) Convert as is, making *NO* changes - see below - then you can
> compare the results between X to Y
>


This is the conversion we like to make.
At the end of the year we will have to make changes in the coding
because the tax-collector will change its rules (again).

> (b) This is the tempting one. While you are converting you think about
> 'enhancing', i.e. adding some spiffy features to revised applications.
> Inevitably this will result in a longer drawn out process because you
> are now having to test the new features.
>


As we have a small company with only 1,6 developpers we don't want to
do this. Not if we can help it.

> Using (a) - Depending on what you are using for database, screening etc.
> you can still run up against problems. Example, I had an old version of
> DOS RM/COBOL (COBOL '74), which I thought I would convert to DOS V 3 M/F
> COBOL. If it's '74 it should work, shouldn't it, no matter which
> compiler I convert it to. Compiles were fine, until I hit the Screen
> Section and each RM Screen statement got flagged as an error. Had I had
> screening as separate programs, back then, then it might have been
> easier to handle, substituting M/F Screen programs for R/M Screen
> programs. I simply just rewrote and got into item (b) above.
>


We are fortunate that 9 years ago we had to cnvert form a Philips
system to the current system and the screen-handling was completely
different between the two. We had an agency convert the routines and
the created a seperate program for all the screen handling.

The only problem will be the database. I've already heard that the sign
in numeric fields is nog always in the same spot.


> Unfortunately whether it is AcuCOBOL or F/J NetCOBOL I don't think you
> can get a 'freebie' to test against. So suggestion, select say 3 to 4
> 'tricky' programs, and having decided which compiler you want to use,
> tell the vendor you aren't going to play unless they run your 4 programs
> against their compiler and return to you the compile results.
>


The NetCobol vendordoes a proof of concept (for free) of the three most
tricky programs. One of them is the screen-handling program. When that
works I'm confident thatthe rest will work as well.

> Do you use any M/F specific features or extensions - then you should be
> aware of these and give them great thought in your conversion plan.
>


The only place we use MF specific routines is in the screen-handling
program (even with hex-calls) but that is in the proof of concept.

In the other posts it was suggested to include RM/Cobol and opensource
Cobol in the list of possibilities. This will be done.

--
MeneerKK

HansJ

2006-08-15, 7:55 am


MeneerKK schrieb:

snip....
>
> For the price MF asks we can buy some 14 new HP servers.
>
> --
>
> MeneerKK
>


MeneerKK, so you are supporting a significant number of users with that
system.

When all screen I/O is within one program, that's an ideal situation,
so what about the database / files being used?


Regards HansJ

MeneerKK

2006-08-15, 7:55 am


HansJ schreef:

> MeneerKK schrieb:
>
> snip....
>
> MeneerKK, so you are supporting a significant number of users with that
> system.
>


We will be using 2 HP servers (Production and testing). They are not
that big because we only have some 15 users.


> When all screen I/O is within one program, that's an ideal situation,
> so what about the database / files being used?
>


All files are Cobol created and handled.
This means that when we switch we will have to convert them to the new
standard.
The NetCobol vendor has already said he has a conversion tool for the
files.

We have some 200 files which are year-specific (it's a payroll-company)
totalling about 2 G. Currently we can only have 2 years in production
and when the tax-collector comes for another year we have to scrap the
previous year, put the backup of the requested year on the machine, run
the reports and reset the backup of the previous year. That will not be
neccesary anymore as we will get two 400+G disks on each server. At
last we can have the mandatory 10 years online ;)
But ALL the files will have to be converted. As well as all the
programs, also year specific.

--
MeneerKK



>
> Regards HansJ


William M. Klein

2006-08-15, 7:55 am

When looking at "NetCOBOL" "proof of concept" and MF-specific code, make certain
that what you get with the new compiler is SUPPORTED syntax. My favorite
Fujitsu-ism is

SET ADDRESS OF (statement)

It works in every Fujitsu compiler that I have ever heard of or seen, but they
STEADFASTLY refuse to document it as a supported Fujitsu syntax. They have
indicated they make no claims that they will CONTINUE to support it in future
releases (although I strongly doubt they will stop doing so).

What I would do is make Fujitsu document (and sign) that their "proof of
concept" code uses only code that is documented in their current LRM (and use
SET ADDRESS as an example of what you do not want - or want added to their
documentation).

If you are interested in others of these "may or may not work in the future"
examples, let me know I will try and dig out some of my old lists.

--
Bill Klein
wmklein <at> ix.netcom.com
"MeneerKK" <meneerKK@zonnet.nl> wrote in message
news:1155637128.419453.253350@m73g2000cwd.googlegroups.com...
>
> James J. Gavan schreef:
>
> < conversion blabble scrapped>
>
> This is the conversion we like to make.
> At the end of the year we will have to make changes in the coding
> because the tax-collector will change its rules (again).
>
>
> As we have a small company with only 1,6 developpers we don't want to
> do this. Not if we can help it.
>
>
> We are fortunate that 9 years ago we had to cnvert form a Philips
> system to the current system and the screen-handling was completely
> different between the two. We had an agency convert the routines and
> the created a seperate program for all the screen handling.
>
> The only problem will be the database. I've already heard that the sign
> in numeric fields is nog always in the same spot.
>
>
>
> The NetCobol vendordoes a proof of concept (for free) of the three most
> tricky programs. One of them is the screen-handling program. When that
> works I'm confident thatthe rest will work as well.
>
>
> The only place we use MF specific routines is in the screen-handling
> program (even with hex-calls) but that is in the proof of concept.
>
> In the other posts it was suggested to include RM/Cobol and opensource
> Cobol in the list of possibilities. This will be done.
>
> --
> MeneerKK
>



Michael Mattias

2006-08-15, 7:55 am

"MeneerKK" <meneerKK@zonnet.nl> wrote in message
news:1155635908.151437.85150@h48g2000cwc.googlegroups.com...
>
>
> For the price MF asks we can buy some 14 new HP servers.


Back in '99 when I made the strategic decision to "do Windows(r)" I was
looking at both COBOL and BASIC solutions.

Since I was at that time equally facile in both languages, my decision was
based on non-language considerations, such as cost, the future, runtimes,
portability in case of changes in vendor policies, etc.......

Looking purely at the costs of the development software itself, that
$229.00 up front plus maybe $500.00 in subsequent upgrades for the BASIC
compiler appears to have been a very good guess on my part.

MCM












James J. Gavan

2006-08-15, 6:55 pm

MeneerKK wrote:
> HansJ schreef:
>
>
>

You are getting some good advice. However, perhaps the best bit of news
is your comment below where you should be able to substituter another
vendor's screen program to replace M/F's. (Not necessarily immediately,
but you might perhaps want to break the new screen support program down
into separate modules for calling, depending upon displays you want).

Anyway, what is reassuring is that you are carefully thinking your
conversion through before you jump.


> All the screen I/O is luckely situated in one program. The only one
> that uses specific MF-coding.
>
> In answer to others.
> For NetCobol we will be using the NetCobol for Windows which has
> Accept/Display.
> Currently the NetCobol vendor is doing a Proof of concept for us.


I don't know about F/J's Screen Section but certainly some users here
have indicated it is a bit weak - so possibly something to look out for.

Richard - are you up-to-date on NetCOBOL's Screen Section - has it in
anyway been enhanced ?

Frederico - I noted from a previous message where somebody posted an RM
Screen demo that they appear to have enhanced their version - still
their old style syntax but with new additions. Any pertinent comments ?

Jimmy
MeneerKK

2006-08-15, 6:55 pm

Tue, 15 Aug 2006 19:36:20 GMT schreef James J. Gavan:

>MeneerKK wrote:
>You are getting some good advice.


Indeed. Thanks everyone.
It more than I dared to hope for.

>However, perhaps the best bit of news
>is your comment below where you should be able to substituter another
>vendor's screen program to replace M/F's. (Not necessarily immediately,
>but you might perhaps want to break the new screen support program down
>into separate modules for calling, depending upon displays you want).
>


The main reason we don't want to change the way we are displaying is that
the users don't want to change to windows-screens with clicks etc and the
other programmer is 60+ and only has to go for some 2 years.
The reason for the change is the Alpha-server which is on the vege of
breaking down.


>Anyway, what is reassuring is that you are carefully thinking your
>conversion through before you jump.
>


Due to the advice here I've now selected 4 compilers in my short list.
One, NetCobol is already 'working'. For RM/Cobol I will have to find a
Dutch supplier and the AcuCorp people will be back from their holidays
after this w.
From all I want to see a finished, woring product.

>
>I don't know about F/J's Screen Section but certainly some users here
>have indicated it is a bit weak - so possibly something to look out for.
>
>Richard - are you up-to-date on NetCOBOL's Screen Section - has it in
>anyway been enhanced ?
>


I'm interested in the answer. According to hte Dutch vendor there should be
no problem but then again he had never heard from a report section.

>Frederico - I noted from a previous message where somebody posted an RM
>Screen demo that they appear to have enhanced their version - still
>their old style syntax but with new additions. Any pertinent comments ?
>


Again, extremely interested in the answer.

Thanks everybody for their comments


---
MeneerKK

2006-08-15, 6:55 pm

In article <sed4e297e0f406s50oe5j8rktbmnkuv3lo@4ax.com>,
MeneerKK <meneerKK@zonnet.nl> wrote:

[snip]

>The main reason we don't want to change the way we are displaying is that
>the users don't want to change to windows-screens with clicks etc and the
>other programmer is 60+ and only has to go for some 2 years.


What the users want is, of course, very important (as long as it does not
detract excessively from what the business wants, i.e. (usually) to make
money. As for the programmer's age and plans for retirement... the
business should be able to continue if (may all in Heaven forbid such a
thing ever coming to pass!) he were to be hit tomorrow by a beer-truck.

>The reason for the change is the Alpha-server which is on the vege of
>breaking down.


Bingo. Machinery has a certain life-expectancy and plans are best made
long before this expectancy is reached... and it might be nice, also, to
have something in ready Just In Case the machinery breaks *before* it is
due to; such things have, every now and then, been known to happen.
Likewise with human beings... they have a certain life-expectancy and
plans are best made long before this is reached... and it might be nice,
also, to have something in place Just In Case the vectors of the person's
and the beer-truck's motions have an unexpected intersection.

But... what do I know about such things, I am just a COBOL-coding fool...
such planning and foresight is the province of the people with the Big
Picture, the Managers!

DD
Richard

2006-08-15, 6:55 pm


James J. Gavan wrote:

> Richard - are you up-to-date on NetCOBOL's Screen Section - has it in
> anyway been enhanced ?


Don't do SCREEN SECTION, don't do Windows.

Actually I do have legit copie of Fujitsu Cobol 3 for Win3.1 and Win95,
4 and 6 for Windows and printed manuals even. but I have only used it
for testing and that with Flexus SP2.

Frederico Fonseca

2006-08-15, 6:55 pm

On Tue, 15 Aug 2006 19:36:20 GMT, "James J. Gavan"
<jgavandeletethis@shaw.ca> wrote:

>MeneerKK wrote:
snip[color=darkred]
>
>I don't know about F/J's Screen Section but certainly some users here
>have indicated it is a bit weak - so possibly something to look out for.

W indeed.
snip
>
>Frederico - I noted from a previous message where somebody posted an RM
>Screen demo that they appear to have enhanced their version - still
>their old style syntax but with new additions. Any pertinent comments ?


Thiw will really depend on what version you were comparing.
There have been several changes on what can be displayed using
standard displays (display xxx at yyy zzz), but the bulk of it is
there since version 5.17 and v 7.
These changes include the possiblity of displaying with specific masks
(e.g. XXX-XXX-XXX), or other functions, pop-up windows (which speed up
(re)displays, mainly on dumb terminals) and other stuff.

By using the screen design tools (RM/PANELS and COBOL-WOW
(WOW-EXTENSIONS as its now calleed) then its possible to have even
more stuff done, but so is by using a third party product such as SP2
from Flexus. Both these methods allow for a thin client on windows,
with a RUNTIME server on a Unix machine, wich may be very handy.



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

2006-08-15, 6:55 pm

On Tue, 15 Aug 2006 23:23:52 +0200, MeneerKK <meneerKK@zonnet.nl>
wrote:

>Tue, 15 Aug 2006 19:36:20 GMT schreef James J. Gavan:

snip
>
>Due to the advice here I've now selected 4 compilers in my short list.
>One, NetCobol is already 'working'. For RM/Cobol I will have to find a
>Dutch supplier and the AcuCorp people will be back from their holidays
>after this w.
>From all I want to see a finished, woring product.

see http://www.liant.com/buy/ for the UK or Germany contact.

My company (www.memosis.pt) can also sell you the RM/COBOL products if
you prefer (we sure would prefer that!!!), but all contacts must be
done in English.

If you need a quick test of your programs, I may be able to do that
for you if you cant get any of the other Liant contacts to do this
quickly. If so email me privately.



snip
>
>
>Again, extremely interested in the answer.

see my other post. If you need full details please email me privately.



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

2006-08-17, 6:55 pm

Tue, 15 Aug 2006 22:21:54 +0000 (UTC) schreef docdwarf@panix.com ():

>In article <sed4e297e0f406s50oe5j8rktbmnkuv3lo@4ax.com>,
>MeneerKK <meneerKK@zonnet.nl> wrote:
>
>
>What the users want is, of course, very important (as long as it does not
>detract excessively from what the business wants, i.e. (usually) to make
>money. As for the programmer's age and plans for retirement... the
>business should be able to continue if (may all in Heaven forbid such a
>thing ever coming to pass!) he were to be hit tomorrow by a beer-truck.
>


Last year, as he was on holiday an error occured and he couldn't be
reached. That's when the boss decided to have an extra man at the ready,
me. I still hope he isn't hit by a beer-truck but the bussiness will
continue if it happens.

>
>Bingo. Machinery has a certain life-expectancy and plans are best made
>long before this expectancy is reached... and it might be nice, also, to
>have something in ready Just In Case the machinery breaks *before* it is
>due to; such things have, every now and then, been known to happen.
>Likewise with human beings... they have a certain life-expectancy and
>plans are best made long before this is reached... and it might be nice,
>also, to have something in place Just In Case the vectors of the person's
>and the beer-truck's motions have an unexpected intersection.
>


The testmachine broke down a few ws ago, afetr replacing the powersuplly
it worked again.
The replacing of the machines has been posponed several times until we (the
programming tam) had time. That will never happen but now we must replace
everything in a hurry because december is already looming.


>But... what do I know about such things, I am just a COBOL-coding fool...
>such planning and foresight is the province of the people with the Big
>Picture, the Managers!
>


I'm also a COBOL-scribbler but with some foresight. I think it came with
the age (50+).

--
MeneerKK
MeneerKK

2006-08-17, 6:55 pm

Wed, 16 Aug 2006 01:54:09 +0100 schreef Frederico Fonseca:

>On Tue, 15 Aug 2006 23:23:52 +0200, MeneerKK <meneerKK@zonnet.nl>
>wrote:
>
>snip
>see http://www.liant.com/buy/ for the UK or Germany contact.
>
>My company (www.memosis.pt) can also sell you the RM/COBOL products if
>you prefer (we sure would prefer that!!!), but all contacts must be
>done in English.
>


I've already contacted Liant and found out that RM/Cobol doesnot support
the report section. That si the section we most use so RM is out of the
race.

--
MeneerKK
replace the maan with a zon to email
James J. Gavan

2006-08-17, 6:55 pm

MeneerKK wrote:
> Wed, 16 Aug 2006 01:54:09 +0100 schreef Frederico Fonseca:
>
>
>
>
> I've already contacted Liant and found out that RM/Cobol doesnot support
> the report section. That si the section we most use so RM is out of the
> race.
>

Not necessarily out of the race if you favour RM. I know we are talking
about probably a fair number of reports. However even with RW you are
producing a facsimile of printed lines in the Report Section - rather
like the same thing done for display with the Screen Section. Then of
course you INITIATE and GENERATE.

Should you still favour RM, (and don't forget they have runtime fees
too, but I'm not aware of costs), you could take a look at some of the
separate tools for printing - where you pass a facsimile from COBOL to
their files and they print from there. Take a look at :-

http://www.sanface.com/txt2pdf.html

Not suggesting you use it - but it is an option.

They have also been indirectly mentioned here - Flexus.com and their
product SP2. I don't know it personally, but it will handle Screen(text)
or GUI displays, plus I'm fairly certain it also has a print feature.


Jimmy

2006-08-17, 6:55 pm

In article <62f9e2t3ogtjj6tn8uhpou02j9f5aj6amf@4ax.com>,
MeneerKK <meneerKK@zonnet.nl> wrote:
>Tue, 15 Aug 2006 22:21:54 +0000 (UTC) schreef docdwarf@panix.com ():
>
>
>Last year, as he was on holiday an error occured and he couldn't be
>reached. That's when the boss decided to have an extra man at the ready,
>me.


And it took only... how many years for the boss to realise that 'hmmmmm,
maybe it is *not* a Very Good Idea to have all this knowledge about system
processes in the head of only one individual'?

>I still hope he isn't hit by a beer-truck but the bussiness will
>continue if it happens.


Of course it will continue... the question becomes one of 'will it
continue and profitably?'

>
>
>The testmachine broke down a few ws ago, afetr replacing the powersuplly
>it worked again.


How fortunate... so this has served as an example for how the Prod
machines should be dealt with, right?

>The replacing of the machines has been posponed several times until we (the
>programming tam) had time. That will never happen but now we must replace
>everything in a hurry because december is already looming.


In the USA some people say 'There's never enough time to do it right but
there's always enough time to do it over.

>
>
>
>I'm also a COBOL-scribbler but with some foresight. I think it came with
>the age (50+).


I have known teen-aged school dropouts who have good heads... and I have
known PhDs with walls covered with school-paper and nothing between their
ears. I hope things work well for you.

DD

MeneerKK

2006-08-18, 6:55 pm

Fri, 18 Aug 2006 00:42:17 +0000 (UTC) schreef docdwarf@panix.com ():

>
>And it took only... how many years for the boss to realise that 'hmmmmm,
>maybe it is *not* a Very Good Idea to have all this knowledge about system
>processes in the head of only one individual'?
>


I don't know exactly but I know they tried to get a 'new' man more then
once. The others came and went because the big bucks lured.

>
>Of course it will continue... the question becomes one of 'will it
>continue and profitably?'
>


I now know enough to keep everything running.
As I'm a very good programmer and not one who claims that his way is the
only way, I can read and adjust proigrams not written by me.

>
>How fortunate... so this has served as an example for how the Prod
>machines should be dealt with, right?
>


No, this was after the new machines had been ordered. The delivery time of
two ws is already two ws late but ......... hopefully the are there
monday morning (I don't work on thursday and friday).


>
>In the USA some people say 'There's never enough time to do it right but
>there's always enough time to do it over.
>


I will remember that one.

>
>I have known teen-aged school dropouts who have good heads... and I have
>known PhDs with walls covered with school-paper and nothing between their
>ears. I hope things work well for you.
>


I managed to stay in jobs and earn my money for over 30 years now. I'm one
of the few people I know that are married for more then 30 years.
I feel lucky and am happy so....... I think it works fine for me.


--

MeneerKK
Replace maan with zon
MeneerKK

2006-08-18, 6:55 pm

Fri, 18 Aug 2006 00:18:44 GMT schreef James J. Gavan:

>Not necessarily out of the race if you favour RM. I know we are talking
>about probably a fair number of reports. However even with RW you are
>producing a facsimile of printed lines in the Report Section - rather
>like the same thing done for display with the Screen Section. Then of
>course you INITIATE and GENERATE.
>


It's not that we really, really want RM. We just found that MF(Netherlands)
charges us a lot and we are looking around.

>
>Not suggesting you use it - but it is an option.
>


All suggestions are taken as they are presented, as suggestions, not as a
'you must do this'.

>They have also been indirectly mentioned here - Flexus.com and their
>product SP2. I don't know it personally, but it will handle Screen(text)
>or GUI displays, plus I'm fairly certain it also has a print feature.
>


Up to now the users still want to retain the character-based screens. For
some its almost a holy war against GUI-screens.

--

MeneerKK
Replace maan with zon

2006-08-18, 6:55 pm

In article <3t9ce25nghufva595gg6r2a3b4pnrhb6tq@4ax.com>,
MeneerKK <meneerKK@zonnet.nl> wrote:
>Fri, 18 Aug 2006 00:42:17 +0000 (UTC) schreef docdwarf@panix.com ():
>
>
>I don't know exactly but I know they tried to get a 'new' man more then
>once. The others came and went because the big bucks lured.


Hmmmmm... let me see if I have this straight. Someone with a knowledge of
the company's needs tried to hire a person to fill a position and that
person left 'because the big bucks lured'. At least one other person did
the same (I base this on your use of a plural, 'others')... so this person
with a knowledge of the company's needs said something like:

'We hired someone to fill the job... and they left because they could make
more money elsewhere. We hired someone else to fill this job... and they
left because they could make more money elsewhere. We did this (n) times
with (n) people... so the obvious conclusion is that we do not have to
increase what we are paying for this particular commodity/skill in order
to match market rates!'

As I have said before... I do not think I can lower the quality of my
thinking far enough to be a Manager.

>
>
>I now know enough to keep everything running.
>As I'm a very good programmer and not one who claims that his way is the
>only way, I can read and adjust proigrams not written by me.


Hmmmmm... and what happens when you realise that another organisation will
pay more for your skills... or you get hit by a beer-truck... or you live
another fewer-than-ten years and *you* are now the sixty-year-old ready to
retire and not caring?

>
>
>No, this was after the new machines had been ordered. The delivery time of
>two ws is already two ws late but ......... hopefully the are there
>monday morning (I don't work on thursday and friday).


Let it be hoped, then, that your hopes, hopefully, are realised.

>
>
>
>I will remember that one.


Feel free to use it... and remember that a Good Scholar will cite sources.

>
>
>I managed to stay in jobs and earn my money for over 30 years now. I'm one
>of the few people I know that are married for more then 30 years.
>I feel lucky and am happy so....... I think it works fine for me.


A phrase I find myself repeating, in all seriousness, is 'Life is Good...
and It just keeps Getting Better.'

DD

James J. Gavan

2006-08-18, 6:55 pm

MeneerKK wrote:[color=darkred]
>

I think you missed my point above - SP2 can be used with EITHER
character-based screens, (I wrote 'screen(text)'), OR GUI, i.e.
'Windows' - so the users' preference for character-based can be met.

Jimmy

William M. Klein

2006-08-19, 3:55 am

If interested in RM but you need/want REPORT SECTION check out an add-on (that I
know works with RM). See:

http://www.spc-systems.com/

This fully supports "traditional" COBOL Report Writer syntax - and some
extensions too.

If you want me to get you in touch with them, contact me off-line.

--
Bill Klein
wmklein <at> ix.netcom.com
"MeneerKK" <meneerKK@zonnet.nl> wrote in message
news:7hace2lds5bfgcrstvejqunbduh5k72op1@
4ax.com...
> Fri, 18 Aug 2006 00:18:44 GMT schreef James J. Gavan:
>
>
> It's not that we really, really want RM. We just found that MF(Netherlands)
> charges us a lot and we are looking around.
>
>
> All suggestions are taken as they are presented, as suggestions, not as a
> 'you must do this'.
>
>
> Up to now the users still want to retain the character-based screens. For
> some its almost a holy war against GUI-screens.
>
> --
>
> MeneerKK
> Replace maan with zon



Alistair

2006-08-19, 7:55 am


docdwarf@panix.com wrote:
> In article <3t9ce25nghufva595gg6r2a3b4pnrhb6tq@4ax.com>,
> MeneerKK <meneerKK@zonnet.nl> wrote:
[color=darkred]
>
> Hmmmmm... let me see if I have this straight. Someone with a knowledge of
> the company's needs tried to hire a person to fill a position and that
> person left 'because the big bucks lured'. At least one other person did
> the same (I base this on your use of a plural, 'others')... so this person
> with a knowledge of the company's needs said something like:
>
> 'We hired someone to fill the job... and they left because they could make
> more money elsewhere. We hired someone else to fill this job... and they
> left because they could make more money elsewhere. We did this (n) times
> with (n) people... so the obvious conclusion is that we do not have to
> increase what we are paying for this particular commodity/skill in order
> to match market rates!'
>


But the small bucks were sufficient to lure someone in on each occasion
and encourage them to stay a while. So it works but is not cost
effective or morale boosting.

2006-08-19, 6:55 pm

In article <1155986902.167659.154600@p79g2000cwp.googlegroups.com>,
Alistair <alistair@ld50macca.demon.co.uk> wrote:
>
>docdwarf@panix.com wrote:
>
>
>But the small bucks were sufficient to lure someone in on each occasion
>and encourage them to stay a while. So it works but is not cost
>effective or morale boosting.


I'm not sure how you are using 'works' here, Mr Maclean; there have been
instances I have seen where the 'big bucks lure' has given the hiring firm
insufficient time to get from the new hire a return on the necessary loss
entailed in a new hire... so in addition to leaving a hole in coverage the
company is unrecompensed for search, training and familiarisation costs.

Holes in coverage *and* additional expenses... 'it works', indeed!

DD

MeneerKK

2006-08-20, 6:55 pm

Fri, 18 Aug 2006 22:03:58 +0000 (UTC) schreef docdwarf@panix.com ():

>In article <3t9ce25nghufva595gg6r2a3b4pnrhb6tq@4ax.com>,
>MeneerKK <meneerKK@zonnet.nl> wrote:
>


<the others sniped>

The pay is market-based. But it is a small company and that needs
adjusting.
Here in the Netherlands you can get a better job if you work for an agency.
That is always luring. Certainly for the younger men that were hired before
me.

>
>As I have said before... I do not think I can lower the quality of my
>thinking far enough to be a Manager.
>


This is not the lower thinking of a manager, this is the 'normal' run of
carreers. Some people will get a few months work-experience and then go for
the agencies that offer cars, mobiles and more.
They forget that they will have to make much more hours because they will
hardly work in their home-town. And in the Netherlands traffic-jams are
extreemly common.

>
>Hmmmmm... and what happens when you realise that another organisation will
>pay more for your skills... or you get hit by a beer-truck... or you live
>another fewer-than-ten years and *you* are now the sixty-year-old ready to
>retire and not caring?
>


I got an offer just a few ws ago. It was more money, and a car and and
and.
But, I now work at 10 minutes biking from home. So about half an hour of
traveling a day. That will certainly have grown to about 3 hours a day.
So, I have decided to stay. I only have to do some 12 years. Then only
traveling half an hour a day is very luring.


--

MeneerKK
Replace maan with zon

2006-08-20, 6:55 pm

In article <v4ehe25ne5j3vimloj68hnkchb4un9tski@4ax.com>,
MeneerKK <meneerKK@zonnet.nl> wrote:
>Fri, 18 Aug 2006 22:03:58 +0000 (UTC) schreef docdwarf@panix.com ():
>
>
><the others sniped>
>
>The pay is market-based. But it is a small company and that needs
>adjusting.


The small company, rather frequently, draws from the same labor-pool as
the larger ones... and participates in the same market. When I go to the
supermarket the price-scanner does not look at me and say 'Oh, he works
for a small company... he gets charged less!' When I order from
Amazon.com or bid on an item on eBay it is the same thing.

>Here in the Netherlands you can get a better job if you work for an agency.
>That is always luring. Certainly for the younger men that were hired before
>me.


After certain necessities are taken care of - sleep, food, shelter,
clothing and the like - then the remainders of the factors of the economic
equations which can be seen as composing an individual's life can be seen
as having a kind of 'weighting'... see below.

>
>
>This is not the lower thinking of a manager, this is the 'normal' run of
>carreers. Some people will get a few months work-experience and then go for
>the agencies that offer cars, mobiles and more.
>They forget that they will have to make much more hours because they will
>hardly work in their home-town.


That depends on what they choose to live, neh? When I was consulting in
Manhattan I would hear constant discussions about how people should
balance the amount of commuting time with how much they would have to pay
their landlords... the closer to Manhattan the shorter the commute but the
higher the rent. I think I addressed this at another time... ahhhhhh,
here it is, from
<http://groups.google.com/group/comp...b?output=gplain>

--begin quoted text:

(side note - this same approach, when applied to the question of what
salary it would take to get me to shift from consultant to employee in
Manhattan, would generate slack-jawed amazement; I would base my figures
on two facts and one assumption:

Fact: the Federal Housing Authority (FHA) recommends that housing ans
associated expenses consume no more than 25% - 33% of one's income.

Fact: an average one-bedroom apartment in Manhattan costs (US$x).

Assumption: It is a Good and Proper Thing for a company to pay a skilled,
technical employee enough to afford at *least* an average, one-bedroom in
the town in which s/he is expected to work.)

--end quoted text

>And in the Netherlands traffic-jams are
>extreemly common.


Not much of a traffic-jam if you earn enough to walk to work, I'd say.

>
>
>I got an offer just a few ws ago. It was more money, and a car and and
>and.
>But, I now work at 10 minutes biking from home. So about half an hour of
>traveling a day. That will certainly have grown to about 3 hours a day.
>So, I have decided to stay. I only have to do some 12 years. Then only
>traveling half an hour a day is very luring.


And there you have it... you, on the one hand, value your time and the
difficulty of your commute more than you value the 'and and' that you have
been offered, other programmers value the 'and and'. It would seem that
your hierarchy of values is different than that of other coders... or else
they would not have left for the 'and and'.

Looking for an employee with a specific and unusual set of values might
cause a company to... wait for a while, to say the least.

DD

Pete Dashwood

2006-08-21, 3:55 am


"MeneerKK" <meneerKK@zonnet.nl> wrote in message
news:v4ehe25ne5j3vimloj68hnkchb4un9tski@
4ax.com...
> Fri, 18 Aug 2006 22:03:58 +0000 (UTC) schreef docdwarf@panix.com ():
>
<snipped interesting viewpoints>[color=darkred]
> I got an offer just a few ws ago. It was more money, and a car and and
> and.
> But, I now work at 10 minutes biking from home. So about half an hour of
> traveling a day. That will certainly have grown to about 3 hours a day.
> So, I have decided to stay. I only have to do some 12 years. Then only
> traveling half an hour a day is very luring.
>

I have followed this thread with interest and just wanted to say I am very
impressed with your responses. The attitude you show is that of a man at
peace with himself and with a secure grasp of what he values in life. You
have made some realizations that many people NEVER make; principally, that
your growth as a person is more important than your growth as an employee,
and secondly, that to be happy in your life is to be happy in your work.

My respect and regards to you.

The only thing that worries me a little are your last two sentences
above....

I know you are thinking in terms of 12 years and you are not really
interested in swapping your current situation for a more materially
attractive one, but it might be wise to have a "fallback" position, just in
case the company decide they cannot maintain your employment some time
during the 12 years. It might not be malevolence on their part...the fact
is that circumstances change and companies have to do unpleasant things to
survive sometimes.

During the course of my career I have seen a number of occasions where loyal
decent employees (often with more than 25 years service and totally
dedicated to the company), have been terminated with just the legal
requirement for notice and their holiday pay...

I'm sure the company recognise your value (even though they probably can't
afford to pay you more) and your attitude is one that many companies would
be very pleased to have in their employees, but you cannot guarantee the
twelve years.

Still, given your value set, I would think if it does go pear shaped you
will not have much trouble getting another job; you may just have to trade
some of your current comforts.

I completely relate to your abhorrence of long commutes. I worked at a job
in England that required nearly four hours a day commuting...on crowded
underground and overground trains, with surly people, in darkness...:-) It
made me think, and I realised that many of these people do this because they
have no other choice, and, in some cases, they know of no other way. When
you have a wife and kids it is pretty hard to uproot the family and move
closer to work. If you do, you may be made redundant and have to repeat the
whole process over again for the next job you get... You are right to value
what you have.

(These days I tend to get a contract, then move as close as possible to
where it is. Doc's point is well taken about the expense of finding
accommodation in various major centres, but with contracting you can make
sure that this is covered, or try for a contract in a less expensive
location. For example, I lived and worked in London for a number of years,
but I wouldn't do so now (unless there were special weightings added to the
contract rate). Although it is a great city, the cost of living
(particularly acccommodation) makes it prohibitive. I agree with Doc's
figures on what you should spend on rent (not more than 33%, and probably
25% is reasonable) but I don't personally ever spend more than 15% on rent.
For the Auckland contract I managed to acquire a fully furnished serviced
apartment, with a view of the harbour and 5 minutes from the office, with
electricity and broadband connection thrown in, for around 8% of my gross.
Auckland is much cheaper to live than many major cities. However, one of
the things I have realised is that it isn't about the contract rate or the
cost of living, it is about how much you actually get for yourself, after
paying tax, expenses, and basics like food, clothing, etc. For example, the
cost of living in NZ (by world standards) is low, wages are reasonable, but
tax is high and the currency is weakening. I worked out that for every 2
days I work in Europe, I can save the equivalent of 5 days here... a
sobering thought when you have a limited working life ahead of you. :-) (I
should technically head back to Europe right now, but there is no way I will
forego a summer in my beloved Bay of Plenty, so it has to wait til March
:-))

Best wishes, Meneer, whatever happens... Give some thought to a possible
"Plan B", just in case :-) ; "Plan A" has rarely been found to work... :-))

Tot ziens!

Pete.



HeyBub

2006-08-21, 6:55 pm

MeneerKK wrote:
>
> I got an offer just a few ws ago. It was more money, and a car and
> and and.
> But, I now work at 10 minutes biking from home. So about half an hour
> of traveling a day. That will certainly have grown to about 3 hours a
> day.
> So, I have decided to stay. I only have to do some 12 years. Then only
> traveling half an hour a day is very luring.


You could scam the system.

Take the new job and move next door to the office.

I did. My commute time is measured, literally, in seconds. And I don't even
need the exertion of a bicycle.

The only downside is I don't get to fsck with the environmentalists by
driving a Hummer.


Alistair

2006-08-22, 7:55 am


docdwarf@panix.com wrote:
>
> I'm not sure how you are using 'works' here, Mr Maclean; there have been
> instances I have seen where the 'big bucks lure' has given the hiring firm
> insufficient time to get from the new hire a return on the necessary loss
> entailed in a new hire... so in addition to leaving a hole in coverage the
> company is unrecompensed for search, training and familiarisation costs.
>
> Holes in coverage *and* additional expenses... 'it works', indeed!
>
> DD


I agree with your point but, from a management perspective, the job is
perpetually filled. The only problem is the perpetual need to recruit
the next replacement costing, each time, the equivalent of three
months' salary in recruiting costs. Some management wallah will see
this, not as a problem with paying too little to retain an experienced
employee, but as a successful recruitment on each occasion.

I worked in a company where we had a 50% turnover in the IT department
every year. Management did not see a problem probably because they were
always able to recruit trainee replacements for experienced staff
leaving.

Alistair

2006-08-22, 7:55 am


HeyBub wrote:
> MeneerKK wrote:
> You could scam the system.
>
> Take the new job and move next door to the office.
>
> I did. My commute time is measured, literally, in seconds. And I don't even
> need the exertion of a bicycle.
>
> The only downside is I don't get to fsck with the environmentalists by
> driving a Hummer.


I can only speak for myself but I have always found that the nearer I
lived to my place of work, the harder I found it to get up in the
mornings (nothing to do with hangovers).

2006-08-22, 7:55 am

In article <1156242228.814048.220660@h48g2000cwc.googlegroups.com>,
Alistair <alistair@ld50macca.demon.co.uk> wrote:
>
>docdwarf@panix.com wrote:
>
>I agree with your point but, from a management perspective, the job is
>perpetually filled.


I *almost* agree, Mr Maclean... the *position* may have been perpetually
filled but the *job* might not have been getting done.

>The only problem is the perpetual need to recruit
>the next replacement costing, each time, the equivalent of three
>months' salary in recruiting costs. Some management wallah will see
>this, not as a problem with paying too little to retain an experienced
>employee, but as a successful recruitment on each occasion.


This way there be dragons, Mr Maclean, of the 'what we say versus what we
do' variety. The classic is 'We say we want to save money... but if we
save money our next-year's budget will be decreased and having a smaller
budget translates into less Corporate Status. We do not want less
Corporate Status so... we will find ways to spend money.'

>
>I worked in a company where we had a 50% turnover in the IT department
>every year. Management did not see a problem probably because they were
>always able to recruit trainee replacements for experienced staff
>leaving.


I have seen Management manifest a variety of what I would call 'strange
interpretations', Mr Maclean... and I've commented on what I see as my
capabilities for generating like ones.

DD

Bob Wolfe

2006-09-02, 6:55 pm

Jimmy:

Sorry for the late response.

Our printing product is called COBOL FormPrint and it does support
report, form and document printing in COBOL.



"James J. Gavan" <jgavandeletethis@shaw.ca> wrote:

>MeneerKK wrote:
>Not necessarily out of the race if you favour RM. I know we are talking
>about probably a fair number of reports. However even with RW you are
>producing a facsimile of printed lines in the Report Section - rather
>like the same thing done for display with the Screen Section. Then of
>course you INITIATE and GENERATE.
>
>Should you still favour RM, (and don't forget they have runtime fees
>too, but I'm not aware of costs), you could take a look at some of the
>separate tools for printing - where you pass a facsimile from COBOL to
>their files and they print from there. Take a look at :-
>
>http://www.sanface.com/txt2pdf.html
>
>Not suggesting you use it - but it is an option.
>
>They have also been indirectly mentioned here - Flexus.com and their
>product SP2. I don't know it personally, but it will handle Screen(text)
>or GUI displays, plus I'm fairly certain it also has a print feature.
>
>
>Jimmy



Bob Wolfe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~
When replying by e-mail, make sure that you correct the e-mail address.
Check out The Flexus COBOL Page at http://www.flexus.com

Bob Wolfe

2006-09-02, 6:55 pm

Jimmy:

You are 100% correct. COBOL sp2 can support Windows GUI screens and
character mode screens from a UNIX, UNIX derivative or Open VMS
platform.

With our Thin Client product, you can even support Windows GUI screens
on Windows client machines as well as character mode screens on
terminals from the same UNIX server. The application runs the GUI
screens in a client/server mode across TCP/IP.


"James J. Gavan" <jgavandeletethis@shaw.ca> wrote:

>MeneerKK wrote:
>
>I think you missed my point above - SP2 can be used with EITHER
>character-based screens, (I wrote 'screen(text)'), OR GUI, i.e.
>'Windows' - so the users' preference for character-based can be met.
>
>Jimmy



Bob Wolfe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~
When replying by e-mail, make sure that you correct the e-mail address.
Check out The Flexus COBOL Page at http://www.flexus.com

James J. Gavan

2006-09-02, 6:55 pm

Bob Wolfe wrote:
> Jimmy:
>
> Sorry for the late response.
>
> Our printing product is called COBOL FormPrint and it does support
> report, form and document printing in COBOL.
>
>

Bob,

Thanks for this and the other confirmation. Nice to hear from you again
after quite a bit of time.

Jimmy
Bob Wolfe

2006-09-08, 6:55 pm

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote:

>Bob Wolfe wrote:
>Bob,
>
>Thanks for this and the other confirmation. Nice to hear from you again
>after quite a bit of time.
>
>Jimmy


Jimmy:

I still lurk, but we're so busy that it's difficult to check in every
day. I try to check the postings at least once per w.

Thanks!


Bob Wolfe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~
When replying by e-mail, make sure that you correct the e-mail address.
Check out The Flexus COBOL Page at http://www.flexus.com

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com