Prev: "Hello World" OpenCobol query
Next: "Climategate" code
From: Pete Dashwood on 29 Nov 2009 05:25
William M. Klein wrote:
> Pete,
> I think we (sort-of) agree that the first decision that needs to be
> made is what is the intention of the migration:

Yes. Absolutely.

(In fact, I find myself in "general agreement" with your position; I'd just
like it to go further :-))
>
> - Is it to simply "move" tyheapplication ofgf the mainframe and keep
> it "as much like it was" as possible
> or
> - I the intent to move the application into "the modern world" so
> that it is easy to maintain eand enhance with "Windows" personael and
> resources.

I'm not sure it is as black-and-white as that, but, in principle, yes.
>
> There are< I think PROs and CONs for both and this decision "up
> front" will impact how such a migration should be made. It is my
> perceptions (and I could be right or wrong) that you don't see many
> (if any) PROs to doing a "rehosting" of a mainframe application to
> Windows - without ALSO doing a "migration" to "newer technology".

Yes, I think I said as much... :-)

However, I have stressed all along that this is an arguable personal
opinion. I have listened to opposing arguments from yourself and others and
I am sure that for some sites, this is valid and viable, particularly as a
"short term" measure that gets them off a particular platform. It's kind of
like a "Staging Post" that means they can keep what they have and "have a
look around" before making any drastic decisions. I understand the position,
I just don't agree with it.

The way I see this is that an opportunity is lost, and the overall migration
costs are increased.

That opinion is predicated on the belief that COBOL will not be viable (on
ANY platform...) into the long term future.

That means that migration is inevitable some time. (Unless you pack in your
IT or outsource it totally...)

There is therefore a golden opportunity to get rid of your indexed flat
files and procedural processing, and move into a world of objects and layers
that can be automatically generated as you migrate. If you DON'T do that
when you migrate it is harder (and more expensive) to do it later. (It is
still "doable" but it means repeating quite a bit of "stuff" you had to do
to get to the new platform, and that just seems wasteful to me.)

Unfortunately, most of the popular Migration efforts don't seem to be
concerned about what happens after you are on the new platform. They are
encouraging "same old same old" because their businesses are focused around
COBOL. It is a short term tactic, rather than a long term strategy.

For me, it isn't about perpetuating COBOL (my clients can stay with COBOL or
move to something else, or mix the two without problem; I really don't
care - I have no vested interest in what they use), it is about ensuring
that people moving to a new platform are able to lever the very best out of
that platform. That means objects and layers. This is a pretty hefty mindset
change for sites that have traditionally only used COBOL and time and
training are needed to make the necessary adjustments. BUT these adjustments
are worth it. (I know because I had to make them myself...)

Moving off the current platform is a golden opportunity to embrace the new
technology fully and open up non-COBOL options.

But that doesn't mean I think migrating to a new platform and NOT changing
is "wrong". :-)

It depends on the people, the circumstances, the size of the company, and
the corporate culture, just as much as on the technical and fiscal drivers.

Pete.
--
"I used to write COBOL...now I can do anything."


From: Howard Brazee on 30 Nov 2009 09:40
On Sun, 29 Nov 2009 23:25:24 +1300, "Pete Dashwood"
<dashwood(a)removethis.enternet.co.nz> wrote:

>There is therefore a golden opportunity to get rid of your indexed flat
>files and procedural processing, and move into a world of objects and layers
>that can be automatically generated as you migrate. If you DON'T do that
>when you migrate it is harder (and more expensive) to do it later. (It is
>still "doable" but it means repeating quite a bit of "stuff" you had to do
>to get to the new platform, and that just seems wasteful to me.)

We pretty much have already gotten rid of indexed flat files and
replaced them with the black boxes of databases. But it's just a
different degree of layering from what we had before without moving to
objects.

Still, when moving to a new system, as always (in my experience), we
find that not all of the old data quite fit the new business model. No
amount of encapsulating will make them fit right.

