Re: Somewhat Interesting Mainframe Article

[David Crayford]

On 15/10/2017 11:38 PM, Paul Gilmartin wrote:

  Many applications systems, including ones I

worked on needed to be redesigned and replaced.  It could have been
done in COBOL but getting management to buy into upgrading the way
they do things to at least the 1985 standard and its facilities let
alone anything later was too difficult.

Look at it this way though. As machines get faster and faster, there is little 
need to revamp (any) code. That is one of the issue now days. management is 
just to happy so they do not have to rewrite code they just get a bigger 
machine. Maybe that is the undoing of Z?


I see the author's point as quite the opposite:
 https://www.infoq.com/articles/retiring-mainframe-programmers

The processing power of the z is ample, as are its reliability, security, and
economy of operation.  But as companies merge and move into new lines
of business and areas of operation, as there are changes in tax laws,
environmental regulations, reporting requirements, and insurance laws;
as operations move to  Internet and cashless transactions, management
information systems changes are necessary.


You make a good point! I know from ex colleagues back in the UK that 
demand for COBOL programmers has increased significantly in the last 
couple of years due to changes in banking regulations which stipulate 
that retail and investment banking systems must be separated. That means 
cracking open the  legacy systems for significant modifications. Good 
for COBOL programmers not so good for the banks! Contract rates for 
COBOL programmers haven't been so good since Y2K!


One of our customers, the only "big bank" in town, have recently 
modernized their core banking CICS system to use Websphere Liberty 
Profile for the new REST API. They're very happy with the results so far 
but had to crack open the PL1 code to modularize it into "business 
units" to simplify the API. So you're quite right. Legacy code has to be 
changed quite often and that will be the case until they no longer 
exist. That may be a long way away.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Somewhat Interesting Mainframe Article

[David Crayford]

On 15/10/2017 10:22 PM, scott Ford wrote:

Ed,

I agree with you. Machines are faster and faster. But customers are demanding 
changes to code and fixes faster. This to me is a problem, especially if 
'caution is thrown to the wind'. Dealing with the security subsystem, I.e.; 
RACF, ACF2 and TOP-SECRET , many customers are ignorant of these products , 
especially in how and why they work.

I write in COBOL and my first love Assembler, so we have exits that support our 
product.
I have seen like everyone else a lot of craziness. The approach of using the PC 
and Java for everything to me is a cop out . This is the apparent trend I have 
been seeing. To this t-Rex this is not the only path to product development.



I don't fall in love with programming languages. I see them merely as 
tools which I'm happy to discard when a sharper one comes along.


As a vendor, I can't think of a single reason why I would choose to 
write code in COBOL. You could make the case for assembler for AR-mode 
stuff but Metal/C has removed those handcuffs. I can, however, think of 
many reasons why I would use Java. I can solve problems in Java that 
would be nigh-on impossible in COBOL and/or assembler. The best thing 
about the JVM is if you don't want to pay Java's verbosity tax you can 
choose Groovy, Kotlin, Scala etc and still have access to the gargantuan 
Java eco-system. Oh, and the code can run on a zIIP making it much 
cheaper to execute for your customers.



Scott

On Oct 15, 2017, 1:25 AM -0400, Edward Gould , wrote:

On Oct 14, 2017, at 8:50 PM, Clark Morris  wrote:


As a retired systems programmer and applications programmer analyst
whose primary languages were COBOL and Assembler, I have serious
doubts about that statistic. There have been many successful
migrations from the 360/370/390/z series systems. There also have
been many successful if overly expensive migrations to SAP, Oracle,
and the rest of the bunch. I would be amazed Facebook, Amazon, and
Microsoft have any z series or BUNCH successor mainframes. Take a
look at the job postings. Many applications systems, including ones I
worked on needed to be redesigned and replaced. It could have been
done in COBOL but getting management to buy into upgrading the way
they do things to at least the 1985 standard and its facilities let
alone anything later was too difficult.

