Re: Somewhat Interesting Mainframe Article

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

Clark:

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

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

Re: Somewhat Interesting Mainframe Article

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

>There are 15 trillion lines of COBOL   

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

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

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

Re: ShopZ order response

2017-10-14 Thread Phil Smith 
Ed Gould wrote:
>I was never in the loop about Sterling Forest, but didn't they have a fire 
>that ruined pretty much all of their tapes?
>This had to be in the 1980's (Think). I actually ordered the source from them 
>one time and I think it was a renumber subcommand of basic.

No idea, sorry!

And he also wrote:
>About 20 years or so maybe longer 30? anyway, A contractor working for one of 
>the large aero space companies, came to Guide with a large box of tapes. On 
>each tape was a copy of IBM's compiler that IBM used to create source (PLS if 
>I am not mistaken). I wasn't interested but when he opened the box after the 
>session I have never seen a black Friday sale but one of the women there said 
>it reminded her of one.
>My memory is stretching here but somehow the legal department got involved and 
>they tracked down 30 or the 32 tapes.
>No one that got one of the tapes was willing to talk about it at the next 
>Guide. There were whispers of the FBI but no one would confirm it.

In the early 90s, IBM PartnerWorld went pay-to-play briefly--$5K/year IIRC. As 
part of that new offering, we could get the PLX (PL/X?) compiler. So I said 
sure, send it to me.

A few months later, they revamped the program again and said they were 
refunding the $5K. Except...I got to go to my VP and say "I have good news and 
bad news, and they're the same news: we're getting MOST of that $5K back". We 
lost about a third of it because PWD had to pay Raleigh for the compiler. Of 
course we never actually used it.

Hmm, as I finish typing this, it feels like maybe I've already shared this 
anecdote. Apologies if so.

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

Re: CCKD (was: Transfer a large number of sequential file from mainframe ...)

2017-10-14 Thread Graham Harris 
>o Is there a z/OS utility to generate a CCKD?  Or, would it be necessary
to run
>  Hecules in a Linux guest to which the source volume could be ATTACHed?

http://www.bsp-gmbh.com/turnkey/cookbook/hercules/cckddasd.html#cckddump

On 12 October 2017 at 17:26, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Thu, 12 Oct 2017 03:54:44 +, W Mainframe wrote:
>
> >A suggestion...Could be better or not... You could try... Convert your
> volume to a cckd image using Hercules utilies. Once they are converted, you
> will be take advantage of compression and time to this transfer. I did same
> thing some thing, with success. Btw there is one a problem, you need to
> move your datasets to a same volume.. Make sense?
> >
> A clever idea!  That would contain all the data and all the
> formatting/metadata,
> to be unwound at leisure at the receiving end.  Somewhat like a .ISO.
>
> Would AWSTAPE provide similar benefit.  Would need to unload PDS and VSAM.
>
> Otherwise:
>
> o Is there a z/OS utility to generate a CCKD?  Or, would it be necessary
> to run
>   Hecules in a Linux guest to which the source volume could be ATTACHed?
>
> o Classic 3390 volumes are pretty small by today's conventions.  Can CCKD
>   handle EAV?  What are the z/OS restrictions on EAV?
>
> o What about PDSE?  The format is not generally documented.  (But has it
> been
> reverse-enginered?)  (But OP specified sequential.)
>
> o Big-endian; little-endian.  A shame, resulting in impossibility of
> NFS-sharing a
>   CCKD archive among z, Sparc, Intel, ARM, ...  AWSTAPE wisely is uniformly
>   little-endian, leaving it to big-endian hosts to adapt on the fly.
>
> -- 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: Somewhat Interesting Mainframe Article

2017-10-14 Thread Paul Gilmartin 
On Sat, 14 Oct 2017 17:40:19 -0500, Steve Beaver wrote:

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

Cite?

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

-- gil

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

Re: Somewhat Interesting Mainframe Article

2017-10-14 Thread Steve Beaver 
There are 15 trillion lines of COBOL   

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

Tom,

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

Scott

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

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

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

Re: Somewhat Interesting Mainframe Article

2017-10-14 Thread scott Ford 
Tom,

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

Scott

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

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

Re: Somewhat Interesting Mainframe Article

2017-10-14 Thread Tom Brennan 

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

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


esst...@juno.com wrote:

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

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




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

Re: ShopZ order response

2017-10-14 Thread David W Noon 
On Fri, 13 Oct 2017 20:46:36 -0400, Tony Harminc (t...@harminc.net)
wrote about "Re: ShopZ order response" (in
):

> On 13 October 2017 at 18:47, Phil Smith III  wrote:
> 
>> Anyone know if Sterling Forest still has 3420s? Last time I was there
>> (2004?) they did, and even a 7-track drive IIRC.
> 
> Also in 2004 I was surprised to see a short string of 3420 drives, all
> powered up and lights on, at one of our UK banking customers. I asked,
> and it seems they were used only for data exchange. A nightly courier
> would arrive from each of the other big banks with tapes, and be
> dispatched with the ones from this bank. I had a vision, perhaps not
> inaccurate, of each bank having such a dusty set of drives used only
> for the same purpose.
> 
> Maybe someone at a UK bank can tell us if that scheme survives today...

I can't vouch for today, but the use of 9-track, reel-to-reel tapes was
the standard back in the late 1990's.

