Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Anne & Lynn Wheeler]

frank.swarbr...@outlook.com (Frank Swarbrick) writes:
> Here's a somewhat interesting document: 
> https://www.irs.gov/pub/irs-pia/imf_pia.pdf.
> "IMF is a batch driven application that uses VSAM files."
> Date of Approval: February 28, 2017 PIA ID Number: 2140 A 
> ...
> Date of Approval: February 28, 2017 PIA ID Number: 2140 A. SYSTEM
> DESCRIPTION 1. Enter the full name and acronym for the system,
> project, application and/or database.
> www.irs.gov

re:
http://www.garlic.com/~lynn/2018c.html#57 The IRS Really Needs Some New 
Computers
http://www.garlic.com/~lynn/2018c.html#62 The IRS Really Needs Some New 
Computers

trivia: around turn of century, I was co-author of financial industry
x9.99 (privacy impact assessment, PIA) standard, along with somebody
that had previously worked at treasury. current version
https://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.99%3A2009+(Identical+to+ISO+22307-2008)

Work included meetings with several different federal agency privacy
officers ... including IRS.  Also talked to the people behind HIPAA
https://www.hhs.gov/hipaa/for-professionals/privacy/index.html

old reference to voting to approve NWI (new work item) for x9.99 (April
1999)
http://www.garlic.com/~lynn/aepay3.htm#aadsnwi

reference to standard available (April 2004, 5yrs later)
http://www.garlic.com/~lynn/aadsm17.htm#45

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[David Crayford]

On 23/04/2018 9:29 PM, Seymour J Metz wrote:

Isn't a class with no methods essentially a record type? Although that still 
leaves the issue of reading and writing them.


Nope. There's no such thing as a Java class with no methods because all 
classes are sub-classes of the Object root class [1] and inherit all 
it's methods such as toString, hashCode et al.


[1] https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html




--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of David 
Crayford 
Sent: Monday, April 23, 2018 4:45 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com)

C++ doesn't have garbage collection. Resource finalization is
deterministic and performed by a destructor. Also, C++ has POD structs
that map data in the same way as assembler, C, COBOL, PL/1 and access
record based data sources in exactly the same way.

Java doesn't have records and does not support value types (like C#) so
you can't define a class with fixed sized buffers on the stack. To map a
record from a legacy data source you have to use a byte array and
manipulate it using a class like a ByteBuffer.
This is mostly done using code generation tools to serialize the data
into the corresponding Java types. Of course, there is a lot of overhead
in doing so but that's why IBM have provided zIIP processors. If it
wasn't for zIIPs Java would not be
viable on z/OS. IBM have done a lot of work on the hardware stack to
make Java more efficient. The z114 has a new facility to help implement
pauseless garbage collection.

The z/OS JVM is highly optimized for heap memory management and
efficient use of cache lines. It provides excellent features for
concurrent programming and provides collection libraries for concurrent
data structures using lock-free/wait-free
algorithms. For example, ConcurrentHashMap can make use of transactional
memory to serialize access
The string class uses the new SIMD instructions for search/replace
methods. Once the JIT compiler has warmed up it will inline the hot
spots to improve code locality and mitigate instruction caches misses.

The most important thing to bear in mind is that replacing a legacy
application written in assembler with Java is madness and doomed to
failure. IMO, Java should be used only for new applications or
modernizing and existing legacy application.


On 23/04/2018 6:29 AM, Hobart Spitz wrote:

Somewhere, maybe in a different branch of this topic, there was a
discussion about the pros and cons of replacing Assembler with Java.  I
apologize for posting here if it's the wrong place, but I can't seem to
find the original discussion, and I have a question that seems relevant and
important, IMHO.

That's said, I can answer the question, for C/C++, as follows.  (I pose the
question for Java, below.)

*With the *nix/C record and string models, there are these issues:*

 1. Errant/unexpected/unintended pieces of binary data in a text
 file/string can break something.
 2. Separate functions/methods/techniques must be used to manipulate text
 files/strings versus binary files/string. You *must* know what you are
 dealing with up front, and/or somehow code logic for both. (I'm not sure
 the latter is possible in the general case.)
 3. Even with *nix/C oriented machine instructions, the need to inspect
 all characters up to a target point results in performance killing cache
 flooding.
 4. C++ does garbage collection resulting in "pauses" in forward
 progress, and working set, caching, and CPU spikes, among other things.

Let's call these attributes fragility, productivity, and efficiency,
respectively, for the convenience convenience.  C has issue with these
characteristics.

As most of the readers here know, mainframe style records and strings do
not suffer from these limitation.  When the length of a string/record is
known external to the data contents, you can manipulate any platform-native
data in z/OS, z/VM without it breaking due to something in the data, you
write the same code regardless of what you are dealing with, and, less
obviously, any activity that skips a cache can avoid a cache line promotion
saving processor resources.

So, my "burning" question for Java is, which, if any, of these above issues
(data fragility, coding productivity, efficiency, and garbage collections)
does Java share with C/C++.

If Java suffers from all or most of the issues, then I would say replacing
Assembler with Java is pretty much out of the question.  On the other hand,
if Java suffers few or none of the above issues, it might be viable to
replace Assembler with Java (ignoring other issues, like cost, testing,
compatibility, data porting, etc.)

To sum up:  Does Java use a similar record/string model to that of C/C++,
and does it do 

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[David Crayford]

On 23/04/2018 9:23 PM, Jerry Callen wrote:

C and C++ do NOT have garbage collection; memory management is controlled by 
the programmer, with C++ providing a lot of assistance in the form of 
constructors and destructors.

String manipulation can be done in a variety of ways; C++, in particular, 
provides counted strings and byte arrays with no restrictions on content.


FWIW, while we impoverished souls on z/OS still use std::string with a 
COW implementation the C++11 standard forbids it. It turns out in 
multi-threaded applications the locking overhead was higher than copying 
[1].
I'm doing a lot of Java work right now and I can see the merits of the 
immutable Java string class with all the nice benefits like interning.


[1] https://shaharmike.com/cpp/std-string/



I've programmed in assembler, PL/I, COBOL and C/C++. If you are dealing with 
COBOL records that make extensive use of OCCURS DEPENDING ON, it probably make 
sense to stick with COBOL. Otherwise, it's quite easy to write robust, 
efficient code in C and C++ on z/OS.


Indeed. IMO, the more strongly typed the language the more robust it is. 
Assembler, COBOL, C et al don't fit into that category.


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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[David Crayford]

On 23/04/2018 10:05 PM, Charles Mills wrote:

The z114 has a new facility to help implement pauseless garbage collection.

Note "pause less" garbage collection -- less pausing than previous implementations. Not 
pauseless as in "no pausing."


Indeed. Thanks for the correction!


Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Monday, April 23, 2018 1:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com)

C++ doesn't have garbage collection. Resource finalization is
deterministic and performed by a destructor. Also, C++ has POD structs
that map data in the same way as assembler, C, COBOL, PL/1 and access
record based data sources in exactly the same way.

Java doesn't have records and does not support value types (like C#) so
you can't define a class with fixed sized buffers on the stack. To map a
record from a legacy data source you have to use a byte array and
manipulate it using a class like a ByteBuffer.
This is mostly done using code generation tools to serialize the data
into the corresponding Java types. Of course, there is a lot of overhead
in doing so but that's why IBM have provided zIIP processors. If it
wasn't for zIIPs Java would not be
viable on z/OS. IBM have done a lot of work on the hardware stack to
make Java more efficient. The z114 has a new facility to help implement
pauseless garbage collection.

The z/OS JVM is highly optimized for heap memory management and
efficient use of cache lines. It provides excellent features for
concurrent programming and provides collection libraries for concurrent
data structures using lock-free/wait-free
algorithms. For example, ConcurrentHashMap can make use of transactional
memory to serialize access
The string class uses the new SIMD instructions for search/replace
methods. Once the JIT compiler has warmed up it will inline the hot
spots to improve code locality and mitigate instruction caches misses.

The most important thing to bear in mind is that replacing a legacy
application written in assembler with Java is madness and doomed to
failure. IMO, Java should be used only for new applications or
modernizing and existing legacy application.


On 23/04/2018 6:29 AM, Hobart Spitz wrote:

Somewhere, maybe in a different branch of this topic, there was a
discussion about the pros and cons of replacing Assembler with Java.  I
apologize for posting here if it's the wrong place, but I can't seem to
find the original discussion, and I have a question that seems relevant and
important, IMHO.

That's said, I can answer the question, for C/C++, as follows.  (I pose the
question for Java, below.)

*With the *nix/C record and string models, there are these issues:*

 1. Errant/unexpected/unintended pieces of binary data in a text
 file/string can break something.
 2. Separate functions/methods/techniques must be used to manipulate text
 files/strings versus binary files/string. You *must* know what you are
 dealing with up front, and/or somehow code logic for both. (I'm not sure
 the latter is possible in the general case.)
 3. Even with *nix/C oriented machine instructions, the need to inspect
 all characters up to a target point results in performance killing cache
 flooding.
 4. C++ does garbage collection resulting in "pauses" in forward
 progress, and working set, caching, and CPU spikes, among other things.

Let's call these attributes fragility, productivity, and efficiency,
respectively, for the convenience convenience.  C has issue with these
characteristics.

As most of the readers here know, mainframe style records and strings do
not suffer from these limitation.  When the length of a string/record is
known external to the data contents, you can manipulate any platform-native
data in z/OS, z/VM without it breaking due to something in the data, you
write the same code regardless of what you are dealing with, and, less
obviously, any activity that skips a cache can avoid a cache line promotion
saving processor resources.

So, my "burning" question for Java is, which, if any, of these above issues
(data fragility, coding productivity, efficiency, and garbage collections)
does Java share with C/C++.

If Java suffers from all or most of the issues, then I would say replacing
Assembler with Java is pretty much out of the question.  On the other hand,
if Java suffers few or none of the above issues, it might be viable to
replace Assembler with Java (ignoring other issues, like cost, testing,
compatibility, data porting, etc.)

To sum up:  Does Java use a similar record/string model to that of C/C++,
and does it do garbage collection similarly.

Thanks in advance for satisfying my curiosity.











OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Sat, Apr 21, 2018 at 12:29 PM, Barry Merrill 

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Charles Mills]

> The z114 has a new facility to help implement pauseless garbage collection.

Note "pause less" garbage collection -- less pausing than previous 
implementations. Not pauseless as in "no pausing."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Monday, April 23, 2018 1:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com)

C++ doesn't have garbage collection. Resource finalization is 
deterministic and performed by a destructor. Also, C++ has POD structs 
that map data in the same way as assembler, C, COBOL, PL/1 and access 
record based data sources in exactly the same way.