Clark Morris

Clark:

Look at it this way though. As machines get faster and faster, there is little 
need to revamp (any) code. That is one of the issue now days. management is 
just to happy so they do not have to rewrite code they just get a bigger 
machine. Maybe that is the undoing of Z?

Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Somewhat Interesting Mainframe Article

[David Crayford]

But there must have been a lot of successful mainframe migrations 
otherwise the mainframe install base wouldn't have shrunk to where it is 
today. My wife has worked on a few mainframe to SAP migrations and they 
were all successful with very happy customers. Small applications 
though. I also know of big sites failing miserably and wasting hundreds 
of millions of dollars.


I think one thing is for sure and that's very few companies if any will 
choose the mainframe for green fields applications.



On 16/10/2017 12:59 AM, Bill Wilkie wrote:

After many years of  writing Assembler and Cobol on a mainframe, I have seen a 
lot of technologies rolled out with big promises. THEY ALL FAILED.

I remember one time there was a product that let you code logic tables that 
would generate code. Management billed it as the solution to long lead times 
for changes and orderly development. It screwed everything up and took a long 
to get rid of it and get things back to normal.

Then I worked for a vendor and had to attend change control  meetings. 
Management complained about how long it took to get changes in and looked for 
other alternatives yet kept adding more restrictions On changes in the 
mainframe group. While Open systems attended the same meeting and when they 
were asked, do you have a backup plan, they said what's that. Management 
thought that was fine because they could get stuff done.

But the biggest BOONDOGGLE of all times, was what management spent a few 
million on and that was Four Quadrant Leadership. If discussed something with 
another person and YOU made the change you were operating from Quadrant 1. If 
you discussed it with another persons and THEY did it you were operating from 
Quadrant 2. No one ever figured out whay it was important but everyone in the 
company had to take the course. We spent millions and the manager who bought it 
was called a VISIONARY. I suspect or should I say HOPE he is on the 
unemployment line with the rest of the visionaries.

From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of scott 
Ford <idfli...@gmail.com>
Sent: Sunday, October 15, 2017 2:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Somewhat Interesting Mainframe Article

Ed,

I agree with you. Machines are faster and faster. But customers are demanding 
changes to code and fixes faster. This to me is a problem, especially if 
'caution is thrown to the wind'. Dealing with the security subsystem, I.e.; 
RACF, ACF2 and TOP-SECRET , many customers are ignorant of these products , 
especially in how and why they work.

I write in COBOL and my first love Assembler, so we have exits that support our 
product.
I have seen like everyone else a lot of craziness. The approach of using the PC 
and Java for everything to me is a cop out . This is the apparent trend I have 
been seeing. To this t-Rex this is not the only path to product development.


Scott

On Oct 15, 2017, 1:25 AM -0400, Edward Gould <edgould1...@comcast.net>, wrote:

On Oct 14, 2017, at 8:50 PM, Clark Morris <cfmpub...@ns.sympatico.ca> wrote:


As a retired systems programmer and applications programmer analyst
whose primary languages were COBOL and Assembler, I have serious
doubts about that statistic. There have been many successful
migrations from the 360/370/390/z series systems. There also have
been many successful if overly expensive migrations to SAP, Oracle,
and the rest of the bunch. I would be amazed Facebook, Amazon, and
Microsoft have any z series or BUNCH successor mainframes. Take a
look at the job postings. Many applications systems, including ones I
worked on needed to be redesigned and replaced. It could have been
done in COBOL but getting management to buy into upgrading the way
they do things to at least the 1985 standard and its facilities let
alone anything later was too difficult.

Clark Morris

Clark:

Look at it this way though. As machines get faster and faster, there is little 
need to revamp (any) code. That is one of the issue now days. management is 
just to happy so they do not have to rewrite code they just get a bigger 
machine. Maybe that is the undoing of Z?

Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 

Re: Somewhat Interesting Mainframe Article

[Edward Gould]

