Yep, and there's also a new code 'n' defined for the same leader element that indicates that non-ISBD punctuation was omitted. 
Still a lot of work if you weren't already having the code provide the punctuation. 
But I'm not complaining because the greater data granularity supported by MARC itself is really a win. 

-Kristina

> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Roy Tennant
> Sent: Wednesday, May 3, 2017 1:19 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] ISBD punctuation (related to [CODE4LIB] rda)
> 
> >Now I'll need to detect when a record is not providing punctuation, and
> have my code insert it based on the MARC element.
> 
> Presumably you could check the appropriate leader element:
> 
> "In 2010, MARBI (Machine-Readable Bibliographic Information Committee)
> approved MARC proposal no. 2010-07 submitted by the Deutsche
> Nationalbibliothek to add a code to Leader/18 (Descriptive Cataloging Form)
> to indicate the omission of ISBD punctuation in MARC 21 records."
> 
> Roy (who can't believe that we're finally doing this)
> 
> On Wed, May 3, 2017 at 10:11 AM, Spurgin, Kristina M. <
> [log in to unmask]> wrote:
> 
> > Related to Eric's question re: RDA, the following news hit my inbox
> > this
> > morning:
> >
> > The library community is moving ahead to, in general, stop using most
> > ISBD punctuation in MARC records beginning January 2018.
> >
> > I've not spent that much time thinking through this, but my initial
> > take is that it's going to require a lot more work for me than the RDA
> > change did.
> >
> > A number of substantial changes are needed to the MARC format to
> > support this. These are listed in this document:
> > https://www.loc.gov/aba/pcc/documents/isbdmarc2016.pdf
> > These will need to be understood/supported by our systems and code.
> >
> > Data-wise, this is a good move overall, however the reality of all our
> > legacy MARC makes it somewhat nightmarish, at least in my first
> assessment.
> >
> > We've always relied on that punctuation in the MARC itself to provide
> > the punctuation in the extracted/transformed MARC data that ends up
> > populating our catalog displays. Now I'll need to detect when a record
> > is not providing punctuation, and have my code insert it based on the
> > MARC element. I don't think we can strip out all the punctuation
> > (tricky to JUST remove the ISBD punctuation) and provide the needed
> > display punctuation programmatically because the legacy records won't
> > have the new MARC elements required to code the data with more
> > granularity---so it will be unclear what punctuation the code should provide
> in many cases.
> >
> > Bah...
> >
> > Anyway, heads up in case it affects any of the stuff you are doing
> > with catalog data...
> >
> > Pasting relevant listserv message below...
> >
> > -=-
> > Kristina M. Spurgin -- Library Data Strategist
> >      E-Resources & Serials Management, Davis Library
> >                       University of North Carolina at Chapel Hill
> >              CB#3938, Davis Library -- Chapel Hill, NC 27514-8890
> >                            919-962-3825 -- [log in to unmask]
> >
> >
> >
> > From: Program for Cooperative Cataloging
> > [mailto:[log in to unmask]] On Behalf Of Beacom, Matthew
> > Sent: Monday, May 1, 2017 4:31 PM
> > To: [log in to unmask]
> > Subject: [PCCLIST] Removing Punctuation in MARC records (PCC ISBD and
> > MARC Task Group Revised Final Report (2016): a timeline
> >
> > Hi all,
> >
> > The attached is a brief rationale and a timeline for implementing the
> > recommendations of the PCC ISBD and MARC Task Group (Revised Final
> > Report 2016).
> >
> > The Task Group recommendation is at https://www.loc.gov/aba/pcc/
> > documents/isbdmarc2016.pdf
> >
> > Here, in the body of this message, is the text of the attached, the
> > rationale and the timeline for action.
> >
> > Rationale:
> > A fuller rationale for removing ISBD punctuation from MARC records is
> > in the report of the PCC ISBD and MARC Task Group Final Report (2016).
> > In brief, the rationale for removing the ISBD punctuation is that
> > since the ISBD punctuation was designed for the card catalog format,
> > it is now an unnecessary burden within MARC; and that, as we prepare
> > for a post-MARC bibliographic environment, the ISBD punctuation is a
> > hindrance to that transition.
> >
> > The argument against making the change is a pragmatic one that
> > combines concerns about timing—doing this just at MARC’s ‘end-of-life’
> > moment—and the potential for labor-intensive disruption in that time.
> > In 2014, it was thought that the impact of the change on our systems
> > before the anticipated migration to linked data and BIBFRAME in 3-5
> > years would be a double whammy that should be avoided, and we hoped
> > removing the ISBD punctuation could be handled on the conversion of
> > our MARC data to BIBFRAME.  But in 2017, the anticipated migration
> > seems at least as far off as it did in 2014: a sure sign that imminence was
> over-predicted.
> >
> > Removing the ISBD punctuation would improve MARC as a format for
> > bibliographic data for the duration of the MARC format’s use. As noted
> > above, the use of MARC can be reasonably expected to continue far
> > longer than some anticipated in 2014. The benefits of removing ISBD
> > punctuation from MARC records include:
> >
> > MARC coding can be used alone to designate parts of the bibliographic
> > description, eliminating the redundancy of parallel input of
> > punctuation and MARC coding. Eliminating most punctuation from MARC
> > records simplifies data entry and allows catalogers to focus solely on
> > coding to better identify parts of the bibliographic description. It
> > also allows for flexibility in the design of online displays without
> > the need for suppressing punctuation. Omission of ISBD punctuation in
> > MARC records is routine in other MARC formats used around the world.
> >
> > MARC 21 will be around for many years with millions of additional
> > records created as libraries slowly move to working with BIBFRAME.
> > With a transition to BIBFRAME, local systems and bibliographic
> > utilities will need the ability to readily map data back and forth,
> > i.e., BIBFRAME to MARC and MARC to BIBFRAME. Those mapping programs
> > would be greatly simplified and more easily maintained if punctuation
> > did not have to be added or removed at the same time. Developing
> > programs now to remove punctuation from MARC
> > 21 will facilitate a transition to BIBFRAME in the future.
> >
> > Actions:
> > 1.      TIMELINE: new start date set to Jan. 1, 2018 for going live with
> > the permission to not use ISBD punctuation; 9-10 months to prepare and
> > adapt.
> > a.      Phase 1: Now to ALA Annual 2017:  Make and distribute record sets
> > for initial preparation testing for impact in local systems, etc.
> > b.      Phase 2: July 1, 2017-Oct. 1, 2017: Use this preparatory period (3
> > months) to complete initial testing of record sets in local systems
> > and report on impact.
> > Initial testing is for non-access points in bibliographic records.
> > Vendors shall be made aware that further testing will address access points
> and
> > authority records, where applicable.   Furthermore, only records with ISBD
> > punctuation are included in the initial testing.  The records do not
> > include coding that needs to be developed by MAC.
> > c.      Phase 3: Oct.  1, 2017 to Jan. 1, 2018:  Analyze results of
> > testing in local systems, and evaluate responses from system vendors
> > (including any projections they may have regarding development and
> > release of upgrades to accommodate proposed changes). Use this second
> > preparatory period (3 months) to understand or make any local changes
> > necessary to tools, workflows, policies.
> > d.      Phase 4: Jan. 1, 2018-? Based on analysis of phase 3, develop
> > timeline, revise specifications, plan changes to tools, workflows,
> > policies as necessary.
> > January 1, 2018 is a “check-in” date to understand the status after
> > hearing from vendors, testers, etc.
> > 1. might vendors need to fold punctuation changes into a multi-year
> > development cycle?
> > 2. Will there be any MAC actions and MARC documentation updates
> needed?
> > 3. Confirm assumption that this proposal would ease conversion to
> > linked data.
> >
> > 2.      COMMUNICATION: PCC community outreach to stakeholders (i.e.
> local
> > system vendors: ILMS and discovery tool providers) Goes through all 4
> > phases.
> > a.      OCLC will reach out to ILMS vendors
> > b.      PCC group will also reach out to discovery tool vendors (some
> > overlap between a & b; redundancy OK)
> > c.      PCC institutional members reach out to vendors as customers
> > d.      PCC Steering will monitor progress through each phase and chair
> > will report to PoCo and PCC
> >
> > 3.      TESTING RECORD SETS: OCLC and LC will create and distribute small
> > record sets for PCC institutional members and vendors to use to test
> > impact of ISBD-punctuation-less records on import, workflow, indexing,
> > sorting, display, etc.
> > a.      OCLC will have some number of pairs of records (with
> > punctuation/without punctuation) --some English, some German--to test
> > by end of phase 1
> > b.      LC will have some number of pairs of records (with
> > punctuation/without punctuation) to test by end of phase 1
> > c.      PCC institutions may create pairs of records (with
> > punctuation/without punctuation), too.
> > d.      PCC institutional members and vendors will report on impact (using
> > the test record sets) at end of phase 2
> >
> > The phases 1-3 above, in short, prepare us to systematically and
> > effectively remove unneeded punctuation from the MARC records. Phase
> > 4, beginning Jan. 1, 2018, is when preparation will morph into
> implementation.
> >
> > PCC will be working through Policy Committee, the Standing
> > Committees—each will have its role, and whatever ad hoc or temporary
> groups may be needed.
> >
> > Thank you and all the best to you,
> >
> > Matthew Beacom
> > PCC Chair
> >
> > Lori Robare
> > PCC Chair-Elect
> >
> > Kate Harcourt
> > PCC Past Chair
> >
> > > -----Original Message-----
> > > From: Code for Libraries [mailto:[log in to unmask]] On Behalf
> > > Of Eric Lease Morgan
> > > Sent: Wednesday, May 3, 2017 11:14 AM
> > > To: [log in to unmask]
> > > Subject: [CODE4LIB] rda
> > >
> > > To what degree have any of us done massive RDA work in our catalogs,
> > > and similarly, to what degree have some of the community's MARC
> > > programming libraries have been modified to account for RDA rules?
> > >
> > > For example, has anybody done any large scale find & replace
> > > operations against their catalogs to create RDA fields with values
> > > found in other
> > MARC
> > > fields? Why or why not? Similarly, RDA seems to define a publication
> > field in
> > > MARC 264. Correct? Yet the venerable Perl-based MARC::Record module
> > > (still) pulls publication dates from MARC 260. [1] A colleague found
> > > a
> > bit of a
> > > discussion of this issue from the VuFind community. [2] Which leaves
> > > me
> > to
> > > ask another question, “Why is there so much business logic embedded
> > > into the MARC cataloging rules?”
> > >
> > > Alas. How in the world is the library community ever going to have
> > > more consistently encoded data so it can actually disseminate
> information?
> > >
> > > [1] MARC::Record - http://bit.ly/2px2sC6 [2] discussion -
> > > https://vufind.org/jira/browse/VUFIND-749
> > >
> > > —
> > > Eric Morgan
> >