Java doesn't have records and does not support value types (like C#) so 
you can't define a class with fixed sized buffers on the stack. To map a 
record from a legacy data source you have to use a byte array and 
manipulate it using a class like a ByteBuffer.
This is mostly done using code generation tools to serialize the data 
into the corresponding Java types. Of course, there is a lot of overhead 
in doing so but that's why IBM have provided zIIP processors. If it 
wasn't for zIIPs Java would not be
viable on z/OS. IBM have done a lot of work on the hardware stack to 
make Java more efficient. The z114 has a new facility to help implement 
pauseless garbage collection.

The z/OS JVM is highly optimized for heap memory management and 
efficient use of cache lines. It provides excellent features for 
concurrent programming and provides collection libraries for concurrent 
data structures using lock-free/wait-free
algorithms. For example, ConcurrentHashMap can make use of transactional 
memory to serialize access
The string class uses the new SIMD instructions for search/replace 
methods. Once the JIT compiler has warmed up it will inline the hot 
spots to improve code locality and mitigate instruction caches misses.

The most important thing to bear in mind is that replacing a legacy 
application written in assembler with Java is madness and doomed to 
failure. IMO, Java should be used only for new applications or 
modernizing and existing legacy application.


On 23/04/2018 6:29 AM, Hobart Spitz wrote:
> Somewhere, maybe in a different branch of this topic, there was a
> discussion about the pros and cons of replacing Assembler with Java.  I
> apologize for posting here if it's the wrong place, but I can't seem to
> find the original discussion, and I have a question that seems relevant and
> important, IMHO.
>
> That's said, I can answer the question, for C/C++, as follows.  (I pose the
> question for Java, below.)
>
> *With the *nix/C record and string models, there are these issues:*
>
> 1. Errant/unexpected/unintended pieces of binary data in a text
> file/string can break something.
> 2. Separate functions/methods/techniques must be used to manipulate text
> files/strings versus binary files/string. You *must* know what you are
> dealing with up front, and/or somehow code logic for both. (I'm not sure
> the latter is possible in the general case.)
> 3. Even with *nix/C oriented machine instructions, the need to inspect
> all characters up to a target point results in performance killing cache
> flooding.
> 4. C++ does garbage collection resulting in "pauses" in forward
> progress, and working set, caching, and CPU spikes, among other things.
>
> Let's call these attributes fragility, productivity, and efficiency,
> respectively, for the convenience convenience.  C has issue with these
> characteristics.
>
> As most of the readers here know, mainframe style records and strings do
> not suffer from these limitation.  When the length of a string/record is
> known external to the data contents, you can manipulate any platform-native
> data in z/OS, z/VM without it breaking due to something in the data, you
> write the same code regardless of what you are dealing with, and, less
> obviously, any activity that skips a cache can avoid a cache line promotion
> saving processor resources.
>
> So, my "burning" question for Java is, which, if any, of these above issues
> (data fragility, coding productivity, efficiency, and garbage collections)
> does Java share with C/C++.
>
> If Java suffers from all or most of the issues, then I would say replacing
> Assembler with Java is pretty much out of the question.  On the other hand,
> if Java suffers few or none of the above issues, it might be viable to
> replace Assembler with Java (ignoring other issues, like cost, testing,
> compatibility, data porting, etc.)
>
> To sum up:  Does Java use a similar record/string model to that of C/C++,
> and does it do garbage collection similarly.
>
> Thanks in advance for satisfying my curiosity.
>
>
>
>
>
>
>
>
>
>
>
> OREXXMan
> JCL is the buggy whip of 21st century computing.
> We want Pipelines in the z/OS base.
>
> On Sat, Apr 21, 2018 

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Kirk Wolf]

On Mon, Apr 23, 2018 at 8:23 AM, Jerry Callen  wrote:

>
> I've programmed in assembler, PL/I, COBOL and C/C++. If you are dealing
> with COBOL records that make extensive use of OCCURS DEPENDING ON, it
> probably make sense to stick with COBOL. Otherwise, it's quite easy to
> write robust, efficient code in C and C++ on z/OS.
>
>
Indeed COBOL ODO and related complexities make it difficult.

The IBM Record Generator for Java"  (formerly known as the JZOS Record
Generator) does support converting COBOL ADATA layouts to Java record
mapping classes:

https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an=ca=897=ENUS217-295
https://developer.ibm.com/cics/2016/05/12/java-cics-using-ibmjzos/

If you run a COBOL ODO through this, you can see the generated Java code
that handles var length strings, arrays of structures, and offsetting
everything (and the things that follow ODOs).

The same thing could be implemented for C/C++.  SMOP :-)

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Seymour J Metz]

Isn't a class with no methods essentially a record type? Although that still 
leaves the issue of reading and writing them.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Monday, April 23, 2018 4:45 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com)

C++ doesn't have garbage collection. Resource finalization is
deterministic and performed by a destructor. Also, C++ has POD structs
that map data in the same way as assembler, C, COBOL, PL/1 and access
record based data sources in exactly the same way.

Java doesn't have records and does not support value types (like C#) so
you can't define a class with fixed sized buffers on the stack. To map a
record from a legacy data source you have to use a byte array and
manipulate it using a class like a ByteBuffer.
This is mostly done using code generation tools to serialize the data
into the corresponding Java types. Of course, there is a lot of overhead
in doing so but that's why IBM have provided zIIP processors. If it
wasn't for zIIPs Java would not be
viable on z/OS. IBM have done a lot of work on the hardware stack to
make Java more efficient. The z114 has a new facility to help implement
pauseless garbage collection.

The z/OS JVM is highly optimized for heap memory management and
efficient use of cache lines. It provides excellent features for
concurrent programming and provides collection libraries for concurrent
data structures using lock-free/wait-free
algorithms. For example, ConcurrentHashMap can make use of transactional
memory to serialize access
The string class uses the new SIMD instructions for search/replace
methods. Once the JIT compiler has warmed up it will inline the hot
spots to improve code locality and mitigate instruction caches misses.

The most important thing to bear in mind is that replacing a legacy
application written in assembler with Java is madness and doomed to
failure. IMO, Java should be used only for new applications or
modernizing and existing legacy application.


On 23/04/2018 6:29 AM, Hobart Spitz wrote:
> Somewhere, maybe in a different branch of this topic, there was a
> discussion about the pros and cons of replacing Assembler with Java.  I
> apologize for posting here if it's the wrong place, but I can't seem to
> find the original discussion, and I have a question that seems relevant and
> important, IMHO.
>
> That's said, I can answer the question, for C/C++, as follows.  (I pose the
> question for Java, below.)
>
> *With the *nix/C record and string models, there are these issues:*
>
> 1. Errant/unexpected/unintended pieces of binary data in a text
> file/string can break something.
> 2. Separate functions/methods/techniques must be used to manipulate text
> files/strings versus binary files/string. You *must* know what you are
> dealing with up front, and/or somehow code logic for both. (I'm not sure
> the latter is possible in the general case.)
> 3. Even with *nix/C oriented machine instructions, the need to inspect
> all characters up to a target point results in performance killing cache
> flooding.
> 4. C++ does garbage collection resulting in "pauses" in forward
> progress, and working set, caching, and CPU spikes, among other things.
>
> Let's call these attributes fragility, productivity, and efficiency,
> respectively, for the convenience convenience.  C has issue with these
> characteristics.
>
> As most of the readers here know, mainframe style records and strings do
> not suffer from these limitation.  When the length of a string/record is
> known external to the data contents, you can manipulate any platform-native
> data in z/OS, z/VM without it breaking due to something in the data, you
> write the same code regardless of what you are dealing with, and, less
> obviously, any activity that skips a cache can avoid a cache line promotion
> saving processor resources.
>
> So, my "burning" question for Java is, which, if any, of these above issues
> (data fragility, coding productivity, efficiency, and garbage collections)
> does Java share with C/C++.
>
> If Java suffers from all or most of the issues, then I would say replacing
> Assembler with Java is pretty much out of the question.  On the other hand,
> if Java suffers few or none of the above issues, it might be viable to
> replace Assembler with Java (ignoring other issues, like cost, testing,
> compatibility, data porting, etc.)
>
> To sum up:  Does Java use a similar record/string model to that of C/C++,
> and does it do garbage collection similarly.
>
> Thanks in advance for satisfying my curiosity.
>
>
>
>
>
>
>
>
>
>
>
> OREXXMan
> JCL is the buggy whip of 21st century computing.
> We want Pipelines in the z/OS base.
>
> On Sat, Apr 21, 2018 at 12:29 PM, 

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Jerry Callen]

On Sun, 22 Apr 2018 18:29:38 -0400, Hobart Spitz  wrote:

>That's said, I can answer the question, for C/C++, as follows.  (I pose the
>question for Java, below.)
>
>*With the *nix/C record and string models, there are these issues:*
>
>   1. Errant/unexpected/unintended pieces of binary data in a text
>   file/string can break something.
>   2. Separate functions/methods/techniques must be used to manipulate text
>   files/strings versus binary files/string. You *must* know what you are
>   dealing with up front, and/or somehow code logic for both. (I'm not sure
>   the latter is possible in the general case.)
>   3. Even with *nix/C oriented machine instructions, the need to inspect
>   all characters up to a target point results in performance killing cache
>   flooding.
>   4. C++ does garbage collection resulting in "pauses" in forward
>   progress, and working set, caching, and CPU spikes, among other things.
>
>Let's call these attributes fragility, productivity, and efficiency,
>respectively, for the convenience convenience.  C has issue with these
>characteristics.

C and C++ do NOT have garbage collection; memory management is controlled by 
the programmer, with C++ providing a lot of assistance in the form of 
constructors and destructors.

String manipulation can be done in a variety of ways; C++, in particular, 
provides counted strings and byte arrays with no restrictions on content.

I've programmed in assembler, PL/I, COBOL and C/C++. If you are dealing with 
COBOL records that make extensive use of OCCURS DEPENDING ON, it probably make 
sense to stick with COBOL. Otherwise, it's quite easy to write robust, 
efficient code in C and C++ on z/OS.

-- Jerry

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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Smith, Nathan (ATLANTA, GA)]

My young whippersnapper self (I'm 31 now, but I started my career as a 
mainframe developer at 23) remembers listening to the seasoned professionals 
talk about Y2K.  They told me that they weren't all that concerned with Y2K on 
mainframe insurance administration and claims systems since they used ALIS 
dates (my former employer was a Fortune 500 disability insurer) where the dates 
were stored as DDDYYY in packed decimal format, where DDD is the Julian date 
and YYY is the offset from 1800.  Developers in the year 2799 might be in a 
pinch, but there's plenty of time to figure it out. :)

Anthem, Inc.

Nathan A. Smith, Database Administrator Sr., Anthem Database Services
600 Peachtree St. NE, Main Drop GA1319-A154, Atlanta, GA 30308
O: (770) 519-6496 | M: (770) 519-6496
nathanael.sm...@anthem.com



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Porowski, Kenneth
Sent: Friday, April 20, 2018 16:35
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com)