>From 1996 to 1999 I was working at Lloyd's Bank in London. I was working
in a section called Autoclearings and our batch jobs wrote and read
these tapes.

The Bank of England ran a clearing house through which all financial
transfers were made between clearing banks. The concrete bunker was in
Uxbridge. All the clearing banks would write their pending transactions
to 9-track tape (with ANSI labels and RECFM=DB ASCII records). These
tapes would then be  put into an armoured car and sent off to Uxbridge.
Tapes containing completed transactions would be sent back to the banks
so they could reconcile their accounts.
In 1998 the Bank of England announced that they had a new system called
High Speed Transfer (HST). This consisted of custom terminals with
hardware cryptography connected to leased lines ... that went to
Uxbridge. The data transmissions were made up of ANSI format HDR1 and
HDR2 records, a stream of ASCII data records in RECFM=DB format,
followed by ANSI format TLR1 and TLR2 records. This was not warmly
received by the clearing banks as state-of-the-art technology.

I find it a little surprising that reel-to-reel tape was still being
used in 2004 but, given that the HST alternative was really no better, I
guess we should not be really surprised.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

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

Re: ShopZ order response

2017-10-14 Thread Phil Smith 
Tony Harminc wrote:
>Also in 2004 I was surprised to see a short string of 3420 drives, all
>powered up and lights on, at one of our UK banking customers. I asked,
>and it seems they were used only for data exchange. A nightly courier
>would arrive from each of the other big banks with tapes, and be
>dispatched with the ones from this bank. I had a vision, perhaps not
>inaccurate, of each bank having such a dusty set of drives used only
>for the same purpose.

>Maybe someone at a UK bank can tell us if that scheme survives today...

Heh, I believe that. My dad was doing camera-ready copy in the late 70s and 
early 80s--long before it was common--and had to deliver it on 8" floppies. 
Mutual Life of Canada ("MuCana") was still using 8" floppies on a daily basis, 
and he somehow made a connection there and would run a 3420 over and get back a 
floppy. This went on MUCH longer than sanity would suggest.

"If it ain't broke, don't fix it"; such things usually get fixed when it does 
break, and either parts are no longer available or the only guy who knew how to 
fix it is retired or DEAD. Like the dude in Pennsylvania who was still 
servicing keypunches in the early 2000s. That stopped when he passed away--at 
86.

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

Somewhat Interesting Mainframe Article

2017-10-14 Thread esst...@juno.com 
https://www.infoq.com/articles/retiring-mainframe-programmers

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

Re: git, z/OS and COBOL

2017-10-14 Thread scott Ford 
We use GIT for source as I stated above. I feel the learning curve is a bit
much.
But there are a couple interactive learning tutorials that a feel are good.

The 'fly in the ointment'  is when you have done a 'commit,push' and have
one approval for a pull request.
Like any other source mgmt system you have to know how to back out a PR for
example. I am still learning.

The diff and blame functions using GIT with Bitbucket are great...


Scott

On Fri, Oct 13, 2017 at 8:40 AM David Crayford  wrote:

> Thanks Jesse,
>
> That's great stuff! The README.TXT gave me directions on how to setup a
> Jenkins slave on z/OS. We're going to use this starting next week.
>
>
> On 12/10/2017 11:28 PM, Jesse 1 Robinson wrote:
> > Today LinkedIn news note points to an article on Git for z/OS by
> Rosalind Radcliffe, who has been speaking at SHARE for some time on its
> virtues. This very long URL goes through LinkedIn.
> >
> >
> https://www.linkedin.com/pulse/git-zos-development-how-do-you-build-now-can-rosalind-radcliffe/?trk=eml-email_feed_ecosystem_digest_01-recommended_articles-7-PBYN=AQFJkRF5baAZ4A=fromEmail=3GEOaGOlxTtnY1
> >
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > 626-543-6132 Office ⇐=== NEW
> > robin...@sce.com
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of David Crayford
> > Sent: Thursday, October 12, 2017 3:56 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: git, z/OS and COBOL
> >
> > On 11/10/2017 9:48 PM, Pew, Curtis G wrote:
> >>> I'd like to run into the problems before the applications people have
> a chance to hit it so we can head that all off.
> >>>
> >>> And I'd love to know the answers to this before the POC dies. So I am
> very interested in this thread.
> >> I think all the discussion of line numbering is a bit of a red herring.
> You can still use git on files that have line numbers. It may have to keep
> track of “changes” that don’t really change anything, and it may require
> additional storage and processing, but git still works.
> >>
> >> In most cases line numbers imbedded in files are relics of older
> technologies, and you’re better off eliminating them. But if there’s a case
> where you do still need them, it won’t prevent current technology from
> doing its thing.
> >>
> >> (In case you couldn’t tell, I’m a big fan of git. I don’t think anyone
> >> who embraces it will regret it.)
> > Indeed! If you can ditch those relics all the better. I'm a big fan of
> git too. It's revolutionized our workflows on z/OS. We use bitbucket and
> Jira from Atlassian which integrate beautifully. We use agile and raise a
> Jira for each feature branch. This gives us visibility to every line of
> code that has been changed for each feature. We do code reviews on pull
> requests which is great for QA. Code reviews find bugs early and we've
> found find more bugs than systems testing.
> >
> >
> > --
> > 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
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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