Hi, Paul.

I'm afraid you're caught between a rock and a hard place if your VM
sysprogs will not let you install the current Pipelines runtime
available from Marist. Almost all of the (many) enhancements John has
made to Pipelines since it first was shipped with z/VM have been to the
so-called Marist Pipes distribution and they have not been "back-ported"
to the official z/VM Pipelines code.

The most current set of documents for CMS Pipelines are also found on
the Marist web page, especially the frequently updated PIPELINE NEWSxxxx
files and the CMS Pipeline Author's Edition, which I consider the final
authoritativie reference on all things Pipe.

I would suggest that if you are interested in getting the most out of
Pipes you donload and install the Marist runtime on your VM user id; it
can live happily alongside of the official VM Pipes distribution, and
you can easily switch back an forth between the two. You don't need to
replace one with the other (and neither do your customers....)

Also download the Author's Edition, it's a very nicely written PDF file
and it has hyperlinks in the text so you can wander around in it via
mouse clicks.

Hope this helps some and have a good one, too.

DJ
On 12/7/2010 8:49 AM, Paul Gilmartin wrote:
On Dec 7, 2010, at 01:49, Rob van der Heij wrote:

On Tue, Dec 7, 2010 at 3:34 AM, Paul Gilmartin<paulgboul...@aim.com>  wrote:

Worse yet, if it's in the spool in NETDATA format (well, then
it's likely not so huge):

Sorry, but it appears you have not even read the book. Most plumbers
on the list would at least look in the index and find the idiom to
deal with netdata files. There's built-in stages to block and deblock
netdata just fine. The generic solution is just a bit more complicated
than you suggest (there's the netdata envelopes that need to be
handled to pass the meta data as well). The same applies to things
like VMARC and VMFPLC that frequently handle stacked files.

I'm familiar with the READER and NETDATA stages; I use them;
I cited them in the 3-line example I posted (yes, abbreviated,
absent necessary arguments.)

I was echoing John Larson's observation that there seems to be
no conventional way to deal with large VMARCs other than unpacking
them entirely, with large disk space requirements.

Is the book you mention:

     Title: z/VM V6R1 CMS Pipelines Reference
     Document Number: SC24-6169-00
     Build Date: 07/24/09 14:05:06

?  This contains no mention of VMFPLC*, and only an incidental
mention of VMARC in connection with obtaining RXSOCKET.

the FTP archive at vm.marist.edu contains VMARC MODULE and several
files with filetype VMARC; nothing relevant to VMFPLC*.

Are there other sources I should be consulting?

Well, yes.  A Google search finds a thread I started early this
year, to which Rick Troth and John Hartman, among others replied.

Rick Troth mentions that "[tar and VMFPLC B]oth can be neatly
wrapped into plumbing."  Nothing more specific.

And John Hartmann states, "The undocumented LISTDIR stage will
get you all the information you require."

      pipe listdir | console
     PIPFPI011E Null or blank parameter list found.
     PIPSCA003I ... Issued from stage 1 of pipeline 1.
     PIPSCA001I ... Running "listdir".
     Ready(00011); T=0.01/0.01 07:37:31

Undocumented, indeed.

And there is a VMFPLC thread about 5 years old, to which you
contributed.  A glance at the code and at a VMFPLC archive
shows a mismatch, "FPLH" in the code, and "FPLC" in the
archive.  Perhaps the format changed in the interim.

You can write filters in REXX or even in assembler if you need. Many
of us have written their own filters for specific scenarios, and most
are willing to share if you ask (and if their employer allows that).
It may be me, but the tone of your posts on the list right now does
not encourage me to dig in my plumbers' toolbox and throw in some
fittings and appendices to build something.

I'm considerably constrained by the need to provide code to
customers.  My own systems programmer won't install the
Pipelines Runtime; I must assume that some customers will
feel likewise.  And they may have similar aversions to complex
tools; I want to keep things standard and simple for them.

Thanks for your assistance; you've provided some useful
suggestions and encouragement.  And my apologies if I
offended.

-- gil

Reply via email to