Now for those that didn't move to a 4 digit year to resolve Y2K but instead 
went to a window technique, how many of your current staff know what dates were 
used for the window so they can again fix the problem before it occurs.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David L. Craig
Sent: Friday, April 20, 2018 4:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day Due to 
New Hardware (nextgov.com)

In 1974, we considered it, but the cost of a byte of disk storage was enough to 
push the storage of each date's century toward the '90s.  We fully expected the 
remediation would be needed but storage would be more affordable by then, which 
panned out.  What everybody got wrong was expecting the relative costs of 
hardware and software to not change, but in fact they flipped--hardware became 
dirt cheap but software became very expensive.

On Fri, Apr 20, 2018 at 7:46 PM, Gerhard Adam  wrote:

> It was discussed, but the general feeling was that those systems would
> have been rewritten or replaced long before it became an issue.
>
> No one expected applications to be running 30-40 years after they were
> first implemented.
>
> Sent from my iPhone
>
> > On Apr 20, 2018, at 12:25 PM, Lester, Bob  wrote:
> >
> >
> > I agree with both you and Gil.  But, how many programmers in the
> > 60s,
> 70s, even 80s were thinking about Y2K?  Sure, the really good ones
> were, but what about the other 80%?
> >
> > and, Y2K came off without a hitch...(FSVO - "hitch")
> >
> > I love Fridays...
> >
> > BobL
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Porowski, Kenneth
> > Sent: Friday, April 20, 2018 1:20 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to
> > New
> Hardware (nextgov.com) [ EXTERNAL ]
> >
> > That was due to lack of foresight by the programmer not due to the
> > age
> of the system.
> >
> >
> >
> > This email message and any accompanying materials may contain
> proprietary, privileged and confidential information of CIT Group Inc.
> or its subsidiaries or affiliates (collectively, “CIT”), and are
> intended solely for the recipient(s) named above.  If you are not the
> intended recipient of this communication, any use, disclosure,
> printing, copying or distribution, or reliance on the contents, of
> this communication is strictly prohibited.  CIT disclaims any
> liability for the review, retransmission, dissemination or other use
> of, or the taking of any action in reliance upon, this communication
> by persons other than the intended recipient(s).  If you have received
> this communication in error, please reply to the sender advising of
> the error in transmission, and immediately delete and destroy the
> communication and any accompanying materials.  To the extent permitted
> by applicable law, CIT and others may inspect, review, monitor,
> analyze, copy, record and retain any communications sent from or received at 
> this email address.
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> > Sent: Friday, April 20, 2018 3:13 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax
> > Day
> Due to New Hardware (nextgov.com)
> >
> >> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:
> >>
> >> Applications don't get old.  They either do what they're supposed
> >> to do
> or they don't.   It has nothing to do with age.
> > Remember Y2K?
> >
> > -- gil
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / 

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[David Crayford]

C++ doesn't have garbage collection. Resource finalization is 
deterministic and performed by a destructor. Also, C++ has POD structs 
that map data in the same way as assembler, C, COBOL, PL/1 and access 
record based data sources in exactly the same way.


Java doesn't have records and does not support value types (like C#) so 
you can't define a class with fixed sized buffers on the stack. To map a 
record from a legacy data source you have to use a byte array and 
manipulate it using a class like a ByteBuffer.
This is mostly done using code generation tools to serialize the data 
into the corresponding Java types. Of course, there is a lot of overhead 
in doing so but that's why IBM have provided zIIP processors. If it 
wasn't for zIIPs Java would not be
viable on z/OS. IBM have done a lot of work on the hardware stack to 
make Java more efficient. The z114 has a new facility to help implement 
pauseless garbage collection.


The z/OS JVM is highly optimized for heap memory management and 
efficient use of cache lines. It provides excellent features for 
concurrent programming and provides collection libraries for concurrent 
data structures using lock-free/wait-free
algorithms. For example, ConcurrentHashMap can make use of transactional 
memory to serialize access
The string class uses the new SIMD instructions for search/replace 
methods. Once the JIT compiler has warmed up it will inline the hot 
spots to improve code locality and mitigate instruction caches misses.


The most important thing to bear in mind is that replacing a legacy 
application written in assembler with Java is madness and doomed to 
failure. IMO, Java should be used only for new applications or 
modernizing and existing legacy application.



On 23/04/2018 6:29 AM, Hobart Spitz wrote:

Somewhere, maybe in a different branch of this topic, there was a
discussion about the pros and cons of replacing Assembler with Java.  I
apologize for posting here if it's the wrong place, but I can't seem to
find the original discussion, and I have a question that seems relevant and
important, IMHO.

That's said, I can answer the question, for C/C++, as follows.  (I pose the
question for Java, below.)

*With the *nix/C record and string models, there are these issues:*

1. Errant/unexpected/unintended pieces of binary data in a text
file/string can break something.
2. Separate functions/methods/techniques must be used to manipulate text
files/strings versus binary files/string. You *must* know what you are
dealing with up front, and/or somehow code logic for both. (I'm not sure
the latter is possible in the general case.)
3. Even with *nix/C oriented machine instructions, the need to inspect
all characters up to a target point results in performance killing cache
flooding.
4. C++ does garbage collection resulting in "pauses" in forward
progress, and working set, caching, and CPU spikes, among other things.

Let's call these attributes fragility, productivity, and efficiency,
respectively, for the convenience convenience.  C has issue with these
characteristics.

As most of the readers here know, mainframe style records and strings do
not suffer from these limitation.  When the length of a string/record is
known external to the data contents, you can manipulate any platform-native
data in z/OS, z/VM without it breaking due to something in the data, you
write the same code regardless of what you are dealing with, and, less
obviously, any activity that skips a cache can avoid a cache line promotion
saving processor resources.

So, my "burning" question for Java is, which, if any, of these above issues
(data fragility, coding productivity, efficiency, and garbage collections)
does Java share with C/C++.

If Java suffers from all or most of the issues, then I would say replacing
Assembler with Java is pretty much out of the question.  On the other hand,
if Java suffers few or none of the above issues, it might be viable to
replace Assembler with Java (ignoring other issues, like cost, testing,
compatibility, data porting, etc.)

To sum up:  Does Java use a similar record/string model to that of C/C++,
and does it do garbage collection similarly.

Thanks in advance for satisfying my curiosity.











OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Sat, Apr 21, 2018 at 12:29 PM, Barry Merrill  wrote:


In 1975 there was a BOF, Bird's of a Feather Session on Year 2000 Concerns
at the SPRING SHARE meeting, as I recall.  BOF's were spontaneous evening
meetings posted/scheduled usually that day.

Barry


Herbert W. “Barry” Merrill, PhD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
ba...@mxg.com



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Friday, April 20, 2018 5:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Hobart Spitz]

Somewhere, maybe in a different branch of this topic, there was a
discussion about the pros and cons of replacing Assembler with Java.  I
apologize for posting here if it's the wrong place, but I can't seem to
find the original discussion, and I have a question that seems relevant and
important, IMHO.

That's said, I can answer the question, for C/C++, as follows.  (I pose the
question for Java, below.)

*With the *nix/C record and string models, there are these issues:*

   1. Errant/unexpected/unintended pieces of binary data in a text
   file/string can break something.
   2. Separate functions/methods/techniques must be used to manipulate text
   files/strings versus binary files/string. You *must* know what you are
   dealing with up front, and/or somehow code logic for both. (I'm not sure
   the latter is possible in the general case.)
   3. Even with *nix/C oriented machine instructions, the need to inspect
   all characters up to a target point results in performance killing cache
   flooding.
   4. C++ does garbage collection resulting in "pauses" in forward
   progress, and working set, caching, and CPU spikes, among other things.

Let's call these attributes fragility, productivity, and efficiency,
respectively, for the convenience convenience.  C has issue with these
characteristics.

As most of the readers here know, mainframe style records and strings do
not suffer from these limitation.  When the length of a string/record is
known external to the data contents, you can manipulate any platform-native
data in z/OS, z/VM without it breaking due to something in the data, you
write the same code regardless of what you are dealing with, and, less
obviously, any activity that skips a cache can avoid a cache line promotion
saving processor resources.

So, my "burning" question for Java is, which, if any, of these above issues
(data fragility, coding productivity, efficiency, and garbage collections)
does Java share with C/C++.

If Java suffers from all or most of the issues, then I would say replacing
Assembler with Java is pretty much out of the question.  On the other hand,
if Java suffers few or none of the above issues, it might be viable to
replace Assembler with Java (ignoring other issues, like cost, testing,
compatibility, data porting, etc.)

To sum up:  Does Java use a similar record/string model to that of C/C++,
and does it do garbage collection similarly.

Thanks in advance for satisfying my curiosity.











OREXXMan
JCL is the buggy whip of 21st century computing.
We want Pipelines in the z/OS base.

On Sat, Apr 21, 2018 at 12:29 PM, Barry Merrill  wrote:

> In 1975 there was a BOF, Bird's of a Feather Session on Year 2000 Concerns
> at the SPRING SHARE meeting, as I recall.  BOF's were spontaneous evening
> meetings posted/scheduled usually that day.
>
> Barry
>
>
> Herbert W. “Barry” Merrill, PhD
> President-Programmer
> Merrill Consultants
> MXG Software
> 10717 Cromwell Drive
> Dallas, TX 75229
> www.mxg.com
> ba...@mxg.com
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, April 20, 2018 5:27 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New
> Hardware (nextgov.com)
>
> On Fri, 20 Apr 2018 19:25:54 +, Lester, Bob wrote:
> >
> >I agree with both you and Gil.  But, how many programmers in the 60s,
> 70s, even 80s were thinking about Y2K?  Sure, the really good ones were,
> but what about the other 80%?
> >
> >and, Y2K came off without a hitch...(FSVO - "hitch")
>
>
> >-Original Message-
> >From: IBM Mainframe Discussion List Porowski, Kenneth
> >Sent: Friday, April 20, 2018 1:20 PM
> >
> >That was due to lack of foresight by the programmer not due to the age of
> the system.
> >
> True in the sense that it affected one-year-old computers as much as older
> computers running th same software.
>
> I'm disappointed that this thread has so much focused on Y2K which I meant
> only as an extreme example.  Things change.  Y2K was only more precisely
> forseeable.
>
> Increasing complexity of the tax code requires new logic.  Inflation and
> rate escalation may have made some data fields inadequate in size.
> E-filing requires network interfaces and code to support them and causes
> the one-day spike in workload.  I gather from these fora that COBOL is not
> comfortably suited to TCP/IP.  IBM bet that SNA/VTAM could crush TCP/IP and
> customers were the losers.  IBM bet that EBCDIC could crush ASCII and
> customers were the losers.  And customers bet that COBOL skills would
> remain in the forefront of availability.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Barry Merrill]

In 1975 there was a BOF, Bird's of a Feather Session on Year 2000 Concerns
at the SPRING SHARE meeting, as I recall.  BOF's were spontaneous evening
meetings posted/scheduled usually that day.

