Sent from my iPad > On Mar 27, 2017, at 12:00 AM, IBM-MAIN automatic digest system > <[email protected]> wrote: > > There are 16 messages totaling 872 lines in this issue. > > Topics of the day: > > 1. GREAT presentation on the history of the mainframe > 2. Migrating Cobol (7) > 3. ComputerWorld Says: Cobol plays major role in U.S. government breaches (2) > 4. Help deleting file (6) > > ---------------------------------------------------------------------- > > Date: Sat, 25 Mar 2017 21:22:12 -0700 > From: Anne & Lynn Wheeler <[email protected]> > Subject: Re: GREAT presentation on the history of the mainframe > > [email protected] (Tony Harminc) writes: >> Boeblingen got their hands slapped for anti-trust reasons for moving >> the controllers inside (shades of the 2319 disk), or because corporate >> inherently favoured Endicott over Boeblingen (and presumably POK over >> both)? Or something else? > > re: > http://www.garlic.com/~lynn/2017.html#74 The ICL 2900 > http://www.garlic.com/~lynn/2017.html#86 GREAT presentation on the history of > the mainframe > > memory bus with generalized 9-positions for microprocessors (& > microprocessor all the same) was much more advanced design than other > IBM systems were (suppose to be) doing. > > which in part, made it straight-forward to do the 5-way SMP, past posts > http://www.garlic.com/~lynn/submain.html#bounce > > note some of this would have been similar (but different) to effort > later in the 70s to migrate the large number of different internal > microprocessors to 801/risc (Illiad). past 801 posts > http://www.garlic.com/~lynn/subtopic.html#801 > > because of the difficulty having all the unique development and > operations for each unique microprocessor. > > I've previously told story after working on ECPS for endicott and 5-way > SMP for Boeblingen, I got involved in doing 16-way SMP which lots of > people thought was really great ... even getting 3033 processor > engineers to work on it in their spare time (lot more interesting than > remapping 168-3 logic to 20% faster chips) That is until somebody > informed the head of POK that it could be decades before the POK > favorite son operating system had (effective) 16-way support ... at > which time some of us were invited to never visit POK again (and 3033 > processor engineers to stop being distracted). IBM eventually ships > 16-way system more than two decades later ... recent reference > http://www.garlic.com/~lynn/2017c.html#30 The ICL 2900 > > past SMP posts > http://www.garlic.com/~lynn/subtopic.html#smp > > -- > virtualization experience starting Jan1968, online at home since Mar1970 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 13:46:36 +0200 > From: James Wellingtin <[email protected]> > Subject: Migrating Cobol > > Hey > I have posted this to the cicslist , and someone there asked me to post it > to this group as well for feedbackj > > We are very soon to migrate from COBOL ENT V4.2.0 to either Cobol 5.2. or > 6.1 > > Do anybody have made any experience in doing that > > Have you experienced any problem ? > Please describe > What have been the main issues > Are there speciel things which should be taken care of . > > All kind of knowledge and experience would be appreciated. > > What version of Cobol are you running > > Now it is nearly a year ago Cobol 6.1 went GA > Does anybody have migrated to that, and is it worth going to that version , > or should you order 5.2 instead > > Regards > James > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 07:57:42 -0400 > From: Mitch Mccluhan <[email protected]> > Subject: Re: Migrating Cobol > > ...contact me. We've done it a number if times. > > Mitch > > Mitch Mccluhan > [email protected] > > On Sunday, March 26, 2017 James Wellingtin <[email protected]> wrote: > Hey > I have posted this to the cicslist , and someone there asked me to post it > to this group as well for feedbackj > > We are very soon to migrate from COBOL ENT V4.2.0 to either Cobol 5.2. or > 6.1 > > Do anybody have made any experience in doing that > > Have you experienced any problem ? > Please describe > What have been the main issues > Are there speciel things which should be taken care of . > > All kind of knowledge and experience would be appreciated. > > What version of Cobol are you running > > Now it is nearly a year ago Cobol 6.1 went GA > Does anybody have migrated to that, and is it worth going to that version , > or should you order 5.2 instead > > Regards > James > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 08:14:32 -0400 > From: Charles Mills <[email protected]> > Subject: Re: Migrating Cobol > > My *impression* is that many are skipping 5 and going straight to 6.1. > > CharlesSent from a mobile; please excuse the brevity. > -------- Original message --------From: James Wellingtin > <[email protected]> Date: 3/26/17 7:46 AM (GMT-05:00) To: > [email protected] Subject: Migrating Cobol > Hey > I have posted this to the cicslist , and someone there asked me to post it > to this group as well for feedbackj > > We are very soon to migrate from COBOL ENT V4.2.0 to either Cobol 5.2. or > 6.1 > > Do anybody have made any experience in doing that > > Have you experienced any problem ? > Please describe > What have been the main issues > Are there speciel things which should be taken care of . > > All kind of knowledge and experience would be appreciated. > > What version of Cobol are you running > > Now it is nearly a year ago Cobol 6.1 went GA > Does anybody have migrated to that, and is it worth going to that version , > or should you order 5.2 instead > > Regards > James > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 12:30:23 +0000 > From: Dan Little <[email protected]> > Subject: Re: Migrating Cobol > > I don't think you can order 5.2 any more. I recommend 6.1 especially if > you have large programs as the compiler is 64-bit and can compile much > larger programs. > > > Dan > > > >> On Sun, Mar 26, 2017 at 08:28 Charles Mills <[email protected]> wrote: >> >> My *impression* is that many are skipping 5 and going straight to 6.1. >> >> CharlesSent from a mobile; please excuse the brevity. >> -------- Original message --------From: James Wellingtin < >> [email protected]> Date: 3/26/17 7:46 AM (GMT-05:00) To: >> [email protected] Subject: Migrating Cobol >> Hey >> I have posted this to the cicslist , and someone there asked me to post it >> to this group as well for feedbackj >> >> We are very soon to migrate from COBOL ENT V4.2.0 to either Cobol 5.2. or >> 6.1 >> >> Do anybody have made any experience in doing that >> >> Have you experienced any problem ? >> Please describe >> What have been the main issues >> Are there speciel things which should be taken care of . >> >> All kind of knowledge and experience would be appreciated. >> >> What version of Cobol are you running >> >> Now it is nearly a year ago Cobol 6.1 went GA >> Does anybody have migrated to that, and is it worth going to that version , >> or should you order 5.2 instead >> >> Regards >> James >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 10:17:21 -0500 > From: Bill Woodger <[email protected]> > Subject: Re: Migrating Cobol > > If you have very large programs and you want to optimise them to Level 1 or > Level 2, then Enterprise COBOL V6.1 is your best bet. The optimiszer was > re-written with 64-bit addressing and is now much more comfortable with large > programs (which may just fail to compile with V5.2). > > V6.1 is now "continuous delivery". Meaning new functionality, not just fixes > and retro-fitting, can and is being supplied by PTF. > > Consider use of the Automatic Binary Optimizer (ABO). This can allow your > COBOL programs to benefit from z/ARCH instructions without needing to be > recompiled. This can allow you to rework your planning. > > Biggest problem seems to have been the need for PDSE: no more loadmodules, > now Program Objects, which must be in a PDSE. > > ABO again offers some extra flexibility by not requiring PDSE for all > executables. > > IBM has done a lot of work over the last few months to reproduce V4.2 output > where the results expected are "undefined" across all compilers, but have a > specific outcome under a particular compiler. > > You could chose ABO for "everything" and V5/v6 for new > development/maintenance (an incremental "migration") through to Big Bang, > V5/V6-only, and devil take the hind-most. Or anything in between. > > ABO has not been around long, and V1.2 only since last November. > > ABO gives you some new ways to do migration, but be aware that there are > still discussions (including on this list) as to how much testing is required > for an ABO over a recompile. Ask your friendly IBM rep if you can talk to the > ABO people in Markham about your specific site :-) > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 15:49:54 +0000 > From: Jesse 1 Robinson <[email protected]> > Subject: Re: Migrating Cobol > > The question of 'how much testing with ABO' is entirely cultural. No > technical expert can provide an answer satisfactory to all. At one end, you > can argue for minimal testing because application code has not changed, only > the executables. How many shops insist on extensive testing for updates to > LE? That's the executable side of COBOL after all. We test for compiler > changes but seldom if ever for LE PTFs or even what comes with the next z/OS. > > At the other end you have to deal with application programmers' unease at > changes outside their control. In my first IT job, I worked in an application > unit that eschewed dynamic run-time loads by running a 'super link' that > pulled in all available load modules to form a single large executable. They > did not want any 'surprises' at run time. That was long ago, but I suspect > that the same mentality still prevails in many shops. > > We haven't set off down the yellow-brick ABO road, so it's hard to gauge how > much angst we'll actually have to overcome. I'm pretty sure it won't be > trivial. > > . > . > 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 > [email protected] > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Bill Woodger > Sent: Sunday, March 26, 2017 8:17 AM > To: [email protected] > Subject: (External):Re: Migrating Cobol > > If you have very large programs and you want to optimise them to Level 1 or > Level 2, then Enterprise COBOL V6.1 is your best bet. The optimiszer was > re-written with 64-bit addressing and is now much more comfortable with large > programs (which may just fail to compile with V5.2). > > V6.1 is now "continuous delivery". Meaning new functionality, not just fixes > and retro-fitting, can and is being supplied by PTF. > > Consider use of the Automatic Binary Optimizer (ABO). This can allow your > COBOL programs to benefit from z/ARCH instructions without needing to be > recompiled. This can allow you to rework your planning. > > Biggest problem seems to have been the need for PDSE: no more loadmodules, > now Program Objects, which must be in a PDSE. > > ABO again offers some extra flexibility by not requiring PDSE for all > executables. > > IBM has done a lot of work over the last few months to reproduce V4.2 output > where the results expected are "undefined" across all compilers, but have a > specific outcome under a particular compiler. > > You could chose ABO for "everything" and V5/v6 for new > development/maintenance (an incremental "migration") through to Big Bang, > V5/V6-only, and devil take the hind-most. Or anything in between. > > ABO has not been around long, and V1.2 only since last November. > > ABO gives you some new ways to do migration, but be aware that there are > still discussions (including on this list) as to how much testing is required > for an ABO over a recompile. Ask your friendly IBM rep if you can talk to the > ABO people in Markham about your specific site :-) > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 11:27:07 -0500 > From: Bill Woodger <[email protected]> > Subject: Re: Migrating Cobol > > Danger of this becoming another ABO thread in disguise :-) > > The question of the testing of ABO is not entirely cultural, or not > necessarily so. Nor necessarily "compliance". There can be a technical basis > on which to make decisions, which cultural and compliance issues may make > moot. I'm keen to poke for the technical basis, of which there are not much > more than hints and generalisations for now :-) > > It's like developing a strain of peas which pick themselves when ready, pack > themselves and stack themselves in boxes on the trailer. So will stick to > "the One True Way to cultivate peas", some will stick to "the only way the > rules allow to cultivate peas". Some will get on with more interesting stuff > whilst the peas look after themselves. That latter group will be small if > there are no detailed instructions on the sacks of seed. > > IBM's intention going forward is that ABO and Enterprise COBOL are a > complimentary package. New ARCH level, new compiler (or PTF to existing > compiler), new ABO. You don't need to recompile everything to use the new > instructions immediately, you can ABO (even perhaps "on the fly"). New > development/maintenance uses the new compiler. "Migration" becomes... > > A cultural and real-world (compliance) impact for sure, but if the technical > basis has no more known grounding than the Witchdoctory One True Way then it > won't happen on any scale. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 16:45:00 +0000 > From: scott Ford <[email protected]> > Subject: Re: ComputerWorld Says: Cobol plays major role in U.S. government > breaches > > Bravo Phil and Tim from IBM. In my experience with NYC Stock Exchange and > too many Brokerage houses to count, all of these installations had very > tight internal/ external security. Including multiple firewalls to enter > the MF domains. Once in the MF domain, the security subsystem was tightly > controlled. > > Scott > > On Fri, Mar 24, 2017 at 1:12 PM Michael Seeman <[email protected]> > wrote: > >> Some articles posted regarding the 2015 OPM Breach at the Department of >> the Interior Data Center implied that DOI Mainframes were hacked. This is >> not the case. >> >> >> >> ---------------------------------------------------------------------- >> >> For IBM-MAIN subscribe / signoff / archive access instructions, >> >> send email to [email protected] with the message: INFO IBM-MAIN >> >> -- > Scott Ford > IDMWORKS > z/OS Development > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 17:27:29 -0400 > From: Joseph Reichman <[email protected]> > Subject: Help deleting file > > Hi > > I'm getting a 213-04 abend on my ispf profile > Dataset > > It's seems to be a catch-22 where I can't delete > As the system cannot find it > > And I cannot allocate because the system says it's a duplicate dataset > Doing a 3.4 I can see what pack it's on > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Mon, 27 Mar 2017 00:37:02 +0300 > From: Binyamin Dissen <[email protected]> > Subject: Re: Help deleting file > > Uncatalog/recatalog > > On Sun, 26 Mar 2017 17:27:29 -0400 Joseph Reichman <[email protected]> > wrote: > > :>Hi > :> > :>I'm getting a 213-04 abend on my ispf profile > :>Dataset > :> > :>It's seems to be a catch-22 where I can't delete > :>As the system cannot find it > :> > :>And I cannot allocate because the system says it's a duplicate dataset > :>Doing a 3.4 I can see what pack it's on > :> > :>---------------------------------------------------------------------- > :>For IBM-MAIN subscribe / signoff / archive access instructions, > :>send email to [email protected] with the message: INFO IBM-MAIN > > -- > Binyamin Dissen <[email protected]> > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 17:54:14 -0400 > From: Joseph Reichman <[email protected]> > Subject: Re: Help deleting file > > I was able to uncatalog > But not catalog > > Maybe the entry was just in the catalog and didn't > Exist > > Subsqently I allocated it > Thank you very much > > > >> On Mar 26, 2017, at 5:37 PM, Binyamin Dissen <[email protected]> >> wrote: >> >> Uncatalog/recatalog >> >> On Sun, 26 Mar 2017 17:27:29 -0400 Joseph Reichman <[email protected]> >> wrote: >> >> :>Hi >> :> >> :>I'm getting a 213-04 abend on my ispf profile >> :>Dataset >> :> >> :>It's seems to be a catch-22 where I can't delete >> :>As the system cannot find it >> :> >> :>And I cannot allocate because the system says it's a duplicate dataset >> :>Doing a 3.4 I can see what pack it's on >> :> >> :>---------------------------------------------------------------------- >> :>For IBM-MAIN subscribe / signoff / archive access instructions, >> :>send email to [email protected] with the message: INFO IBM-MAIN >> >> -- >> Binyamin Dissen <[email protected]> >> http://www.dissensoftware.com >> >> Director, Dissen Software, Bar & Grill - Israel >> >> >> Should you use the mailblocks package and expect a response from me, >> you should preauthorize the dissensoftware.com domain. >> >> I very rarely bother responding to challenge/response systems, >> especially those from irresponsible companies. >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 15:01:20 -0700 > From: Lizette Koehler <[email protected]> > Subject: Re: Help deleting file > > Using 3.4 you can search the catalog (no volser) or volumes (complete or > partial > volser) > > If your dataset is cataloged but incorrectly > > Go to TSO READY PROMPT > Delete 'dsn' NOSCRATCH NOPURGE <--- This uncatalogs the dataset > DELETE 'dsn' <--- this deletes the catalog entry > > Then issue > > ALLOC DD(DMYTMP) DA('your ispf dataset name') CYLINDERS SPACE(1 1) BLOCKS(10) > RECFM(F B) and so forth. > > Then issue ISPF. > > If you are in ISPF and are able to create a NEW ispf dataset, do that. > > Then go to the ready prompt and issue > > 1) FREE DD(ISPPROF) > 2) ALLOC DD(ISPPROF)DA('new dataset name here') SHR > > Then access ISPF > > You probably should look at the ISPF User's Guide volumes - they can be quiet > helpful. > > > Lizette > > >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] On >> Behalf Of Joseph Reichman >> Sent: Sunday, March 26, 2017 2:27 PM >> To: [email protected] >> Subject: Help deleting file >> >> Hi >> >> I'm getting a 213-04 abend on my ispf profile Dataset >> >> It's seems to be a catch-22 where I can't delete As the system cannot find it >> >> And I cannot allocate because the system says it's a duplicate dataset Doing >> a >> 3.4 I can see what pack it's on > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 18:03:31 -0400 > From: Joseph Reichman <[email protected]> > Subject: Re: Help deleting file > > Thank you > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Lizette Koehler > Sent: Sunday, March 26, 2017 6:01 PM > To: [email protected] > Subject: Re: Help deleting file > > Using 3.4 you can search the catalog (no volser) or volumes (complete or > partial > volser) > > If your dataset is cataloged but incorrectly > > Go to TSO READY PROMPT > Delete 'dsn' NOSCRATCH NOPURGE <--- This uncatalogs the dataset > DELETE 'dsn' <--- this deletes the catalog entry > > Then issue > > ALLOC DD(DMYTMP) DA('your ispf dataset name') CYLINDERS SPACE(1 1) > BLOCKS(10) RECFM(F B) and so forth. > > Then issue ISPF. > > If you are in ISPF and are able to create a NEW ispf dataset, do that. > > Then go to the ready prompt and issue > > 1) FREE DD(ISPPROF) > 2) ALLOC DD(ISPPROF)DA('new dataset name here') SHR > > Then access ISPF > > You probably should look at the ISPF User's Guide volumes - they can be > quiet helpful. > > > Lizette > > >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] >> On Behalf Of Joseph Reichman >> Sent: Sunday, March 26, 2017 2:27 PM >> To: [email protected] >> Subject: Help deleting file >> >> Hi >> >> I'm getting a 213-04 abend on my ispf profile Dataset >> >> It's seems to be a catch-22 where I can't delete As the system cannot >> find it >> >> And I cannot allocate because the system says it's a duplicate dataset >> Doing a >> 3.4 I can see what pack it's on > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 18:05:02 -0400 > From: Joseph Reichman <[email protected]> > Subject: Re: Help deleting file > > Lizette > > Thanks for your help with JES2 I got my SPOOL and CHKPNT data set off a > system pack and put them om work > > Pack > > thanks > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Lizette Koehler > Sent: Sunday, March 26, 2017 6:01 PM > To: [email protected] > Subject: Re: Help deleting file > > Using 3.4 you can search the catalog (no volser) or volumes (complete or > partial > volser) > > If your dataset is cataloged but incorrectly > > Go to TSO READY PROMPT > Delete 'dsn' NOSCRATCH NOPURGE <--- This uncatalogs the dataset > DELETE 'dsn' <--- this deletes the catalog entry > > Then issue > > ALLOC DD(DMYTMP) DA('your ispf dataset name') CYLINDERS SPACE(1 1) > BLOCKS(10) RECFM(F B) and so forth. > > Then issue ISPF. > > If you are in ISPF and are able to create a NEW ispf dataset, do that. > > Then go to the ready prompt and issue > > 1) FREE DD(ISPPROF) > 2) ALLOC DD(ISPPROF)DA('new dataset name here') SHR > > Then access ISPF > > You probably should look at the ISPF User's Guide volumes - they can be > quiet helpful. > > > Lizette > > >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:[email protected]] >> On Behalf Of Joseph Reichman >> Sent: Sunday, March 26, 2017 2:27 PM >> To: [email protected] >> Subject: Help deleting file >> >> Hi >> >> I'm getting a 213-04 abend on my ispf profile Dataset >> >> It's seems to be a catch-22 where I can't delete As the system cannot >> find it >> >> And I cannot allocate because the system says it's a duplicate dataset >> Doing a >> 3.4 I can see what pack it's on > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > Date: Sun, 26 Mar 2017 16:14:35 -0700 > From: Anne & Lynn Wheeler <[email protected]> > Subject: Re: ComputerWorld Says: Cobol plays major role in U.S. government > breaches > > [email protected] (scott Ford) writes: >> Bravo Phil and Tim from IBM. In my experience with NYC Stock Exchange >> and too many Brokerage houses to count, all of these installations had >> very tight internal/ external security. Including multiple firewalls >> to enter the MF domains. Once in the MF domain, the security subsystem >> was tightly controlled. > > as part of our IBM HA/CMP product > https://www.ibm.com/developerworks/aix/library/au-hacmpcheatsheet/ > > ... we had meetings with SIAC at their offices in wtc > https://en.wikipedia.org/wiki/Securities_Industry_Automation_Corporation > > The Securities Industry Automation Corporation (SIAC) is a subsidiary of > the NYSE Euronext. Its purpose is to provide technical services for the > exchanges themselves, members and other financial institutions. In this > role, SIAC provides the computers and other systems required to run the > exchanges. It also owns communication lines and hardware to provide > real-time quotes and transaction information to all market participants > from the Consolidated Tape/Ticker System (CTS), Consolidated Quotation > System (CQS), and Options Price Reporting Authority (OPRA). > > ... snip ... > > this was before > https://en.wikipedia.org/wiki/1993_World_Trade_Center_bombing > > note HA/CMP effort included handling attacks, not just failure modes. > > It was in this period that I also coined the term disaster servivability > and geographic servivability. I was also asked to write section for the > corporate stratetegic continuous availability document. However, the > section got pulled because both the rochester people (as/400) and pok > people (mainframe) said they could meet the requirements. some past > posts > http://www.garlic.com/~lynn/submain.html#available > > posts in this thread: > http://www.garlic.com/~lynn/2017c.html#60 [EXTERNAL] ComputerWorld Says: > Cobol plays major role in U.S. government breaches > http://www.garlic.com/~lynn/2017c.html#61 [EXTERNAL] ComputerWorld Says: > Cobol plays major role in U.S. government breaches > http://www.garlic.com/~lynn/2017c.html#67 Cobol plays major role in U.S. > government breaches > http://www.garlic.com/~lynn/2017c.html#69 ComputerWorld Says: Cobol plays > major role in U.S. government breaches > http://www.garlic.com/~lynn/2017c.html#70 ComputerWorld Says: Cobol plays > major role in U.S. government breaches > http://www.garlic.com/~lynn/2017c.html#71 ComputerWorld Says: Cobol plays > major role in U.S. government breaches > http://www.garlic.com/~lynn/2017c.html#75 ComputerWorld Says: Cobol plays > major role in U.S. government breaches > http://www.garlic.com/~lynn/2017c.html#76 Cobol plays major role in U.S. > government breaches > > after leaving IBM, one of the first things was being brought in as > consultants to small client/server startup that wanted to do payment > trasnactions on their server, the startup at also invented this > technology called "SSL" they wanted to use, it is now frequently called > "electronic commerce". I had complete authority over the webserver to > payment networks ... which included huge amount of firewalls and HA > redundancy (including geographic survivability). However, I could only > make recommendations on the client/server side ... some of which were > almost immediately violated, that continue to account for some number of > exploits. > > later at financial industry infrastructure protection meetings, > securities industry participation were some of the most difficult > https://fas.org/irp/offdocs/pdd/pdd-63.htm > > securities industry was amoung the most insistant on the FS/ISAC not be > government operation and therefor subject to FOIA ... concern that > public might become aware of some of the things that go on. > https://www.fsisac.com/ > > -- > virtualization experience starting Jan1968, online at home since Mar1970 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ------------------------------ > > End of IBM-MAIN Digest - 25 Mar 2017 to 26 Mar 2017 (#2017-85) > **************************************************************
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
