BEGIN:VCALENDAR
VERSION:2.0
METHOD:PUBLISH
CALSCALE:GREGORIAN
PRODID:-//WordPress - MECv7.36.4//EN
X-ORIGINAL-URL:https://virtualzcomputing.com/
X-WR-CALNAME:VirtualZ Computing
X-WR-CALDESC:No-code IBM Z data integration, live data access, cloud file storage, and z/OS storage modernization for AI, analytics, and enterprise applications.
X-WR-TIMEZONE:America/Chicago
BEGIN:VTIMEZONE
TZID:America/Chicago
X-LIC-LOCATION:America/Chicago
BEGIN:DAYLIGHT
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
TZNAME:CDT
DTSTART:20260308T030000
RRULE:FREQ=YEARLY;BYMONTH=03;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
TZNAME:CST
DTSTART:20261101T010000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
REFRESH-INTERVAL;VALUE=DURATION:PT1H
X-PUBLISHED-TTL:PT1H
X-MS-OLK-FORCEINSPECTOROPEN:TRUE
BEGIN:VEVENT
CLASS:PUBLIC
UID:MEC-c731ca56d433217024aa86c24f090de1@virtualzcomputing.com
DTSTART;TZID=America/Chicago:20260917T000000
DTEND;TZID=America/Chicago:20260918T000000
DTSTAMP:20260917T070958Z
CREATED:20260917
LAST-MODIFIED:20260917
PRIORITY:5
SEQUENCE:9
TRANSP:OPAQUE
SUMMARY:Send It. Receive It. One Engine: Data Sharing Between ISVs and Their Customers with PropelZ
DESCRIPTION:“Just send us the file.”\nThat’s the moment a service the customer already paid for quietly stops. Not because the data is hard to move; PropelZ moves it at 56,000 records a second, roughly six terabytes an hour. It’s because somebody on the customer’s side has to hunt down the fields, write the extract, run it in a batch window on metered MIPS, and ship it, then do it again the next time a field changes. One enterprise data team told us a single extract takes six to eight weeks, after months in a backlog. And somebody on the ISV’s side has to decode a different layout from every customer, one hand-built intake at a time, while the customer it just signed waits to go live.\nBoth sides are waiting on the same file. The enterprise isn’t getting what it pays for. The ISV isn’t delivering what it sold. Neither of them caused it.\nIn this recorded session, VirtualZ Computing founder and CEO Jeanne Glass and co-founder and CTO Vince Re take the file out of the middle. On the send side, one product replaces the tens of extract programs an enterprise maintains: it reads data in place, uses the COBOL copybook you already have as the layout, filters before the data leaves, and delivers in one hop, zIIP-eligible on z/OS or on Linux, Windows or Linux on IBM Z. On the receive side, one engine inside the ISV’s platform decodes whatever every customer sends, in whatever layout it already produces, and the customer installs nothing. And the customer chooses: keep sending as-is and let the ISV decode it, or run PropelZ on its own side and halve the ISV’s processing.\nIf a platform you’ve paid for is waiting on a data feed, or a customer you’ve signed is waiting to go live, this is the session that changes the math.\nWhat is PropelZ for data sharing?\nPropelZ is VirtualZ Computing’s patented, no-code data movement and decoding platform. Used for data sharing, it runs on either side of an ISV–customer relationship: on the customer’s z/OS, Linux or Windows to feed every provider from one product, and inside the ISV’s platform, on any system with a Java environment, to decode every customer’s data with one engine. It is declarative and metadata-driven: you describe the data with artifacts you already have, such as a COBOL copybook or a Db2 table definition, and PropelZ handles it. Any input, any output, transformed in flight, with no custom code, no staging and no change data capture.\nWhat you’ll see\n\nThe two-sided problem: why “just send us the file” turns into a six-to-eight-week extract, a months-long backlog, a brittle program and a bigger MIPS bill, and why every customer’s file is a project for the ISV\nHow a top-tier global bank asked its banking platform ISV to use PropelZ, and how that ISV built PropelZ for Linux into its platform as a container that runs per feed, with no mainframe anywhere in its estate\nWho owns the metadata: the customer declares what it will send, or the ISV publishes what it needs, and PropelZ supports both\nThe hybrid model: the customer keeps sending as-is and the ISV decodes it, or the customer runs PropelZ on its own side to filter before it sends and cut the ISV’s processing by roughly half\nSend side: the copybook is the spec, one step added to the batch job you already run, incremental every ten minutes, zIIP-eligible, round trips back to VSAM\nReceive side: installs in about an hour, one engine for every customer, onboarding in days, the customer installs nothing\nThe economics: a proof of concept of close to ten thousand datasets that ran Friday to Monday on the incumbent tool and a couple of hours on PropelZ\n\nWho should attend\nISV product and platform leaders, chief technology officers and heads of customer onboarding; enterprise data platform owners, integration leads and mainframe architects; CIOs and chief data officers responsible for sending enterprise data to service providers, or receiving it from customers, on z/OS, IBM i, Linux or Windows.\nHosts\nJeanne Glass, Founder and CEO, VirtualZ Computing  ·  Vince Re, Co-Founder and Chief Technology Officer, VirtualZ Computing\nIn the customer’s words\n“We’ve increased throughput, reduced unnecessary processing layers, and improved operational efficiency.”\n— Chief Product & Technology Officer, banking platform ISV\nWatch now →\n\nSharing data between ISVs and their customers with PropelZ\nQ. What does PropelZ do for data sharing between an ISV and its customers?\nA. PropelZ runs on either side of the relationship. On the customer’s side it replaces hand-built extract programs with one product that feeds every provider. On the ISV’s side it replaces one-off intakes with one engine that decodes every customer’s data. It is the same engine and the same mapping in both places, so the customer can choose where it runs.\nQ. Why does it take so long to send data to a service provider?\nA. Because nothing about it is hard and all of it is work. Someone has to find which fields go in the output, reformat them, convert EBCDIC to what the provider expects, schedule the job, make it fault tolerant and monitor it. One enterprise data team reported six to eight weeks per extract, after months in a backlog. Then the source changes a field and the extract is revisited. Multiply by every provider the enterprise feeds.\nQ. Who owns the metadata, the ISV or the customer?\nA. Either. The customer can say “here is what I am going to send you” and hand over the COBOL copybook it already maintains; PropelZ reads the data from that. Or the ISV can publish “here is what I need” and the customer maps to it once. PropelZ supports both, and nobody writes a parser.\nQ. Does the customer have to install anything to share data with an ISV running PropelZ?\nA. No. The customer keeps sending exactly what it sends today, and the ISV runs PropelZ on its own side to decode it. Nothing is installed at the customer, which avoids the security reviews and change processes that new mainframe software triggers.\nQ. What does the customer gain by running PropelZ on its own side?\nA. Filtering before the data leaves. Records with hundreds or thousands of fields become records with the handful the provider needs, so the network carries a fraction of the bytes and the provider’s processing time drops by roughly half. Customers of one banking platform ISV are now taking that step. It is the same engine and the same mapping, so the ISV’s intake does not change.\nQ. Does PropelZ raise the mainframe MIPS bill?\nA. No. Most PropelZ processing on z/OS is dispatched on zIIP engines, so you can run all you want without driving metered software costs up. Hand-built extracts on general-purpose engines can raise peak utilization and the licence cost of everything running alongside them. If there is no zIIP in the configuration, VirtualZ provides tuning guidance, or PropelZ runs on Linux, Windows, or Linux on IBM Z in another LPAR.\nQ. Can an ISV use PropelZ without a mainframe?\nA. Yes. PropelZ runs on any platform with a Java environment, and no mainframe is required anywhere in the ISV’s estate to process mainframe data. One banking platform ISV runs it as a container in its cloud: a customer feed arrives, PropelZ starts, decodes it, and disappears. Multi-tenant platforms choose how to segregate customer data, and PropelZ can deliver the same feed to more than one target.\nQ. Do you have to use every PropelZ capability, or can you use just part of it?\nA. Just part, if that is what fits. Some ISVs use PropelZ only for ingestion and transformation in front of infrastructure they already have. One asked for no transformation at all, bit for bit what was on the original input, because it already had software that understood those records. Both are configuration.\nQ. How does PropelZ handle a change to the source data?\nA. You update the COBOL copybook you would have updated anyway, and nothing else changes. For a Db2 table, PropelZ reads the structure from Db2 and needs no layout at all. There is no extract program to revisit.\nQ. Does PropelZ require change data capture or journaling to deliver data frequently?\nA. No. Because it is fast, PropelZ can run incrementally, every ten minutes if the provider wants, and send only what changed since the last run, with no CDC, journaling or logging to switch on. A feed that was daily because of processing cost starts to look like a real-time feed.\nQ. Does PropelZ fit existing mainframe operations and schedulers?\nA. Yes. If the data a provider needs is produced by an overnight batch job, add one step to that job. Trigger PropelZ from CA 7 or another scheduler, from workflow automation, or from a command when someone needs it now. It scales to inventories of thousands of files, running ten, a hundred or a thousand at a time, and it can round-trip data: send a VSAM file to the cloud, process it, and bring the result back to VSAM.\nQ. How long does it take to install PropelZ?\nA. About an hour on any platform, Linux or z/OS. The time in a deployment goes to the ordinary things around it: network access to targets, digital certificates and connectivity. This is not a six-month proof of concept; install, configure and test the same day, and if the mainframe queue is the wait, test on Linux against the same data first.\nQ. How fast is PropelZ compared with the tools enterprises already have?\nA. In one proof of concept, a large, well-staffed site with licences for most tools in the category built a test of close to ten thousand datasets. On the incumbent product the job was submitted on Friday and still running on Monday. PropelZ ran it in a couple of hours. In deployments, ingestion that took hours typically runs in half the time, and in some cases a tenth. Throughput is customer-reported at 56,000 records per second, roughly six terabytes an hour on a mid-sized cloud instance.\nQ. How has an ISV used PropelZ for data sharing?\nA. A top-tier global bank asked its banking platform ISV to implement PropelZ to improve how the two shared data. The ISV had been writing custom ingestion per customer and hitting enormous processing times and brittle feeds. It built PropelZ for Linux into its platform as a metadata-driven engine, removed the intermediate data-handling layers, and now decodes bank data directly with no mainframe in its estate. Read more in our white paper: Banking AI Needs Core Data. ( https://virtualzcomputing.com/pdf-tl-paper/banking-ai-core-data/ )\n
URL:https://virtualzcomputing.com/events/data-sharing-isvs-customers-propelz-webinar/
CATEGORIES:Featured Col 1
LOCATION:Virtual
ATTACH;FMTTYPE=image/webp:https://virtualzcomputing.com/wp-content/uploads/2026/09/Webinar-Send-It-Receive-It-One-Engine-PropelZ-Data-Sharing_872p.webp
END:VEVENT
END:VCALENDAR