Barry 


Herbert W. “Barry” Merrill, PhD
President-Programmer
Merrill Consultants
MXG Software
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com
ba...@mxg.com



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, April 20, 2018 5:27 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com)

On Fri, 20 Apr 2018 19:25:54 +, Lester, Bob wrote:
>
>I agree with both you and Gil.  But, how many programmers in the 60s, 70s, 
>even 80s were thinking about Y2K?  Sure, the really good ones were, but what 
>about the other 80%?
>
>and, Y2K came off without a hitch...(FSVO - "hitch")


>-Original Message-
>From: IBM Mainframe Discussion List Porowski, Kenneth
>Sent: Friday, April 20, 2018 1:20 PM
>
>That was due to lack of foresight by the programmer not due to the age of the 
>system.
>
True in the sense that it affected one-year-old computers as much as older 
computers running th same software.

I'm disappointed that this thread has so much focused on Y2K which I meant only 
as an extreme example.  Things change.  Y2K was only more precisely forseeable.

Increasing complexity of the tax code requires new logic.  Inflation and rate 
escalation may have made some data fields inadequate in size.  E-filing 
requires network interfaces and code to support them and causes the one-day 
spike in workload.  I gather from these fora that COBOL is not comfortably 
suited to TCP/IP.  IBM bet that SNA/VTAM could crush TCP/IP and customers were 
the losers.  IBM bet that EBCDIC could crush ASCII and customers were the 
losers.  And customers bet that COBOL skills would remain in the forefront of 
availability.

-- gil

--
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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Edward Gould]

> On Apr 20, 2018, at 3:26 PM, David L. Craig  wrote:
> 
> In 1974, we considered it, but the cost of a byte of disk storage was
> enough to push the storage of each date's century toward the '90s.  We
> fully expected the remediation would be needed but storage would be more
> affordable by then, which panned out.  What everybody got wrong was
> expecting the relative costs of hardware and software to not change, but in
> fact they flipped--hardware became dirt cheap but software became very
> expensive.


Tell me about it. At the time I worked on a online savings program that to save 
space always dropped the sign from the packed fields. You sure learned to do 
MVO like it was an MVC.

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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Edward Gould]

> On Apr 20, 2018, at 3:03 PM, Christopher Y. Blaicher  
> wrote:
> 
> Windows programmers are blown away when I tell them that I still run a 
> program I wrote 45+ years ago.  They ask if I have to re-compile it and I 
> tell them no, it is the same load module created way back then.  Their jaws 
> drop.
> 

Chris,

I have run across 3-4 programs that were compiled in the 1970’s (early IIRC) 
that run many times a day and they still keep running, both in COBOL and ALC. 

Ed

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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Edward Gould]

> On Apr 20, 2018, at 2:13 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:
> 
>> Applications don't get old.  They either do what they're supposed to do or 
>> they don't.   It has nothing to do with age.
>> 
> Remember Y2K?

In the early 70’s I was writing an SMF reporting program.  The y2K hit me while 
I was coding. I stopped and asked the person responsible and he said “Don’t 
worry we will be long gone before it hits” Truth be told the bank sure didn’t 
so nobody was there to hear.

Ed
> 
> -- gil
> 
> --
> 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Doug Fuerst]

Sorry, but I see this as the extension of the nonsense LILCO pulled 
during a hurricane or a nor'easter (I can't recall which) where they 
blamed the lousy pole maintenance on the MF system's they were running.

It was a bunch of nonsense. This is too.

Doug Fuerst
d...@bkassociates.net



-- Original Message --
From: "Gerhard Adam" 
To: IBM-MAIN@listserv.ua.edu
Sent: 20-Apr-18 6:58:27 PM
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New 
Hardware (nextgov.com)


It seems your picking a fight that doesn't exist.  The IRS, has not had 
a problem complying with the tax code, nor in processing returns.  
Software was clearly changed and capable of doing what was needed.


COBOL was never intended to interface directly with networking software 
so it was no more suited for IP than it was for SNA.  Those services 
were provided by subsystems like CICS for which COBOL still works.


I have no idea of why you think customers care about COBOL skills.

The issue I have, is that all the complaining about IBM seems to 
overlook one important fact.  It is IBM that enables companies to 
preserve their investment in code that was developed and is still 
running 40 years later.


When *nix and Windows systems can do some comparable, then there might 
be something to discuss.  At present, they can't even assure a 
program's operation between releases let alone over decades of use.


Sent from my iPhone

 On Apr 20, 2018, at 3:26 PM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:



 On Fri, 20 Apr 2018 19:25:54 +, Lester, Bob wrote:

 I agree with both you and Gil.  But, how many programmers in the 
60s, 70s, even 80s were thinking about Y2K?  Sure, the really good 
ones were, but what about the other 80%?


 and, Y2K came off without a hitch...(FSVO - "hitch")




 -Original Message-
 From: IBM Mainframe Discussion List Porowski, Kenneth
 Sent: Friday, April 20, 2018 1:20 PM

 That was due to lack of foresight by the programmer not due to the 
age of the system.
 True in the sense that it affected one-year-old computers as much as 
older computers

 running th same software.

 I'm disappointed that this thread has so much focused on Y2K which I 
meant only as
 an extreme example.  Things change.  Y2K was only more precisely 
forseeable.


 Increasing complexity of the tax code requires new logic.  Inflation 
and rate escalation
 may have made some data fields inadequate in size.  E-filing requires 
network interfaces
 and code to support them and causes the one-day spike in workload.  I 
gather from
 these fora that COBOL is not comfortably suited to TCP/IP.  IBM bet 
that SNA/VTAM
 could crush TCP/IP and customers were the losers.  IBM bet that 
EBCDIC could crush
 ASCII and customers were the losers.  And customers bet that COBOL 
skills would remain

 in the forefront of availability.

 -- gil

 
--

 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Mike Schwab]

IBM designed EBCDIC to work with existing card punch equipment and 7
track tapes.  ASCII had not been finalized.  They included a mode
switch into S360 but didn't implement it in software.

On Fri, Apr 20, 2018 at 5:26 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Fri, 20 Apr 2018 19:25:54 +, Lester, Bob wrote:
>>
>>I agree with both you and Gil.  But, how many programmers in the 60s, 70s, 
>>even 80s were thinking about Y2K?  Sure, the really good ones were, but what 
>>about the other 80%?
>>
>>and, Y2K came off without a hitch...(FSVO - "hitch")
>
>
>>-Original Message-
>>From: IBM Mainframe Discussion List Porowski, Kenneth
>>Sent: Friday, April 20, 2018 1:20 PM
>>
>>That was due to lack of foresight by the programmer not due to the age of the 
>>system.
>>
> True in the sense that it affected one-year-old computers as much as older 
> computers
> running th same software.
>
> I'm disappointed that this thread has so much focused on Y2K which I meant 
> only as
> an extreme example.  Things change.  Y2K was only more precisely forseeable.
>
> Increasing complexity of the tax code requires new logic.  Inflation and rate 
> escalation
> may have made some data fields inadequate in size.  E-filing requires network 
> interfaces
> and code to support them and causes the one-day spike in workload.  I gather 
> from
> these fora that COBOL is not comfortably suited to TCP/IP.  IBM bet that 
> SNA/VTAM
> could crush TCP/IP and customers were the losers.  IBM bet that EBCDIC could 
> crush
> ASCII and customers were the losers.  And customers bet that COBOL skills 
> would remain
> in the forefront of availability.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Gerhard Adam]

It seems your picking a fight that doesn't exist.  The IRS, has not had a 
problem complying with the tax code, nor in processing returns.  Software was 
clearly changed and capable of doing what was needed.

COBOL was never intended to interface directly with networking software so it 
was no more suited for IP than it was for SNA.  Those services were provided by 
subsystems like CICS for which COBOL still works.

I have no idea of why you think customers care about COBOL skills.

The issue I have, is that all the complaining about IBM seems to overlook one 
important fact.  It is IBM that enables companies to preserve their investment 
in code that was developed and is still running 40 years later.

When *nix and Windows systems can do some comparable, then there might be 
something to discuss.  At present, they can't even assure a program's operation 
between releases let alone over decades of use.

Sent from my iPhone

> On Apr 20, 2018, at 3:26 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> On Fri, 20 Apr 2018 19:25:54 +, Lester, Bob wrote:
>> 
>> I agree with both you and Gil.  But, how many programmers in the 60s, 70s, 
>> even 80s were thinking about Y2K?  Sure, the really good ones were, but what 
>> about the other 80%?
>> 
>> and, Y2K came off without a hitch...(FSVO - "hitch")
> 
> 
>> -Original Message-
>> From: IBM Mainframe Discussion List Porowski, Kenneth
>> Sent: Friday, April 20, 2018 1:20 PM
>> 
>> That was due to lack of foresight by the programmer not due to the age of 
>> the system.
> True in the sense that it affected one-year-old computers as much as older 
> computers
> running th same software.
> 
> I'm disappointed that this thread has so much focused on Y2K which I meant 
> only as
> an extreme example.  Things change.  Y2K was only more precisely forseeable.
> 
> Increasing complexity of the tax code requires new logic.  Inflation and rate 
> escalation
> may have made some data fields inadequate in size.  E-filing requires network 
> interfaces
> and code to support them and causes the one-day spike in workload.  I gather 
> from
> these fora that COBOL is not comfortably suited to TCP/IP.  IBM bet that 
> SNA/VTAM
> could crush TCP/IP and customers were the losers.  IBM bet that EBCDIC could 
> crush
> ASCII and customers were the losers.  And customers bet that COBOL skills 
> would remain
> in the forefront of availability.
> 
> -- gil
> 
> --
> 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Tom Marchant]

On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:

>Applications don't get old.  They either do what they're supposed to do or 
>they don't. 
>It has nothing to do with age.

That's true if they don't need to be changed. But a program that has to be 
changed 
periodically does become harder to maintain, partly due to different 
programming 
styles of many different programmers making changes.

And as to Y2K, there was a story in Computerworld in the early 1970's (IIRC) 
about a 
105 year old woman who had received an invitation from her local elementary 
school 
to register for kindergarten. I was an application programmer at the time.

-- 
Tom Marchant

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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Paul Gilmartin]

On Fri, 20 Apr 2018 19:25:54 +, Lester, Bob wrote:
>
>I agree with both you and Gil.  But, how many programmers in the 60s, 70s, 
>even 80s were thinking about Y2K?  Sure, the really good ones were, but what 
>about the other 80%?
>
>and, Y2K came off without a hitch...(FSVO - "hitch")


>-Original Message-
>From: IBM Mainframe Discussion List Porowski, Kenneth
>Sent: Friday, April 20, 2018 1:20 PM
>
>That was due to lack of foresight by the programmer not due to the age of the 
>system.
>
True in the sense that it affected one-year-old computers as much as older 
computers
running th same software.