> On Oct 15, 2017, at 9:22 AM, scott Ford  wrote:
> 
> Ed,
> 
> I agree with you. Machines are faster and faster. But customers are demanding 
> changes to code and fixes faster. This to me is a problem, especially if 
> 'caution is thrown to the wind'. Dealing with the security subsystem, I.e.; 
> RACF, ACF2 and TOP-SECRET , many customers are ignorant of these products , 
> especially in how and why they work.
> 
> I write in COBOL and my first love Assembler, so we have exits that support 
> our product.
> I have seen like everyone else a lot of craziness. The approach of using the 
> PC and Java for everything to me is a cop out . This is the apparent trend I 
> have been seeing. To this t-Rex this is not the only path to product 
> development.
> 
> 
> Scott


Scott,

I do not know what part you play in your products life cycle. Let us say you 
want to have your program do something unusual like say make a call to vendor B 
to get results. Now all of a sudden you have to ship Vendor B’s product with 
yours. I will guarantee they will not give it to you for free. Now your product 
ships with Vendor’s B product. Your cost *HAVE* to go up, so how do you handle 
it, add 2.00 to the monthly fee? I don’t think so, there are things like 
contract and that means getting lawyers involved etc etc.. Now not only do you 
have two worry about fixes to your product you have to figure out how to 
include fixes from Vendor B as well. 

It gets a lot more complicated as you add on other vendors and pretty soon you 
will be twisted up in release issues and it will drive your company to 
bankruptsy.

Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Somewhat Interesting Mainframe Article

[Edward Gould]

Gil:

> On Oct 15, 2017, at 10:38 AM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> The processing power of the z is ample, as are its reliability, security, and
> economy of operation.  But as companies merge and move into new lines
> of business and areas of operation, as there are changes in tax laws,
> environmental regulations, reporting requirements, and insurance laws;
> as operations move to  Internet and cashless transactions, management
> information systems changes are necessary.
> 
> The technology of coding with "glass keypunches" and change management
> by 8-digit line numbers is insufficient to the task.  And attrition of 
> programming
> talent adds to the need for new techniques.
I do not disagree with you however, take a look (for example) a payroll system.
When I looked at it, every quarter (or so) the tables had to be updated. You 
will not see anything different in a new payroll system. Tax laws change and so 
does the new program.
Outside of somehow doing a query of a remote system to get new tax tables, the 
principal is the same. I sure would not want something like my payroll system 
going out side my company to do an inquiry. That is asking for a lawsuit plain 
and simple. If it is done in house you have a greater chance of getting it 
right than a remote system, plus you have to depend on the remote system not 
being hacked and a few other security issues. You also cannot tell a customer 
that he can’t get checks because of an issue that is not under your control. 
You will loose a customer and get sued.
When you have programs that do basic things there is not a need for the new and 
shiny thing, just to have it, you have to justify it and most managers I have 
worked with don’t like to hear new and shiny.

Ed




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Somewhat Interesting Mainframe Article

[Anne & Lynn Wheeler]

billwil...@hotmail.com (Bill Wilkie) writes:
> But the biggest BOONDOGGLE of all times, was what management spent a
> few million on and that was Four Quadrant Leadership. If discussed
> something with another person and YOU made the change you were
> operating from Quadrant 1. If you discussed it with another persons
> and THEY did it you were operating from Quadrant 2. No one ever
> figured out whay it was important but everyone in the company had to
> take the course. We spent millions and the manager who bought it was
> called a VISIONARY. I suspect or should I say HOPE he is on the
> unemployment line with the rest of the visionaries.

mid-80s, top IBM executives were predicting that corporate revenue would
double mostly based on mainframe business ... and there was massive
internal bldg program to double mainframe manufacturing capacity.

