Dave,
My understanding is that the pipelines package can also be run in the
TSO environment of z/OS, but most z/OS sites are reluctant to install
"unsupported" software on their systems. Can CMS/TSO Pipelines be run in a
user's TSO address space, or must it be installed as a separate product?
TIA,
Leslie
-----Original Message-----
From: CMSTSO Pipelines Discussion List [mailto:cms-pipeli...@vm.marist.edu] On
Behalf Of Dave Jones
Sent: Tuesday, December 07, 2010 09:16
To: CMS-PIPELINES@VM.MARIST.EDU
Subject: Re: [CMS-PIPELINES] The Missing Stages
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
>