I'm disappointed that this thread has so much focused on Y2K which I meant only 
as
an extreme example.  Things change.  Y2K was only more precisely forseeable.

Increasing complexity of the tax code requires new logic.  Inflation and rate 
escalation
may have made some data fields inadequate in size.  E-filing requires network 
interfaces
and code to support them and causes the one-day spike in workload.  I gather 
from
these fora that COBOL is not comfortably suited to TCP/IP.  IBM bet that 
SNA/VTAM
could crush TCP/IP and customers were the losers.  IBM bet that EBCDIC could 
crush
ASCII and customers were the losers.  And customers bet that COBOL skills would 
remain
in the forefront of availability.

-- gil

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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[J R]

That looks more like when the TOD clock overflows. 

> On Apr 20, 2018, at 18:17, Lester, Bob  wrote:
> 
> I, OTOH, seem to remember 2049 as the (or our?) window.  Not sure these days, 
> I'm busy in penguin land
> 
> BobL

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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Lester, Bob]

I, OTOH, seem to remember 2049 as the (or our?) window.  Not sure these days, 
I'm busy in penguin land

BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chris Hoelscher
Sent: Friday, April 20, 2018 2:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com) [ EXTERNAL ]

I seem to recall that 69 was a popular choice for the window breakpoint ...

Chris Hoelscher
Technology Architect, Database Infrastructure Services Technology Solution 
Services Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Porowski, Kenneth
Sent: Friday, April 20, 2018 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day Due to 
New Hardware (nextgov.com)

Now for those that didn't move to a 4 digit year to resolve Y2K but instead 
went to a window technique, how many of your current staff know what dates were 
used for the window so they can again fix the problem before it occurs.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David L. Craig
Sent: Friday, April 20, 2018 4:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day Due to 
New Hardware (nextgov.com)

In 1974, we considered it, but the cost of a byte of disk storage was enough to 
push the storage of each date's century toward the '90s.  We fully expected the 
remediation would be needed but storage would be more affordable by then, which 
panned out.  What everybody got wrong was expecting the relative costs of 
hardware and software to not change, but in fact they flipped--hardware became 
dirt cheap but software became very expensive.

On Fri, Apr 20, 2018 at 7:46 PM, Gerhard Adam  wrote:

> It was discussed, but the general feeling was that those systems would 
> have been rewritten or replaced long before it became an issue.
>
> No one expected applications to be running 30-40 years after they were 
> first implemented.
>
> Sent from my iPhone
>
> > On Apr 20, 2018, at 12:25 PM, Lester, Bob  wrote:
> >
> >
> > I agree with both you and Gil.  But, how many programmers in the 
> > 60s,
> 70s, even 80s were thinking about Y2K?  Sure, the really good ones 
> were, but what about the other 80%?
> >
> > and, Y2K came off without a hitch...(FSVO - "hitch")
> >
> > I love Fridays...
> >
> > BobL
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Porowski, Kenneth
> > Sent: Friday, April 20, 2018 1:20 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to 
> > New
> Hardware (nextgov.com) [ EXTERNAL ]
> >
> > That was due to lack of foresight by the programmer not due to the 
> > age
> of the system.
> >
> >
> >
> > This email message and any accompanying materials may contain
> proprietary, privileged and confidential information of CIT Group Inc. 
> or its subsidiaries or affiliates (collectively, “CIT”), and are 
> intended solely for the recipient(s) named above.  If you are not the 
> intended recipient of this communication, any use, disclosure, 
> printing, copying or distribution, or reliance on the contents, of 
> this communication is strictly prohibited.  CIT disclaims any 
> liability for the review, retransmission, dissemination or other use 
> of, or the taking of any action in reliance upon, this communication 
> by persons other than the intended recipient(s).  If you have received 
> this communication in error, please reply to the sender advising of 
> the error in transmission, and immediately delete and destroy the 
> communication and any accompanying materials.  To the extent permitted 
> by applicable law, CIT and others may inspect, review, monitor, 
> analyze, copy, record and retain any communications sent from or received at 
> this email address.
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> > Sent: Friday, April 20, 2018 3:13 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax 
> > Day
> Due to New Hardware (nextgov.com)
> >
> >> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:
> >>
> >> Applications don't get old.  They either do what they're supposed 
> >> to do
> or they don't.   It has nothing to do with age.
> > Remember Y2K?
> >
> > -- gil
> >
> > 
> > -- For IBM-MAIN subscribe / signoff / archive access instructions, 
> > send
> email to lists...@listserv.ua.edu with the 

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Chris Hoelscher]

I seem to recall that 69 was a popular choice for the window breakpoint ...

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services
Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Porowski, Kenneth
Sent: Friday, April 20, 2018 4:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day Due to 
New Hardware (nextgov.com)

Now for those that didn't move to a 4 digit year to resolve Y2K but instead 
went to a window technique, how many of your current staff know what dates were 
used for the window so they can again fix the problem before it occurs.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David L. Craig
Sent: Friday, April 20, 2018 4:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day Due to 
New Hardware (nextgov.com)

In 1974, we considered it, but the cost of a byte of disk storage was enough to 
push the storage of each date's century toward the '90s.  We fully expected the 
remediation would be needed but storage would be more affordable by then, which 
panned out.  What everybody got wrong was expecting the relative costs of 
hardware and software to not change, but in fact they flipped--hardware became 
dirt cheap but software became very expensive.

On Fri, Apr 20, 2018 at 7:46 PM, Gerhard Adam  wrote:

> It was discussed, but the general feeling was that those systems would 
> have been rewritten or replaced long before it became an issue.
>
> No one expected applications to be running 30-40 years after they were 
> first implemented.
>
> Sent from my iPhone
>
> > On Apr 20, 2018, at 12:25 PM, Lester, Bob  wrote:
> >
> >
> > I agree with both you and Gil.  But, how many programmers in the 
> > 60s,
> 70s, even 80s were thinking about Y2K?  Sure, the really good ones 
> were, but what about the other 80%?
> >
> > and, Y2K came off without a hitch...(FSVO - "hitch")
> >
> > I love Fridays...
> >
> > BobL
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Porowski, Kenneth
> > Sent: Friday, April 20, 2018 1:20 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to 
> > New
> Hardware (nextgov.com) [ EXTERNAL ]
> >
> > That was due to lack of foresight by the programmer not due to the 
> > age
> of the system.
> >
> >
> >
> > This email message and any accompanying materials may contain
> proprietary, privileged and confidential information of CIT Group Inc. 
> or its subsidiaries or affiliates (collectively, “CIT”), and are 
> intended solely for the recipient(s) named above.  If you are not the 
> intended recipient of this communication, any use, disclosure, 
> printing, copying or distribution, or reliance on the contents, of 
> this communication is strictly prohibited.  CIT disclaims any 
> liability for the review, retransmission, dissemination or other use 
> of, or the taking of any action in reliance upon, this communication 
> by persons other than the intended recipient(s).  If you have received 
> this communication in error, please reply to the sender advising of 
> the error in transmission, and immediately delete and destroy the 
> communication and any accompanying materials.  To the extent permitted 
> by applicable law, CIT and others may inspect, review, monitor, 
> analyze, copy, record and retain any communications sent from or received at 
> this email address.
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> > Sent: Friday, April 20, 2018 3:13 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax 
> > Day
> Due to New Hardware (nextgov.com)
> >
> >> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:
> >>
> >> Applications don't get old.  They either do what they're supposed 
> >> to do
> or they don't.   It has nothing to do with age.
> > Remember Y2K?
> >
> > -- gil
> >
> > 
> > -- 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
> >
> > This e-mail transmission may contain information that is 
> > proprietary,
> privileged and/or confidential and is intended exclusively for the
> person(s) to 

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Porowski, Kenneth]

Now for those that didn't move to a 4 digit year to resolve Y2K but instead 
went to a window technique, how many of your current staff know what dates were 
used for the window so they can again fix the problem before it occurs.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David L. Craig
Sent: Friday, April 20, 2018 4:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day Due to 
New Hardware (nextgov.com)

In 1974, we considered it, but the cost of a byte of disk storage was enough to 
push the storage of each date's century toward the '90s.  We fully expected the 
remediation would be needed but storage would be more affordable by then, which 
panned out.  What everybody got wrong was expecting the relative costs of 
hardware and software to not change, but in fact they flipped--hardware became 
dirt cheap but software became very expensive.

On Fri, Apr 20, 2018 at 7:46 PM, Gerhard Adam  wrote:

> It was discussed, but the general feeling was that those systems would 
> have been rewritten or replaced long before it became an issue.
>
> No one expected applications to be running 30-40 years after they were 
> first implemented.
>
> Sent from my iPhone
>
> > On Apr 20, 2018, at 12:25 PM, Lester, Bob  wrote:
> >
> >
> > I agree with both you and Gil.  But, how many programmers in the 
> > 60s,
> 70s, even 80s were thinking about Y2K?  Sure, the really good ones 
> were, but what about the other 80%?
> >
> > and, Y2K came off without a hitch...(FSVO - "hitch")
> >
> > I love Fridays...
> >
> > BobL
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Porowski, Kenneth
> > Sent: Friday, April 20, 2018 1:20 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to 
> > New
> Hardware (nextgov.com) [ EXTERNAL ]
> >
> > That was due to lack of foresight by the programmer not due to the 
> > age
> of the system.
> >
> >
> >
> > This email message and any accompanying materials may contain
> proprietary, privileged and confidential information of CIT Group Inc. 
> or its subsidiaries or affiliates (collectively, “CIT”), and are 
> intended solely for the recipient(s) named above.  If you are not the 
> intended recipient of this communication, any use, disclosure, 
> printing, copying or distribution, or reliance on the contents, of 
> this communication is strictly prohibited.  CIT disclaims any 
> liability for the review, retransmission, dissemination or other use 
> of, or the taking of any action in reliance upon, this communication 
> by persons other than the intended recipient(s).  If you have received 
> this communication in error, please reply to the sender advising of 
> the error in transmission, and immediately delete and destroy the 
> communication and any accompanying materials.  To the extent permitted 
> by applicable law, CIT and others may inspect, review, monitor, 
> analyze, copy, record and retain any communications sent from or received at 
> this email address.
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> > Sent: Friday, April 20, 2018 3:13 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax 
> > Day
> Due to New Hardware (nextgov.com)
> >
> >> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:
> >>
> >> Applications don't get old.  They either do what they're supposed 
> >> to do
> or they don't.   It has nothing to do with age.
> > Remember Y2K?
> >
> > -- gil
> >
> > 
> > -- 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
> >
> > This e-mail transmission may contain information that is 
> > proprietary,
> privileged and/or confidential and is intended exclusively for the
> person(s) to whom it is addressed. Any use, copying, retention or 
> disclosure by any person other than the intended recipient or the 
> intended recipient's designees is strictly prohibited. If you are not 
> the intended recipient or their designee, please notify the sender 
> immediately by return e-mail and delete all copies. OppenheimerFunds 
> may, at its sole discretion, monitor, review, retain and/or disclose 
> the content of all email communications.
> >
> >
> > 
> > -- For IBM-MAIN subscribe / signoff 

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[David L. Craig]