however, a couple years later, a senior disk engineer got a talk
scheduled at the internal, world-wide communication group conference
supposedly on 3174 performance, but opened the talk with statement that
the communication group was going to be responsible for the demise of
the disk division. The issue was that the communication group had
stanglehold on datacenter with their corporate strategic responsibility
for everything that crossed the datacenter walls and were fiercely
fighting distributed computing and client/server trying to preserve
their dumb terminal paradigm and install base. The disk division was
seeing data fleeing the datacenter to more distributed computing
friendly platforms with drop in disk sales. They had come up with
several solutions which were constantly vetoed by the communication
group.

The communication group stranglehold on the datacenter not only was
affecting disk sales but everything mainframe and a few short years
later the company goes into the red.

By the mid-90s, most of the easier applications had fled mainframes
(driving IBM into the red) and the major remaining customer was the
financial industry (accounting for significant percentage of all new
mainframe sales). However, the financial industry was facing significant
bottleneck with decades old legacy cobol financial software that did
settlement in the overnight batch window ... and globalization
(shortening the window) and business increases (increasing workload) was
putting extreme strain on the overnight batch window.

Late 90s, there was a period where the financial industry spends
billions of dollars on new software to support parallized "straight
through processing" (real-time settlement with every transaction),
planning on using large numbers of killer micros. However there were
using some industry standard parallelization libraries ...  and they
continued down the path even when repeatedly told (including by me) the
libraries introduced factor of 100 times overhead (compared to mainframe
batch cobol).  It wasn't until they actually had some major large pilots
go down in flames that they pulled back (100 times overhead totally
swamped anticipated throughput increases from large numbers of
parallelized killer micros).

A decade later, I was involved in effort that approached it from a
different standpoint. It supported high level business rules that
generated fine-grain, parallelizable SQL statements, and rather than
directly implementing parallelization ... it relied on the enormous work
that all the RDBMS vendors (including IBM) put into scalable cluster
parallelized throughput. Prototype pilots were implemented for different
financial sectors that easily supported several times their current peak
workloads on non-mainframe cluster RDBMS platforms. This was presented
to several financial industry groups and initially had high acceptance
... but then hit brick wall. They eventually said that the top
executives still bore significant scars from the failed efforts in the
late 90s and it would be a very long time before it would be tried
again.