--
"In no part of the constitution is more wisdom to be found,
than in the clause which confides the question of war or peace
to the legislature, and not to the executive department."

- James Madison
From: Chuckles55 on 30 Nov 2009 16:25
Everyone,

Thanks very much for the comments !

I'll soon be having a discussion with management regarding the top one
or two options for transferring our organization's z/OS batch jobs to
something-else. Your comments, along with the results of investigation
into sister-organizations' experiences in COBOL-to-COBOL/C#/etc., will
help the management discussion.

Thanks again,
Chuck
From: Clark F Morris on 5 Dec 2009 22:46
On Tue, 24 Nov 2009 10:30:04 -0800 (PST), Chuckles55
<chuckmoore55(a)gmail.com> wrote:

>Hi Everyone,
>
>My organization wants to move its IBM z/OS COBOL programs off onto
>another (perceived-to-be cheaper) platform. One option being discussed
>is converting the (400+) programs (most of which do financial
>crunching to create print files) to run on Windows using either
>MicroFocus COBOL or Fujitsu NETCOBOL. There will be 2-4 programmers on
>the conversion team.
>My questions:
>1) Does anyone here have a preference between MicroFocus and Fujitsu ?
>2) If anyone has done conversions like this, how were DD statement
>(let alone IDCAMS) functionality converted ? (i.e. pass file
>descriptions in as XML ?, use ISAM on Windows ?)

Have the powers that be checked on the deal of the week from IBM to
see if they can reduce costs? Since RDz supports COBOL, there is the
possibility of moving into a development environment that might have
data dictionaries and repository support. The general management
mentality in all too many cases has been to actively ignore advances
made in the COBOL environment and z series operating systems. I have
serious doubts about the long term future of both COBOL and the z
series but in many cases management is not taking advantage of the
readily available tools (including Java) that are on the mainframe.
Reading about managements that refuse to upgrade from COBOL 74 makes
me wonder about their competence.
>
>Any further comments or suggestions would be appreciated,
>Chuck
From: Cláudio Miguel Müller on 7 Dec 2009 05:33
On Nov 27, 11:22 am, Cláudio Miguel Müller
<claudiomiguelmul...(a)gmail.com> wrote:
> On Nov 24, 3:30 pm, Chuckles55 <chuckmoor...(a)gmail.com> wrote:
>
>
>
> > Hi Everyone,
>
> > My organization wants to move its IBM z/OS COBOL programs off onto
> > another (perceived-to-be cheaper) platform. One option being discussed
> > is converting the (400+) programs (most of which do financial
> > crunching to create print files) to run on Windows using either
> > MicroFocus COBOL or Fujitsu NETCOBOL. There will be 2-4 programmers on
> > the conversion team.
> > My questions:
> > 1) Does anyone here have a preference between MicroFocus and Fujitsu ?
> > 2) If anyone has done conversions like this, how were DD statement
> > (let alone IDCAMS) functionality converted ? (i.e. pass file
> > descriptions in as XML ?, use ISAM on Windows ?)
>
> > Any further comments or suggestions would be appreciated,
> > Chuck
>
> Hello Chuck,
> I saw your message in this forum, I have a suggestion.
> See software FILES2SQL inwww.cobol.com.ar/files2sql,
> 100% Compatible with Microfocus Cobol.
> It makes file conversion to Cobol Databases. Very useful and
> practical.
> I hope that helps you to do this.
>
> Cláudio Muller
> Brazil


ERROR NOT FOUND 404
AT
Hello Chuck,
I saw your message in this forum, I have a suggestion.
See software FILES2SQL in www.cobol.com.ar/files2sql,
100% Compatible with Microfocus Cobol.
It makes file conversion to Cobol Databases. Very useful and
practical.
I hope that helps you to do this.
Cláudio Muller
Brazil
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: "Hello World" OpenCobol query
Next: "Climategate" code