In 1974, we considered it, but the cost of a byte of disk storage was
enough to push the storage of each date's century toward the '90s.  We
fully expected the remediation would be needed but storage would be more
affordable by then, which panned out.  What everybody got wrong was
expecting the relative costs of hardware and software to not change, but in
fact they flipped--hardware became dirt cheap but software became very
expensive.

On Fri, Apr 20, 2018 at 7:46 PM, Gerhard Adam  wrote:

> It was discussed, but the general feeling was that those systems would
> have been rewritten or replaced long before it became an issue.
>
> No one expected applications to be running 30-40 years after they were
> first implemented.
>
> Sent from my iPhone
>
> > On Apr 20, 2018, at 12:25 PM, Lester, Bob  wrote:
> >
> >
> > I agree with both you and Gil.  But, how many programmers in the 60s,
> 70s, even 80s were thinking about Y2K?  Sure, the really good ones were,
> but what about the other 80%?
> >
> > and, Y2K came off without a hitch...(FSVO - "hitch")
> >
> > I love Fridays...
> >
> > BobL
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Porowski, Kenneth
> > Sent: Friday, April 20, 2018 1:20 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New
> Hardware (nextgov.com) [ EXTERNAL ]
> >
> > That was due to lack of foresight by the programmer not due to the age
> of the system.
> >
> >
> >
> > This email message and any accompanying materials may contain
> proprietary, privileged and confidential information of CIT Group Inc. or
> its subsidiaries or affiliates (collectively, “CIT”), and are intended
> solely for the recipient(s) named above.  If you are not the intended
> recipient of this communication, any use, disclosure, printing, copying or
> distribution, or reliance on the contents, of this communication is
> strictly prohibited.  CIT disclaims any liability for the review,
> retransmission, dissemination or other use of, or the taking of any action
> in reliance upon, this communication by persons other than the intended
> recipient(s).  If you have received this communication in error, please
> reply to the sender advising of the error in transmission, and immediately
> delete and destroy the communication and any accompanying materials.  To
> the extent permitted by applicable law, CIT and others may inspect, review,
> monitor, analyze, copy, record and retain any communications sent from or
> received at this email address.
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> > Sent: Friday, April 20, 2018 3:13 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day
> Due to New Hardware (nextgov.com)
> >
> >> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:
> >>
> >> Applications don't get old.  They either do what they're supposed to do
> or they don't.   It has nothing to do with age.
> > Remember Y2K?
> >
> > -- gil
> >
> > --
> > 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
> >
> > This e-mail transmission may contain information that is proprietary,
> privileged and/or confidential and is intended exclusively for the
> person(s) to whom it is addressed. Any use, copying, retention or
> disclosure by any person other than the intended recipient or the intended
> recipient's designees is strictly prohibited. If you are not the intended
> recipient or their designee, please notify the sender immediately by return
> e-mail and delete all copies. OppenheimerFunds may, at its sole discretion,
> monitor, review, retain and/or disclose the content of all email
> communications.
> >
> >
> > --
> > 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Christopher Y. Blaicher]

Windows programmers are blown away when I tell them that I still run a program 
I wrote 45+ years ago.  They ask if I have to re-compile it and I tell them no, 
it is the same load module created way back then.  Their jaws drop.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lester, Bob
Sent: Friday, April 20, 2018 3:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com)


   Very good point!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard Adam
Sent: Friday, April 20, 2018 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com) [ EXTERNAL ]

It was discussed, but the general feeling was that those systems would have 
been rewritten or replaced long before it became an issue.

No one expected applications to be running 30-40 years after they were first 
implemented.

Sent from my iPhone

> On Apr 20, 2018, at 12:25 PM, Lester, Bob  wrote:
>
>
> I agree with both you and Gil.  But, how many programmers in the 60s, 70s, 
> even 80s were thinking about Y2K?  Sure, the really good ones were, but what 
> about the other 80%?
>
> and, Y2K came off without a hitch...(FSVO - "hitch")
>
> I love Fridays...
>
> BobL
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Porowski, Kenneth
> Sent: Friday, April 20, 2018 1:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New
> Hardware (nextgov.com) [ EXTERNAL ]
>
> That was due to lack of foresight by the programmer not due to the age of the 
> system.
>
>
>
> This email message and any accompanying materials may contain proprietary, 
> privileged and confidential information of CIT Group Inc. or its subsidiaries 
> or affiliates (collectively, “CIT”), and are intended solely for the 
> recipient(s) named above.  If you are not the intended recipient of this 
> communication, any use, disclosure, printing, copying or distribution, or 
> reliance on the contents, of this communication is strictly prohibited.  CIT 
> disclaims any liability for the review, retransmission, dissemination or 
> other use of, or the taking of any action in reliance upon, this 
> communication by persons other than the intended recipient(s).  If you have 
> received this communication in error, please reply to the sender advising of 
> the error in transmission, and immediately delete and destroy the 
> communication and any accompanying materials.  To the extent permitted by 
> applicable law, CIT and others may inspect, review, monitor, analyze, copy, 
> record and retain any communications sent from or received at this email 
> address.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Friday, April 20, 2018 3:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day
> Due to New Hardware (nextgov.com)
>
>> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:
>>
>> Applications don't get old.  They either do what they're supposed to do or 
>> they don't.   It has nothing to do with age.
> Remember Y2K?
>
> -- gil
>
> --
> 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
>
> This e-mail transmission may contain information that is proprietary, 
> privileged and/or confidential and is intended exclusively for the person(s) 
> to whom it is addressed. Any use, copying, retention or disclosure by any 
> person other than the intended recipient or the intended recipient's 
> designees is strictly prohibited. If you are not the intended recipient or 
> their designee, please notify the sender immediately by return e-mail and 
> delete all copies. OppenheimerFunds may, at its sole discretion, monitor, 
> review, retain and/or disclose the content of all email communications.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Keith Smith]

I started in 1983 and it was thought about, but a few years in and everyone
said the mainframe would be gone by 2000... That mainframe was gone by the
mid 1990's.

On Fri, Apr 20, 2018 at 3:49 PM, Lester, Bob  wrote:

>
>Very good point!
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Gerhard Adam
> Sent: Friday, April 20, 2018 1:47 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New
> Hardware (nextgov.com) [ EXTERNAL ]
>
> It was discussed, but the general feeling was that those systems would
> have been rewritten or replaced long before it became an issue.
>
> No one expected applications to be running 30-40 years after they were
> first implemented.
>
> Sent from my iPhone
>
> > On Apr 20, 2018, at 12:25 PM, Lester, Bob  wrote:
> >
> >
> > I agree with both you and Gil.  But, how many programmers in the 60s,
> 70s, even 80s were thinking about Y2K?  Sure, the really good ones were,
> but what about the other 80%?
> >
> > and, Y2K came off without a hitch...(FSVO - "hitch")
> >
> > I love Fridays...
> >
> > BobL
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Porowski, Kenneth
> > Sent: Friday, April 20, 2018 1:20 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New
> > Hardware (nextgov.com) [ EXTERNAL ]
> >
> > That was due to lack of foresight by the programmer not due to the age
> of the system.
> >
> >
> >
> > This email message and any accompanying materials may contain
> proprietary, privileged and confidential information of CIT Group Inc. or
> its subsidiaries or affiliates (collectively, “CIT”), and are intended
> solely for the recipient(s) named above.  If you are not the intended
> recipient of this communication, any use, disclosure, printing, copying or
> distribution, or reliance on the contents, of this communication is
> strictly prohibited.  CIT disclaims any liability for the review,
> retransmission, dissemination or other use of, or the taking of any action
> in reliance upon, this communication by persons other than the intended
> recipient(s).  If you have received this communication in error, please
> reply to the sender advising of the error in transmission, and immediately
> delete and destroy the communication and any accompanying materials.  To
> the extent permitted by applicable law, CIT and others may inspect, review,
> monitor, analyze, copy, record and retain any communications sent from or
> received at this email address.
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Paul Gilmartin
> > Sent: Friday, April 20, 2018 3:13 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day
> > Due to New Hardware (nextgov.com)
> >
> >> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:
> >>
> >> Applications don't get old.  They either do what they're supposed to do
> or they don't.   It has nothing to do with age.
> > Remember Y2K?
> >
> > -- gil
> >
> > --
> > 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
> >
> > This e-mail transmission may contain information that is proprietary,
> privileged and/or confidential and is intended exclusively for the
> person(s) to whom it is addressed. Any use, copying, retention or
> disclosure by any person other than the intended recipient or the intended
> recipient's designees is strictly prohibited. If you are not the intended
> recipient or their designee, please notify the sender immediately by return
> e-mail and delete all copies. OppenheimerFunds may, at its sole discretion,
> monitor, review, retain and/or disclose the content of all email
> communications.
> >
> >
> > --
> > 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Lester, Bob]

   Very good point!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gerhard Adam
Sent: Friday, April 20, 2018 1:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com) [ EXTERNAL ]

It was discussed, but the general feeling was that those systems would have 
been rewritten or replaced long before it became an issue.

No one expected applications to be running 30-40 years after they were first 
implemented.

Sent from my iPhone

> On Apr 20, 2018, at 12:25 PM, Lester, Bob  wrote:
> 
> 
> I agree with both you and Gil.  But, how many programmers in the 60s, 70s, 
> even 80s were thinking about Y2K?  Sure, the really good ones were, but what 
> about the other 80%?
> 
> and, Y2K came off without a hitch...(FSVO - "hitch")
> 
> I love Fridays...
> 
> BobL
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Porowski, Kenneth
> Sent: Friday, April 20, 2018 1:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New 
> Hardware (nextgov.com) [ EXTERNAL ]
> 
> That was due to lack of foresight by the programmer not due to the age of the 
> system.
> 
> 
> 
> This email message and any accompanying materials may contain proprietary, 
> privileged and confidential information of CIT Group Inc. or its subsidiaries 
> or affiliates (collectively, “CIT”), and are intended solely for the 
> recipient(s) named above.  If you are not the intended recipient of this 
> communication, any use, disclosure, printing, copying or distribution, or 
> reliance on the contents, of this communication is strictly prohibited.  CIT 
> disclaims any liability for the review, retransmission, dissemination or 
> other use of, or the taking of any action in reliance upon, this 
> communication by persons other than the intended recipient(s).  If you have 
> received this communication in error, please reply to the sender advising of 
> the error in transmission, and immediately delete and destroy the 
> communication and any accompanying materials.  To the extent permitted by 
> applicable law, CIT and others may inspect, review, monitor, analyze, copy, 
> record and retain any communications sent from or received at this email 
> address.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Paul Gilmartin
> Sent: Friday, April 20, 2018 3:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day 
> Due to New Hardware (nextgov.com)
> 
>> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:
>> 
>> Applications don't get old.  They either do what they're supposed to do or 
>> they don't.   It has nothing to do with age.
> Remember Y2K?
> 
> -- gil
> 
> --
> 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
> 
> This e-mail transmission may contain information that is proprietary, 
> privileged and/or confidential and is intended exclusively for the person(s) 
> to whom it is addressed. Any use, copying, retention or disclosure by any 
> person other than the intended recipient or the intended recipient's 
> designees is strictly prohibited. If you are not the intended recipient or 
> their designee, please notify the sender immediately by return e-mail and 
> delete all copies. OppenheimerFunds may, at its sole discretion, monitor, 
> review, retain and/or disclose the content of all email communications.
> 
> 
> --
> 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Gerhard Adam]

It was discussed, but the general feeling was that those systems would have 
been rewritten or replaced long before it became an issue.

No one expected applications to be running 30-40 years after they were first 
implemented.

Sent from my iPhone

> On Apr 20, 2018, at 12:25 PM, Lester, Bob  wrote:
> 
> 
> I agree with both you and Gil.  But, how many programmers in the 60s, 70s, 
> even 80s were thinking about Y2K?  Sure, the really good ones were, but what 
> about the other 80%?
> 
> and, Y2K came off without a hitch...(FSVO - "hitch")
> 
> I love Fridays...
> 
> BobL
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Porowski, Kenneth
> Sent: Friday, April 20, 2018 1:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New 
> Hardware (nextgov.com) [ EXTERNAL ]
> 
> That was due to lack of foresight by the programmer not due to the age of the 
> system.
> 
> 
> 
> This email message and any accompanying materials may contain proprietary, 
> privileged and confidential information of CIT Group Inc. or its subsidiaries 
> or affiliates (collectively, “CIT”), and are intended solely for the 
> recipient(s) named above.  If you are not the intended recipient of this 
> communication, any use, disclosure, printing, copying or distribution, or 
> reliance on the contents, of this communication is strictly prohibited.  CIT 
> disclaims any liability for the review, retransmission, dissemination or 
> other use of, or the taking of any action in reliance upon, this 
> communication by persons other than the intended recipient(s).  If you have 
> received this communication in error, please reply to the sender advising of 
> the error in transmission, and immediately delete and destroy the 
> communication and any accompanying materials.  To the extent permitted by 
> applicable law, CIT and others may inspect, review, monitor, analyze, copy, 
> record and retain any communications sent from or received at this email 
> address.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Friday, April 20, 2018 3:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day Due to 
> New Hardware (nextgov.com)
> 
>> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:
>> 
>> Applications don't get old.  They either do what they're supposed to do or 
>> they don't.   It has nothing to do with age.
> Remember Y2K?
> 
> -- gil
> 
> --
> 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
> 
> This e-mail transmission may contain information that is proprietary, 
> privileged and/or confidential and is intended exclusively for the person(s) 
> to whom it is addressed. Any use, copying, retention or disclosure by any 
> person other than the intended recipient or the intended recipient's 
> designees is strictly prohibited. If you are not the intended recipient or 
> their designee, please notify the sender immediately by return e-mail and 
> delete all copies. OppenheimerFunds may, at its sole discretion, monitor, 
> review, retain and/or disclose the content of all email communications.
> 
> 
> --
> 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Gerhard Adam]

Y2k had nothing to do with age.  It had to do with what applications did or 
didn't do.  If they had been written with 4 digit years they could have been 
written in 1964 and had no date issues.

It wasn't like a LA instruction suddenly showed signs of age.

Sent from my iPhone

> On Apr 20, 2018, at 12:13 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:
>> 
>> Applications don't get old.  They either do what they're supposed to do or 
>> they don't.   It has nothing to do with age.
> Remember Y2K?
> 
> -- gil
> 
> --
> 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Lester, Bob]

I agree with both you and Gil.  But, how many programmers in the 60s, 70s, even 
80s were thinking about Y2K?  Sure, the really good ones were, but what about 
the other 80%?

and, Y2K came off without a hitch...(FSVO - "hitch")

I love Fridays...

BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Porowski, Kenneth
Sent: Friday, April 20, 2018 1:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com) [ EXTERNAL ]

That was due to lack of foresight by the programmer not due to the age of the 
system.



This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, April 20, 2018 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day Due to 
New Hardware (nextgov.com)

On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:

>Applications don't get old.  They either do what they're supposed to do or 
>they don't.   It has nothing to do with age.
>
Remember Y2K?

-- gil

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

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Gibney, Dave]

IMO, it was often an explicit decision based on the cost of the technology of 
the time. Also, apparently more often the correct decision given the subsequent 
and apparently successful mitigation. 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Porowski, Kenneth
> Sent: Friday, April 20, 2018 12:20 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New
> Hardware (nextgov.com)
> 
> That was due to lack of foresight by the programmer not due to the age of
> the system.
> 
> 
> 
> This email message and any accompanying materials may contain proprietary,
> privileged and confidential information of CIT Group Inc. or its subsidiaries 
> or
> affiliates (collectively, “CIT”), and are intended solely for the recipient(s)
> named above.  If you are not the intended recipient of this communication,
> any use, disclosure, printing, copying or distribution, or reliance on the
> contents, of this communication is strictly prohibited.  CIT disclaims any
> liability for the review, retransmission, dissemination or other use of, or 
> the
> taking of any action in reliance upon, this communication by persons other
> than the intended recipient(s).  If you have received this communication in
> error, please reply to the sender advising of the error in transmission, and
> immediately delete and destroy the communication and any accompanying
> materials.  To the extent permitted by applicable law, CIT and others may
> inspect, review, monitor, analyze, copy, record and retain any
> communications sent from or received at this email address.
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Paul Gilmartin
> Sent: Friday, April 20, 2018 3:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day Due to
> New Hardware (nextgov.com)
> 
> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:
> 
> >Applications don't get old.  They either do what they're supposed to do or
> they don't.   It has nothing to do with age.
> >
> Remember Y2K?
> 
> -- gil
> 
> --
> 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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Porowski, Kenneth]

That was due to lack of foresight by the programmer not due to the age of the 
system.



This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, April 20, 2018 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day Due to 
New Hardware (nextgov.com)

On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:

>Applications don't get old.  They either do what they're supposed to do or 
>they don't.   It has nothing to do with age.
>
Remember Y2K?

-- gil

--
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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Paul Gilmartin]

On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote:

>Applications don't get old.  They either do what they're supposed to do or 
>they don't.   It has nothing to do with age.
> 
Remember Y2K?

-- gil

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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Frank Swarbrick]

Here's a somewhat interesting document: 
https://www.irs.gov/pub/irs-pia/imf_pia.pdf.
"IMF is a batch driven application that uses VSAM files."
Date of Approval: February 28, 2017 PIA ID Number: 2140 A 
...
Date of Approval: February 28, 2017 PIA ID Number: 2140 A. SYSTEM DESCRIPTION 
1. Enter the full name and acronym for the system, project, application and/or 
database.
www.irs.gov



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, April 19, 2018 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com)

On Thu, 19 Apr 2018 22:47:33 +, Nash, Jonathan S. wrote:

>IRS - 60-Year-Old IT System Failed on Tax Day
>Due to New Hardware
>
>By Aaron Boyd and Frank Konkel
>April 19, 2018 06:02 PM
>
>https://www.nextgov.com/it-modernization/2018/04/irs-60-year-old-it-system-failed-tax-day-due-new-hardware/147598/
>
>Congress and watchdogs have been warning the IRS to upgrade
>its systems for years.
>
>The Ieternal Revenue Service attributed the agency’s Tax Day
>crash to a piece of hardware supporting an IT system that is
>almost 60 years old.
>
>Called the Individual Master File, components of the system -
>including 20 million lines of computer code—date back to 1960,
>when John F. Kennedy was president.  ...
>
“There are two ways of constructing a software design: One way is
to make it so simple that there are obviously no deficiencies, and
the other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.”
― C.A.R. Hoare

Of course, it's much the fault of the Tax Code.

-- gil

--
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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Gerhard Adam]

Applications don't get old.  They either do what they're supposed to do or they 
don't.   It has nothing to do with age.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Smith, Nathan (ATLANTA, GA)
Sent: Friday, April 20, 2018 6:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com)

Why do people seem to ignore the fact that UNIX and the C Programming Language 
were being developed in 1969 and being used in the early '70s (thanks Bell 
Labs!)?  I don't see the mad rush to do away with *nix-based systems or 
applications written in C because they're "old".  Just because an application 
is "old" doesn't mean it's not being updated and enhanced.

Anthem, Inc.

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

Re: [EXTERNAL] Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Dyck, Lionel B. (TRA)]

FUD - pure and simple - used to convince IT management and decision makers that 
they are on the wrong side of the equation. Truth, facts, etc. don't fit that 
narrative.

--
Lionel B. Dyck (Contractor)  <
Mainframe Systems Programmer – RavenTek Solution Partners
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Smith, Nathan (ATLANTA, GA)
Sent: Friday, April 20, 2018 8:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to 
New Hardware (nextgov.com)

Why do people seem to ignore the fact that UNIX and the C Programming Language 
were being developed in 1969 and being used in the early '70s (thanks Bell 
Labs!)?  I don't see the mad rush to do away with *nix-based systems or 
applications written in C because they're "old".  Just because an application 
is "old" doesn't mean it's not being updated and enhanced.

Anthem, Inc.

Nathan A. Smith, Database Administrator Sr., Anthem Database Services
600 Peachtree St. NE, Main Drop GA1319-A154, Atlanta, GA 30308
O: (770) 519-6496 | M: (770) 519-6496
nathanael.sm...@anthem.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Friday, April 20, 2018 08:50
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com)

I have a theory that no news article yet written on IT is accurate (and maybe 
we could drop the "on IT").

Regardless, this one seems to entirely miss the point that *new* hardware had a 
problem, not the *old* software.  Not to mention that while being unable to 
accept payments and returns is bad for the government, it's merely somewhat 
annoying to taxpayers.  Extending by 24 hours because everyone waited until the 
last day to pay isn't really that big a deal.
Systems with one massive peak day per year are tough to manage.


On Thu, Apr 19, 2018 at 11:48 PM, Gerhard Adam  wrote:

> Well, it's rather obvious that the people that wrote this article are 
> about as ignorant as they come.
>

​sas​

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

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and may contain confidential and 
privileged information or may otherwise be protected by law. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, please contact the sender by reply e-mail and destroy all 
copies of the original message and any attachment thereto.

--
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: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Smith, Nathan (ATLANTA, GA)]

Why do people seem to ignore the fact that UNIX and the C Programming Language 
were being developed in 1969 and being used in the early '70s (thanks Bell 
Labs!)?  I don't see the mad rush to do away with *nix-based systems or 
applications written in C because they're "old".  Just because an application 
is "old" doesn't mean it's not being updated and enhanced.

Anthem, Inc.

Nathan A. Smith, Database Administrator Sr., Anthem Database Services
600 Peachtree St. NE, Main Drop GA1319-A154, Atlanta, GA 30308
O: (770) 519-6496 | M: (770) 519-6496
nathanael.sm...@anthem.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Steve Smith
Sent: Friday, April 20, 2018 08:50
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware 
(nextgov.com)

I have a theory that no news article yet written on IT is accurate (and maybe 
we could drop the "on IT").

Regardless, this one seems to entirely miss the point that *new* hardware had a 
problem, not the *old* software.  Not to mention that while being unable to 
accept payments and returns is bad for the government, it's merely somewhat 
annoying to taxpayers.  Extending by 24 hours because everyone waited until the 
last day to pay isn't really that big a deal.
Systems with one massive peak day per year are tough to manage.


On Thu, Apr 19, 2018 at 11:48 PM, Gerhard Adam  wrote:

> Well, it's rather obvious that the people that wrote this article are
> about as ignorant as they come.
>

​sas​

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

CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and may contain confidential
and privileged information or may otherwise be protected by law. Any
unauthorized review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message and any attachment thereto.

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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Steve Smith]

I have a theory that no news article yet written on IT is accurate (and
maybe we could drop the "on IT").

Regardless, this one seems to entirely miss the point that *new* hardware
had a problem, not the *old* software.  Not to mention that while being
unable to accept payments and returns is bad for the government, it's
merely somewhat annoying to taxpayers.  Extending by 24 hours because
everyone waited until the last day to pay isn't really that big a deal.
Systems with one massive peak day per year are tough to manage.


On Thu, Apr 19, 2018 at 11:48 PM, Gerhard Adam  wrote:

> Well, it's rather obvious that the people that wrote this article are
> about as ignorant as they come.
>

​sas​

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

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Gerhard Adam]

Well, it's rather obvious that the people that wrote this article are about as 
ignorant as they come.



Sent from my iPhone

> On Apr 19, 2018, at 3:47 PM, Nash, Jonathan S. 
> <01abdcef2f3c-dmarc-requ...@listserv.ua.edu> wrote:
> 
> IRS - 60-Year-Old IT System Failed on Tax Day
> Due to New Hardware
> 
> By Aaron Boyd and Frank Konkel
> April 19, 2018 06:02 PM
> 
> https://www.nextgov.com/it-modernization/2018/04/irs-60-year-old-it-system-failed-tax-day-due-new-hardware/147598/
> 
> Congress and watchdogs have been warning the IRS to upgrade
> its systems for years.
> 
> The Internal Revenue Service attributed the agency’s Tax Day
> crash to a piece of hardware supporting an IT system that is
> almost 60 years old.
> 
> Called the Individual Master File, components of the system -
> including 20 million lines of computer code—date back to 1960,
> when John F. Kennedy was president.
> 
> IRS told Nextgov 18-month-old hardware supporting the
> Individual Master File experienced a caching issue causing
> the system to fail. The failure disrupted almost all other
> services and systems IRS provides because those systems
> ingest data from the Individual Master File. When those
> systems—such as Direct Pay and the structured payments
> portal—called to the Individual Master File mainframe and
> got no response, they too failed.
> 
> Despite repeated warnings from the Government Accountability
> Office and Congress, IRS plans to modernize the system are
> at least six years behind schedule and several hundred
> million dollars over budget.
> 
> This was our biggest fear about one of these
> mission-critical systems crashing, Dave Powner, GAO's
> director of IT management issues, told Nextgov Thursday.
> Fortunately, it wasn't down for a long period of time, so
> in that way, we dodged a bullet.
> 
> Still, the crash forced the IRS to extend the tax filing
> deadline one day, delaying some 14 million submissions. It
> could be several years before the Individual Master File is
> fully modernized and rid of 1960s-era technology.
> 
> To address the risk of a system failure, the IRS has a plan
> to modernize two core components of the IMF by 2021,
> followed by a year of parallel validation before retiring
> those components in 2022,” the IRS told Nextgov in March,
> before the crash occurred. That timeline could slip because
> the IRS says it needs to hire at least 50 additional
> employees—while backfilling any attrition—plus an additional
> $85 million per year in annual non-labor funding over the
> next five years. The president’s fiscal 2018 budget request
> called for a $239 million reduction in funding for the IRS,
> which has faced numerous cuts in recent years.
> 
> Since Republicans gained control of the House of
> Representatives in 2010, their partisan attacks have left
> the IRS with nearly 10,000 fewer customer service
> representatives to assist taxpayers and a patchwork of IT
> systems, some dating back to the Kennedy Administration,
> which is ultimately harming all taxpayers,” Rep. Gerry
> Connolly, D-Va., told Nextgov.
> 
> However, the Republican-led House ratified a package of nine
> IRS reform bills following the Tax Day crash that could amp
> up IRS’ modernization efforts. The bills, including the
> 21st-Century IRS Act and the Taxpayer First Act, will stress
> improving the customer experience for taxpayers as well as
> modernizing technology across the agency. The reform package
> was ushered in by the House Ways and Means committee,
> chaired by Rep. Kevin Brady, R-Texas.
> 
> A new tax code calls for a new tax administrator, and we
> have worked together so that the IRS can be transformed into
> an agency with a singular mission: taxpayer first, Brady
> said in a statement.
> 
> One of the bills will require IRS to compile a plan to
> enhance agency technology and customer service. That plan is
> due to Congress by September.
> 
> The Individual Master File contains data from 1 billion
> taxpayer accounts dating back several decades and is the
> chief IRS application responsible for receiving 100 million
> Americans’ individual taxpayer data and dispensing refunds.
> IRS first attempted to replace the system with a modernized
> Customer Account Data Engine, but that effort was canceled
> in 2009. A delivery date for CADE 2, the IRS’ subsequent
> modernization effort, has slipped several years even as
> contractors working on the project have earned as much as
> $290 million.
> 
> We still have not seen a solid plan in place, Powner told
> Nextgov. GAO identified the Individual Master File as the
> oldest technology system still operational in government in
> 2016.
> 
> --
> 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 / 

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Paul Gilmartin]

On Thu, 19 Apr 2018 22:47:33 +, Nash, Jonathan S. wrote:

>IRS - 60-Year-Old IT System Failed on Tax Day
>Due to New Hardware
>
>By Aaron Boyd and Frank Konkel
>April 19, 2018 06:02 PM
>
>https://www.nextgov.com/it-modernization/2018/04/irs-60-year-old-it-system-failed-tax-day-due-new-hardware/147598/
>
>Congress and watchdogs have been warning the IRS to upgrade
>its systems for years.
>
>The Ieternal Revenue Service attributed the agency’s Tax Day
>crash to a piece of hardware supporting an IT system that is
>almost 60 years old.
>
>Called the Individual Master File, components of the system -
>including 20 million lines of computer code—date back to 1960,
>when John F. Kennedy was president.  ...
>
“There are two ways of constructing a software design: One way is
to make it so simple that there are obviously no deficiencies, and
the other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult.” 
― C.A.R. Hoare

Of course, it's much the fault of the Tax Code.

-- gil

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

IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

[Nash, Jonathan S.]

IRS - 60-Year-Old IT System Failed on Tax Day
Due to New Hardware

By Aaron Boyd and Frank Konkel
April 19, 2018 06:02 PM

https://www.nextgov.com/it-modernization/2018/04/irs-60-year-old-it-system-failed-tax-day-due-new-hardware/147598/

Congress and watchdogs have been warning the IRS to upgrade
its systems for years.

The Internal Revenue Service attributed the agency’s Tax Day
crash to a piece of hardware supporting an IT system that is
almost 60 years old.

Called the Individual Master File, components of the system -
including 20 million lines of computer code—date back to 1960,
when John F. Kennedy was president.

IRS told Nextgov 18-month-old hardware supporting the
Individual Master File experienced a caching issue causing
the system to fail. The failure disrupted almost all other
services and systems IRS provides because those systems
ingest data from the Individual Master File. When those
systems—such as Direct Pay and the structured payments
portal—called to the Individual Master File mainframe and
got no response, they too failed.

Despite repeated warnings from the Government Accountability
Office and Congress, IRS plans to modernize the system are
at least six years behind schedule and several hundred
million dollars over budget.

This was our biggest fear about one of these
mission-critical systems crashing, Dave Powner, GAO's
director of IT management issues, told Nextgov Thursday.
Fortunately, it wasn't down for a long period of time, so
in that way, we dodged a bullet.

Still, the crash forced the IRS to extend the tax filing
deadline one day, delaying some 14 million submissions. It
could be several years before the Individual Master File is
fully modernized and rid of 1960s-era technology.

To address the risk of a system failure, the IRS has a plan
to modernize two core components of the IMF by 2021,
followed by a year of parallel validation before retiring
those components in 2022,” the IRS told Nextgov in March,
before the crash occurred. That timeline could slip because
the IRS says it needs to hire at least 50 additional
employees—while backfilling any attrition—plus an additional
$85 million per year in annual non-labor funding over the
next five years. The president’s fiscal 2018 budget request
called for a $239 million reduction in funding for the IRS,
which has faced numerous cuts in recent years.

Since Republicans gained control of the House of
Representatives in 2010, their partisan attacks have left
the IRS with nearly 10,000 fewer customer service
representatives to assist taxpayers and a patchwork of IT
systems, some dating back to the Kennedy Administration,
which is ultimately harming all taxpayers,” Rep. Gerry
Connolly, D-Va., told Nextgov.

However, the Republican-led House ratified a package of nine
IRS reform bills following the Tax Day crash that could amp
up IRS’ modernization efforts. The bills, including the
21st-Century IRS Act and the Taxpayer First Act, will stress
improving the customer experience for taxpayers as well as
modernizing technology across the agency. The reform package
was ushered in by the House Ways and Means committee,
chaired by Rep. Kevin Brady, R-Texas.

A new tax code calls for a new tax administrator, and we
have worked together so that the IRS can be transformed into
an agency with a singular mission: taxpayer first, Brady
said in a statement.

One of the bills will require IRS to compile a plan to
enhance agency technology and customer service. That plan is
due to Congress by September.

The Individual Master File contains data from 1 billion
taxpayer accounts dating back several decades and is the
chief IRS application responsible for receiving 100 million
Americans’ individual taxpayer data and dispensing refunds.
IRS first attempted to replace the system with a modernized
Customer Account Data Engine, but that effort was canceled
in 2009. A delivery date for CADE 2, the IRS’ subsequent
modernization effort, has slipped several years even as
contractors working on the project have earned as much as
$290 million.

We still have not seen a solid plan in place, Powner told
Nextgov. GAO identified the Individual Master File as the
oldest technology system still operational in government in
2016.

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