Note that SQL/RDBMS features are common across mainframe and
non-mainframe platforms ... all platforms use industry standard
fixed-block disks, non-mainframes getting slightly better throughput
than mainframe doing CKD simulation on same industry standard disks
(real CKD disks haven't been made for decades). Native fibre-channel
having significantly higher native throughput than mainframe FICON
protocol running over the same fibre-channel.

The most recent published mainframe peak I/O throughput that I've found
is z196 getting 2M IOPS using 104 FICON. About the same time there was
fibre channel announced for E5-2600V1 blade claiming over million IOPS
(for single fibre-channel, two such fibre-channel having higher native
throughput than 104 FICON running over 104 fibre-channel).

max configured z196->z14 went from 80 @625MIPS for 50BIPS to 170
@882MIPS for 150BIPS (three times aggregate processing with more than
double the number of slightly faster processors).

In the same time frame, two chip e5-2600V1 blade at 530BIPS went to 

Re: Somewhat Interesting Mainframe Article

[Edward Gould]

> On Oct 15, 2017, at 9:22 AM, scott Ford  wrote:
> 
> Ed,
> 
> I agree with you. Machines are faster and faster. But customers are demanding 
> changes to code and fixes faster. This to me is a problem, especially if 
> 'caution is thrown to the wind'. Dealing with the security subsystem, I.e.; 
> RACF, ACF2 and TOP-SECRET , many customers are ignorant of these products , 
> especially in how and why they work.
> 
> I write in COBOL and my first love Assembler, so we have exits that support 
> our product.
> I have seen like everyone else a lot of craziness. The approach of using the 
> PC and Java for everything to me is a cop out . This is the apparent trend I 
> have been seeing. To this t-Rex this is not the only path to product 
> development.
> 
> 
> Scott

Scott:

Not only are machines faster the OS is in some aspects faster and faster.
Just to give one example. We were one of the bloody early adopters of MVS.
1. Our two biggest issues were applications and how to speed them up.
2. Trying to account for the application code (who to charge)
2.5 Trying to keep MVS up long enough to get some production done (we had 
typically 6-12 IPL’s a week)

Early on our SE (who functioned more of a high-level sysprog than an IBMer) 
discovered one of the big bottle necks was I/O. He wrote an orange book on it, 
and it was an eye-opener. One of the things he showed in the orange book was 
that when you add buffers to pretty much any QSAM file. The application would 
run faster. Thus was born SAMe (or was it samE). Approximately one year after 
the book was published IBM announce SAM-E. Since he helped write the code we 
were first (or close to) adapters. It worked miracles our run times decreased 
dramatically. Its been 30++ years so I don’t have the numbers in my head. But, 
for a $60 a month product it was a godsend.

We had a three different groups that used our data center. The thought 
originally for the three of them to split the cost. After 5 or so years that 
wasn’t proving feasible, but we were damned to figure out who was getting the 
most. Out of the clear blue a box, about 1/2 the size of a 3830 controller 
showed up in the computer room. We had no idea what it was for; it turned out 
to be a solid-state drive for paging. We didn’t know who ordered it. The VP 
came down and announced he had (without telling or asking anyone). We looked at 
each other and said, but  it wasn’t big enough for our paging volumes. But we 
had to show that we were a team and we decided to put PLPA on it. SO the after 
it was hooked up to a couple of channels and put it online, meanwhile several 
thousand people were doing data entry work, and we were expecting the system to 
crash. It didn’t so I went ahead and defined a VTOC and a PLPA on it. The next 
Sunday it was going live, and we crossed our fingers. Sunday went by and then 
Monday, then Tuesday we had a power glitch, and of course, the system crashed. 
When we tried to IPL, we couldn’t because the idiots who designed the box never 
dreamed of a power outage and we had to define a PLPA someplace else and IPL 
again to use the primary PLPA. The damn box lost the VTOC and the PLPA. So I 
scuttled around and did that and set it up in parmlib who when we IPL’d it 
would automatically come up and use it. Then we had another power glitch. This 
time it remembered the VTOC but not PLPA. So here we go again. It took five 
outages before we crated the damn product up and shipped it out.

A year later another one of those mysterious boxes showed up. The VP came down 
with another person who turned out to be the salesman. The salesman was heard 
to say that he would guarantee this “baby” would find out why we couldn’t 
account for about 25-30 percent of the machine. The next day the tech person 
from the manufacturer showed up and started to open the box. There was nothing 
special about the box other than it had a few gauges on the front and what 
looked like a mini tape drive on the front. As he was unpacking, I asked 
exactly what the machine did, and he started going off on a sales routine. I 
cut him off after a few minutes and said how exactly it was to work. He pushed 
me off on a few more sales type answers. He started to bring long wires out, 
and I told him to stay away from the console, and he continued stringing more 
and more wire out. He motioned to go closer to the console, and I said you are 
not going to touch that machine. We have several thousand people working and 
cannot take any outages. He assured me that he wasn’t going to do anything that 
would bring down the system. I finally told him to STOP, and I reached for the 
phone for the VP. He said OK, when can I hook this up. I said we would have to 
talk with the shift supervisor as I do not know the schedule for the building 
and our connections in Europe and the east coast and west coast. We went over 
to him and asked when the next open slot was where we could have the machine 
for 

Re: Somewhat Interesting Mainframe Article

[Bill Wilkie]

After many years of  writing Assembler and Cobol on a mainframe, I have seen a 
lot of technologies rolled out with big promises. THEY ALL FAILED.

I remember one time there was a product that let you code logic tables that 
would generate code. Management billed it as the solution to long lead times 
for changes and orderly development. It screwed everything up and took a long 
to get rid of it and get things back to normal.

Then I worked for a vendor and had to attend change control  meetings. 
Management complained about how long it took to get changes in and looked for 
other alternatives yet kept adding more restrictions On changes in the 
mainframe group. While Open systems attended the same meeting and when they 
were asked, do you have a backup plan, they said what's that. Management 
thought that was fine because they could get stuff done.

But the biggest BOONDOGGLE of all times, was what management spent a few 
million on and that was Four Quadrant Leadership. If discussed something with 
another person and YOU made the change you were operating from Quadrant 1. If 
you discussed it with another persons and THEY did it you were operating from 
Quadrant 2. No one ever figured out whay it was important but everyone in the 
company had to take the course. We spent millions and the manager who bought it 
was called a VISIONARY. I suspect or should I say HOPE he is on the 
unemployment line with the rest of the visionaries.

From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
scott Ford <idfli...@gmail.com>
Sent: Sunday, October 15, 2017 2:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Somewhat Interesting Mainframe Article

Ed,

I agree with you. Machines are faster and faster. But customers are demanding 
changes to code and fixes faster. This to me is a problem, especially if 
'caution is thrown to the wind'. Dealing with the security subsystem, I.e.; 
RACF, ACF2 and TOP-SECRET , many customers are ignorant of these products , 
especially in how and why they work.

I write in COBOL and my first love Assembler, so we have exits that support our 
product.
I have seen like everyone else a lot of craziness. The approach of using the PC 
and Java for everything to me is a cop out . This is the apparent trend I have 
been seeing. To this t-Rex this is not the only path to product development.


Scott

On Oct 15, 2017, 1:25 AM -0400, Edward Gould <edgould1...@comcast.net>, wrote:
> > On Oct 14, 2017, at 8:50 PM, Clark Morris <cfmpub...@ns.sympatico.ca> wrote:
> >
> >
> > As a retired systems programmer and applications programmer analyst
> > whose primary languages were COBOL and Assembler, I have serious
> > doubts about that statistic. There have been many successful
> > migrations from the 360/370/390/z series systems. There also have
> > been many successful if overly expensive migrations to SAP, Oracle,
> > and the rest of the bunch. I would be amazed Facebook, Amazon, and
> > Microsoft have any z series or BUNCH successor mainframes. Take a
> > look at the job postings. Many applications systems, including ones I
> > worked on needed to be redesigned and replaced. It could have been
> > done in COBOL but getting management to buy into upgrading the way
> > they do things to at least the 1985 standard and its facilities let
> > alone anything later was too difficult.
> >
> > Clark Morris
>
> Clark:
>
> Look at it this way though. As machines get faster and faster, there is 
> little need to revamp (any) code. That is one of the issue now days. 
> management is just to happy so they do not have to rewrite code they just get 
> a bigger machine. Maybe that is the undoing of Z?
>
> Ed
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Somewhat Interesting Mainframe Article

[Paul Gilmartin]

On Sun, 15 Oct 2017 00:25:06 -0500, Edward Gould wrote:

>> On Oct 14, 2017, at 8:50 PM, Clark Morris wrote:
>> 
 Many applications systems, including ones I
>> worked on needed to be redesigned and replaced.  It could have been
>> done in COBOL but getting management to buy into upgrading the way
>> they do things to at least the 1985 standard and its facilities let
>> alone anything later was too difficult.
>
>Look at it this way though. As machines get faster and faster, there is little 
>need to revamp (any) code. That is one of the issue now days. management is 
>just to happy so they do not have to rewrite code they just get a bigger 
>machine. Maybe that is the undoing of Z?
>
I see the author's point as quite the opposite:
https://www.infoq.com/articles/retiring-mainframe-programmers

The processing power of the z is ample, as are its reliability, security, and
economy of operation.  But as companies merge and move into new lines
of business and areas of operation, as there are changes in tax laws,
environmental regulations, reporting requirements, and insurance laws;
as operations move to  Internet and cashless transactions, management
information systems changes are necessary.

The technology of coding with "glass keypunches" and change management
by 8-digit line numbers is insufficient to the task.  And attrition of 
programming
talent adds to the need for new techniques.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Somewhat Interesting Mainframe Article

[scott Ford]

Ed,

I agree with you. Machines are faster and faster. But customers are demanding 
changes to code and fixes faster. This to me is a problem, especially if 
'caution is thrown to the wind'. Dealing with the security subsystem, I.e.; 
RACF, ACF2 and TOP-SECRET , many customers are ignorant of these products , 
especially in how and why they work.

I write in COBOL and my first love Assembler, so we have exits that support our 
product.
I have seen like everyone else a lot of craziness. The approach of using the PC 
and Java for everything to me is a cop out . This is the apparent trend I have 
been seeing. To this t-Rex this is not the only path to product development.


Scott

On Oct 15, 2017, 1:25 AM -0400, Edward Gould , wrote:
> > On Oct 14, 2017, at 8:50 PM, Clark Morris  wrote:
> >
> >
> > As a retired systems programmer and applications programmer analyst
> > whose primary languages were COBOL and Assembler, I have serious
> > doubts about that statistic. There have been many successful
> > migrations from the 360/370/390/z series systems. There also have
> > been many successful if overly expensive migrations to SAP, Oracle,
> > and the rest of the bunch. I would be amazed Facebook, Amazon, and
> > Microsoft have any z series or BUNCH successor mainframes. Take a
> > look at the job postings. Many applications systems, including ones I
> > worked on needed to be redesigned and replaced. It could have been
> > done in COBOL but getting management to buy into upgrading the way
> > they do things to at least the 1985 standard and its facilities let
> > alone anything later was too difficult.
> >
> > Clark Morris
>
> Clark:
>
> Look at it this way though. As machines get faster and faster, there is 
> little need to revamp (any) code. That is one of the issue now days. 
> management is just to happy so they do not have to rewrite code they just get 
> a bigger machine. Maybe that is the undoing of Z?
>
> Ed
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Somewhat Interesting Mainframe Article

[Edward Gould]

> On Oct 14, 2017, at 8:50 PM, Clark Morris  wrote:
> 
> 
> As a retired systems programmer and applications programmer analyst
> whose primary languages were COBOL and Assembler,  I have serious
> doubts about that statistic.  There have been many successful
> migrations from the 360/370/390/z series systems.  There also have
> been many successful if overly expensive migrations to SAP, Oracle,
> and the rest of the bunch.   I would be amazed Facebook, Amazon, and
> Microsoft have any z series or  BUNCH successor mainframes.  Take a
> look at the job postings.  Many applications systems, including ones I
> worked on needed to be redesigned and replaced.  It could have been
> done in COBOL but getting management to buy into upgrading the way
> they do things to at least the 1985 standard and its facilities let
> alone anything later was too difficult.
> 
> Clark Morris 

Clark:

Look at it this way though. As machines get faster and faster, there is little 
need to revamp (any) code. That is one of the issue now days. management is 
just to happy so they do not have to rewrite code they just get a bigger 
machine. Maybe that is the undoing of Z?

Ed
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Somewhat Interesting Mainframe Article

[Clark Morris]

[Default] On 14 Oct 2017 15:39:09 -0700, in bit.listserv.ibm-main
st...@stevebeaver.com (Steve Beaver) wrote:

>There are 15 trillion lines of COBOL   

As a retired systems programmer and applications programmer analyst
whose primary languages were COBOL and Assembler,  I have serious
doubts about that statistic.  There have been many successful
migrations from the 360/370/390/z series systems.  There also have
been many successful if overly expensive migrations to SAP, Oracle,
and the rest of the bunch.   I would be amazed Facebook, Amazon, and
Microsoft have any z series or  BUNCH successor mainframes.  Take a
look at the job postings.  Many applications systems, including ones I
worked on needed to be redesigned and replaced.  It could have been
done in COBOL but getting management to buy into upgrading the way
they do things to at least the 1985 standard and its facilities let
alone anything later was too difficult.

Clark Morris 
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of scott Ford
>Sent: Saturday, October 14, 2017 4:00 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Somewhat Interesting Mainframe Article
>
>Tom,
>
>I have people who think pcs can do everything. They don't consider what a z/OS 
>system can do.
>Many of us yes I am in this group, I am 67 ..the word expiring is a bit odd.
>
>Scott
>
>On Oct 14, 2017, 3:35 PM -0400, Tom Brennan <t...@tombrennansoftware.com>, 
>wrote:
>> Very good article, but I wish he would stop using the term "expiring".
>>
>> I agree with most everything except for COBOL modularization. Instead, 
>> I think good (re)documentation can solve many source code issues 
>> without the risk of changing things you know very little about.
>>
>> esst...@juno.com wrote:
>> > https://www.infoq.com/articles/retiring-mainframe-programmers
>> >
>> > 
>> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
>> > send email to lists...@listserv.ua.edu with the message: INFO 
>> > IBM-MAIN
>> >
>> >
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send 
>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
>lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Somewhat Interesting Mainframe Article

[Paul Gilmartin]

On Sat, 14 Oct 2017 17:40:19 -0500, Steve Beaver wrote:

>There are 15 trillion lines of COBOL   
> 
That's a couple thousand lines of COBOL for every human being on earth.
Sounds high.  How does it factor?  How many programmers wrote an
average of how many lines each?  Do you count lines generated by translators
that cascade through COBOL?  And obsolete lines disabled as comments but
retained for historical value?  Or archived versions no longer in use?

Cite?

>> essteam wrote:
>> > https://www.infoq.com/articles/retiring-mainframe-programmers

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Somewhat Interesting Mainframe Article

[Steve Beaver]

There are 15 trillion lines of COBOL   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Saturday, October 14, 2017 4:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Somewhat Interesting Mainframe Article

Tom,

I have people who think pcs can do everything. They don't consider what a z/OS 
system can do.
Many of us yes I am in this group, I am 67 ..the word expiring is a bit odd.

Scott

On Oct 14, 2017, 3:35 PM -0400, Tom Brennan <t...@tombrennansoftware.com>, 
wrote:
> Very good article, but I wish he would stop using the term "expiring".
>
> I agree with most everything except for COBOL modularization. Instead, 
> I think good (re)documentation can solve many source code issues 
> without the risk of changing things you know very little about.
>
> esst...@juno.com wrote:
> > https://www.infoq.com/articles/retiring-mainframe-programmers
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send email to lists...@listserv.ua.edu with the message: INFO 
> > IBM-MAIN
> >
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Somewhat Interesting Mainframe Article

[scott Ford]

Tom,

I have people who think pcs can do everything. They don't consider what a z/OS 
system can do.
Many of us yes I am in this group, I am 67 ..the word expiring is a bit odd.

Scott

On Oct 14, 2017, 3:35 PM -0400, Tom Brennan , 
wrote:
> Very good article, but I wish he would stop using the term "expiring".
>
> I agree with most everything except for COBOL modularization. Instead,
> I think good (re)documentation can solve many source code issues without
> the risk of changing things you know very little about.
>
> esst...@juno.com wrote:
> > https://www.infoq.com/articles/retiring-mainframe-programmers
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Somewhat Interesting Mainframe Article

[Tom Brennan]

Very good article, but I wish he would stop using the term "expiring".

I agree with most everything except for COBOL modularization.  Instead, 
I think good (re)documentation can solve many source code issues without 
the risk of changing things you know very little about.


esst...@juno.com wrote:

https://www.infoq.com/articles/retiring-mainframe-programmers

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Somewhat Interesting Mainframe Article

[esst...@juno.com]

https://www.infoq.com/articles/retiring-mainframe-programmers

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN