HDTenEightyP/NetNews huggingface dataset:
Newsgroups: bit.listserv.cmspip-l
Date:         Tue, 7 Apr 1992 08:02:17 CDT
From:         Rick Troth <TROTH@RICEVM1.RICE.EDU>
Subject:      Re: Pipes Description

>                    PIPES is a utility that will bring the wonders
>(at least, some of them) of UNIX to CMS.

        What's UNIX?   (just kidding)

        Better than that ... UNIX is byte oriented.   CMS Pipes is
record oriented  (as is CMS itself).   I see that as a *major* advantage.

"Dinosaur Babysitters:  we'd cast your pet in stone,
                        if you'd only let us"
"You can fight the whole world ... or live in your own"
 Rick Troth <TROTH@RICEVM1.RICE.EDU> -------- Rice Univ, I/S VM Systems Support
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.cmspip-l
Date:         Wed, 15 Apr 1992 15:21:58 EDT
From:         Melinda Varian <MAINT@PUCC.BITNET>
Subject:      Re: LOOKUP output streams

Doug,  I think the pipe shown below does what you want.  Basically,
you just needed to display the *primary* output of "lookup", which
contains the pairs of matched records, in addition to the secondary
output, which contains the unmatched detail records, which you were
already displaying.

/* Display all entries from PILE and matched entries from MAST */

mast.0 = 4; mast.1 = 'A'; mast.2 = 'B dat'; mast.3 = 'C dat'; mast.4 = 'D'
pile.0 = 3; pile.1 = 'C'; pile.2 = 'B'; pile.3 = 'F not in it'

'PIPE (endchar ?)',
      'stem pile.|',                  /* Read detail records.        */
      'sort |',                       /* Sort them.                  */
   'l: lookup 1 |',                   /* Match with master records.  */
      'spec',                         /* Reformat matched pairs:     */
         '/PILE </ 1',
         '1-* next',                  /*    Detail record.           */
         'read',
         '/> had a match in MAST: </ next',
         '1-* next',                  /*    Master record.           */
         '/>/ next |',
      'console',                      /* Display on console.         */
'?',
      'stem mast. |',                 /* Get master records.         */
   'l: |',                            /* Route to lookup.            */
      'spec',                         /* Unmatched detail records.   */
         '/PILE </ 1',
         '1-* next',
         '/> was not matched./ next |',
      'console'                       /* Display.                    */

return rc
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.cmspip-l
Date:         Tue, 7 Apr 1992 11:38:29 EST
From:         "Scott Mattes" <COTRSSM@SEA04VM.NAVSEA.NAVY.MIL>
Subject:      Re: RDR file to Printer
Comments: To: VM/SP CMS Pipelines Discussion List
              <CMSPIP-L%MARIST.BITNET@uga.cc.uga.edu>
              7 Apr 1992 10:13:46 EDT from <LEWIS%KENTVM.BITNET@uga.cc.uga.edu>

On Tue, 7 Apr 1992 10:13:46 EDT Doug Lewis said:
>Hi All,
>
>I am a new user of pipes, therefore please forgive me if this question
>has an obvious solution.
>
>On my account, the following command works to transfer a rdr file
>to the printer:  'PIPE READER | PRINTMC'
>
>When I issue the same command under a different userid I get 'No reader
>file available.'

  Do a CP Q C * and see if the rdr is spooled to F or *.  If not, that
is your problem.

Scott       | No success can compensate for failure in the home. David O. McKay
Mattes      | President 1951-70, Church of Jesus Christ of Latter-day Saints
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: University of Califonia San Francisco
Newsgroups: bit.listserv.cmspip-l
Date:         Fri, 10 Apr 1992 12:35:38 PDT
From:         Yossie Silverman <YOSSIE@UCSFVM.UCSF.EDU>
Subject:      Re: VMC device driver

My problem with SMART was that I wanted to use the SNAP commands which just
deliver binary data with no interpretation performed and no 'more data
available' indication either.  As mentioned in a previous note, I solved
the problem in a pretty general way.  To repeat:

literal next | dup * | literal d idle | vmc | tolabel +---

  will give you all the screens of 'd idle'.

nlocate /"/ | nlocate />/ | deblock 16 | nfind _

  will deliver the result in a single column with all extreneous info
removed.

  In my case I also needed the results from 'vmc smart d' so I just
used the screen after 'd idle' results (I.e. what the 'tolabel' shunted
to the secondary screen) for that.  Smart is nice enough to deliver a
'D' screen when it gets a 'NEXT' and there are no more screens of the
current command.

- Yossie
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.cmspip-l
Date:         Fri, 10 Apr 1992 14:02:35 CDT
From:         Rick Troth <TROTH@RICEVM1.RICE.EDU>
Subject:      WAITRD? WRTERM?

Hi,

        What is it that Pipes grabs hold of for CMS redirection?
I presume that it traps WAITRD and WRTERM.   Correct?   The reason is
that I want to do some gems in C,  and I do *not* want to go through the
overhead of the C/370 support library,  but want to call CMS directly.
Maybe C should call Pipes directly instead of re-directed WAITRD/WRTERM.

 Rick Troth <TROTH@RICEVM1.RICE.EDU> -------- Rice Univ, I/S VM Systems Support
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.cmspip-l
Date:         Wed, 15 Apr 1992 10:00:18 LCL
From:         Bridget Rutty <SYSBXR@SUVM.BITNET>
Subject:      CMS Filter

I've solved my problem by writing two pipes, one to detach the disk
and the other to release the file mode.  But in the process I tried
to do it with only one pipe, stringing several CMS commands together.
It won't work, pipedemo shows that the subroutine runs ok and gets
the file mode and spec works ok building the commands (as far as I
can see, not all of it will fit on the screen) but cms apparently
never sees the commands.  Eof is propigated from the subroutine
to spec to cms and the commands don't execute.  If I use the same
structure but spec only builds one cms command it works.  If I
put a buffer between spec and cms the record gets passed to the
buffer but not cms.  So there's something I'm not understanding
about cms.

Here's the pipe:

/*  */
address command 'EXEC PIPEDEMO',
  ' pipdsrc srt22d |',              /* What file mode was assigned ? */
  'spec /exec pushmsg/ 1',            /* Save msg settings           */
  '/#cp set imsg off/ nextword',     /* Turn off imsg               */
  '/#rel/ nextword',                 /* Build command - release     */
  '1-* nextword',                    /* Get file mode               */
  '/(det#/ nextword',                /* And detach                  */
  '/exec popmsg/ nextword |',        /* Put msg settings back       */
  'cms'                               /* Now do it                   */
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.cmspip-l
Date:         Tue, 7 Apr 1992 11:16:45 MEZ
From:         Otto Stolz +49 7531 88 2645 <RZOTTO@DKNKURZ1.BITNET>

Hi,

Melinda has asked for a one-liner.

What about
  pipe < / | find F| locate 27.1 /s/| spec 1.56 1| sort unique| console
issued as a filelist-prefix command against your personal NETLOG file?

It will display a list of all Files ("find F") sent ("locate 27.1 /s/"),
together with all their recipients ("spec 1.56 1").

Best regards,
                    Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
                               <RZOTTO@nyx.uni-konstanz.de>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.cmspip-l
Date:         Mon, 6 Apr 1992 16:51:03 CDT
From:         Landy Manderson <USTS034@UABDPO.BITNET>
Subject:      Re: Pipes Description
Comments: To: Stace Cameron <GH0234%SPRINGB.bitnet@SIUCVMB.SIU.EDU>,
              cmspip-l@marist.BITNET

On Mon, 6 Apr 1992 16:35:40 CST you said:
>I have to justify ordering CMS PIPLELINES. Our systems people wont order it
>unless they know "what it is for", "who will use it", etc. I have seen it
>mentioned in postings on VM-UTIL and VM-REXX and it looked worthwhile from
>the snippets of code there. Does anyone have a short explantion of the
>features in PIPELINES?

I just installed our copy of Pipelines yesterday, so I am hardly an expert
on the subject, but I thought I would add two cents worth anyway.

The IBM VM Software Newsletter for 2Q/3Q 1991 has a little article about
Pipelines, which has a few details.  It also mentions that a Feature Article
is/was planned for the 1Q92 issue.  I dunno if this issue has already been
printed, but I can't find it laying around anywhere (my messy office could
be at fault there).  The article mentions a "CMS Pipelines Tutorial" manual,
GG66-3158.

Now, let me tell why _we_ ordered it.  It came to my attention that a lot of
the cutting edge software that is being developed "in the field" is being
based on Pipelines.  For example, the latest version of PNN has support for
Pipelines, and VM/CMS Gopher requires it.  I think you are going to see more
and more really nifty, useful, exciting software coming out that requires it.
(And FYI, the article sez Pipelines is now built into VM/ESA CMS 1.1...)

That's just half the story.  I am sure others on the list are in a
better position to tell you why you _personally_ want to touch and use
Pipelines (increased productivity, ability to write neat little utilities
really fast, faster filtering/sorting/displaying of data and files, etc.)
My impression is that alot of people get a gleam in their eye when talking
about it.  (Line from _IBM_ installation manual preface: "The pipeline is a
way of life...")

BTW, if you are on the IBM HESC, Pipelines is included in one of those groups.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.cmspip-l
Date:         Thu, 9 Apr 1992 10:54:30 EDT
From:         Melinda Varian <MAINT@PUCC.BITNET>
Subject:      Re: interpreting trace info

On Thu, 9 Apr 1992 09:41:13 +0200 R.Rys said:
> Hello,
>
> is there somewhere a description of the meaning of the trace records
> written when running a pipe with the trace option?

I don't know of any description of the trace records.  They are fairly
readily understood once one understands how the CMS Pipelines dispatcher
works.  And the best way to get to understand that is to read the Piper's
new paper, "CMS Pipelines Explained".  (That's the paper that is in the
archive as PIPJARG LIST3820.  If you have been unable to print that
file, send me mail (off the list -- *don't* reply to the list, please)
with your mailing address and I will try to send you a paper copy.)

> More specific: what does "COMMIT LEVEL 0" mean? is "LOCATE CALLED" a
> call of a locate macro that copies data between stages?

The commit level mechanism allows the stages in a pipeline to notify
one another when they are ready for data to flow or for other events.
Commit level 0 is the level at which, by convention, data flow through
the pipe.  (For an explanation of commit levels, see SL26-0018-01 or
"CMS Pipelines Explained".)

Any of the built-in stages that start at a commit level lower than 0
commit to 0 when they have verified that their environment and arguments
are correct.  A Rexx stage, by default, commits to 0 the first time it
issues an INPUT, OUTPUT, or SELECT ANYINPUT command.

"Locate called" means that the stage has done the equivalent of a
PEEKTO; i.e., it has done a locate-mode read, which leaves the
producing stage blocked.

> But what to do with "INPUT 0 BYTES" then ( which is apparently issued
> in some cases before the locate macro )...

"Input 0 bytes" usually means that the stage has done the equivalent
of a READTO with no argument; this is a move-mode read with a 0-length
buffer.  Typically, the stage has previously done a PEEKTO to get a
record and is now ready to unblock the producer, which it does
by issuing a READTO for the record.  As it has already processed the
record, there is no point in actually retrieving it again with the
READTO, so it specifies a length of 0 bytes.

In case you've not noticed it, there is a very convenient way to
capture trace output for mulling over.  This is from the help file
for RUNPIPE:

   /* debug pipe */
   pipe='(trace)' arg(1)
   address command
   'PIPE var pipe | runpipe | > pipeline trace a'

Melinda
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Acknowledge-To: <RZOTTO@DKNKURZ1>
Newsgroups: bit.listserv.cmspip-l
Date:         Wed, 8 Apr 1992 09:33:24 +0200
From:         Otto Stolz <RZOTTO@DKNKURZ1.BITNET>
Subject:      Re: READER (Revisited)

Hi,

apparently I've been too hasty pushing out my most recent note.
Meanwhile, I've learned that the NETDATA format is not as easy as I had
erroneously assumed.

On Tue, 7 Apr 1992 16:44:55 EDT Christoper V. DeRobertis said:
> I read a file in from the reader, using READER, tyro to do a little
> work over it, then write it back out.
> ...
> Results after running J EXEC:
>
> &
> &              *{//* This is a test 2
> &                *{//*This is a test
> &                  *{  //* This is a test
> &                    *{//* This is a test
> &                        *{/**//* This is a test, WAY out!!!
> &                          *{//*
> &                            *{//* Can you hear me?

Let me guess: When you browsed your RDR file via PEEK, it looked good;
now you use PIPE's READER stage, it looks like a wallpaper?

If so, the reason is most probably the RDR file being in NETDATA format.
Read pages 48..50 in your SL26-0018-01 "User's Guide and Filter Refrence"
then try something like
    "PIPE READER | FIND" '41'x "| SPEC 2-* 1| PAD 80"           ,
                "| DEBLOCK NETDATA | NFIND" 'E0'x "| SPEC 2-* 1",
                "| ..."

What the Pipes User's Manual does not mention:
This pipeline will most probably garble any file that happens *not* to
be in NETDATA format. You can determine the format of the desired RDR
file easily by something like
    call diag 8, "ORDER" desired
    "RDR ( NOTYPE"
    select
    when rc=00 then ...
    when rc=01 then ...
    ...
    when rc=23 then "PIPE READER | ... | DEBLOCK NETDATA | ..."
    when rc=24 then ...
    otherwise       ...
    end
For more details, try
    HELP CP  ORDER
    HELP CMS RDR

I hope, that really helps, this time,
                    Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
                               <RZOTTO@nyx.uni-konstanz.de>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.cmspip-l
Date:         Thu, 9 Apr 1992 15:13:15 CDT
From:         Christian.J.Reichetzeder@AWIIMC12.IMC.UNIVIE.AC.AT
Subject:      Re: VMC device driver
              8 Apr 1992 14:12:30 PDT from <YOSSIE@UCSFVM.UCSF.EDU>

On Wed, 8 Apr 1992 14:12:30 PDT Yossie Silverman said:
>There seems to be a limit of 8320 or so bytes on the response length
>from SMART using this driver.
The limit  is 8k.  What you  get is 8240  bytes because  of the  formatting to
80-byte records  with the last 48  bytes garbage. SMART doesn't  even tell you
that more is waiting and there's no  way to retrieve other than increasing the
buffer.
I'm too  lazy too  look up  the SMART and/or  VMCF docs  whether the  limit is
imposed there  - to  change it  in Pipes modify  PIPDEL (yes!!)  ASSEMBLE, the
label REPLY defines the buffer ...

Christian
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.cmspip-l
Date:         Tue, 14 Apr 1992 15:41:56 LCL
From:         Bridget Rutty <SYSBXR@SUVM.BITNET>
Subject:      Re: CMS Filter
Comments: To: Wayne Smith <WTS@MAINE.MAINE.EDU>

On Tue, 14 Apr 92 15:40:07 EDT you said:
>Hi Bridget,
>
>The detached response from cms release is a CP response, and so
>is not caught by pipe cms.
>
>I've always thought it a CMS bug (CMS should catch and then replay the msg),
>but have never found the time/energy to fight the support center on it!
>
>Maybe now that PIPE is IN CMS for ESA 1.1.1, it would be easier?

Well now, I should have known that.  And I even checked to make sure
release was a cms command before I wrote that note.  I wanted to hide
it from the users and thought pipes was the perfect solution.  Guess
I'll have to think about it.  Thanks.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.cmspip-l
Date:         Thu, 9 Apr 1992 15:45:08 CDT
From:         Christian.J.Reichetzeder@AWIIMC12.IMC.UNIVIE.AC.AT
Subject:      Re: interpreting trace info
              9 Apr 1992 09:41:13 +0200 from <SYSTRR1@CC1.KULEUVEN.AC.BE>

Took me more time to reply than Melinda .... anyway ...

On Thu, 9 Apr 1992 09:41:13 +0200 R.Rys said:
>is there somewhere a description of the meaning of the trace records written
>when running a pipe with the trace option?
You wouldn't guess ... it's in the  help for the message although I admit that
in some cases you'd be not much wiser afterwards :-).
>
I'll try a short description, you'd have to RTM for details.
Only stages at the lowest commit level  (which can be negative) can run. As it
is now data  is exchanged on commit  level 0. Stages starting  at lower levels
(REXX programs  start on  -1) can  abandon the  pipe before  everything starts
working.

If you want to play:
* You'll see more than "0 bytes" when using e.g. BUFFER.
* Keep Pipes short
* Write this small stage for more tests:
    /* NOP REXX ..... */
    Trace '?R'; nop; Nop; Nop; Nop;   /* Just in case ... :-) */
* Start for example like this:
    PIPE (Trace) Literal Abc|cons
    PIPE (Trace) Literal Abc|spec 1-*|cons
    PIPE (Trace) Literal Abc|nop|cons
    PIPE (Trace) Literal Abc|nop|spec 1-*|cons
  Once the trace in NOP pops up you can enter:
       Exit 12345
       'short'
       'commit 0'
       'commit 1'
       'short'; 'commit 1'
   eventually you can also try 'output', 'peekto' and the like.

Christian
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.cmspip-l
Date:         Mon, 6 Apr 1992 19:11:17 EST
From:         "Slow-Children@Play" <IQTI400@INDYCMS.IUPUI.EDU>
Subject:      Re: Pipes Description
Comments: To: VM/SP CMS Pipelines Discussion List
              <CMSPIP-L%MARIST.BITNET@uga.cc.uga.edu>
              6 Apr 1992 16:35:40 CST from <GH0234%SPRINGB.bitne
              t@SIUCVMB.SIU.EDU>

On Mon, 6 Apr 1992 16:35:40 CST Stace Cameron said:
>I have to justify ordering CMS PIPLELINES. Our systems people wont order it
>unless they know "what it is for", "who will use it", etc. I have seen it
>mentioned in postings on VM-UTIL and VM-REXX and it looked worthwhile from
>the snippets of code there. Does anyone have a short explantion of the
>features in PIPELINES?
>


Although I cannot begin to sound the trumpets as loud as the master
plumbers, I think I'd feel somewhat naked in a VM environment and not
have PIPES available.  While it appears to be nothing more than a fact
that PIPES is inherent to VM/ESA 1.1, why not use this to your cause?
On the list of "pros", list the fact that since it will be part of ESA,
then it's a powerful tool you could be using *now*.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Approved-By:  Public-Access Computer Systems Forum <LIBPACS@UHUPVM1.BITNET>
Newsgroups: bit.listserv.pacs-l
Date:         Thu, 16 Apr 1992 11:00:19 CDT
From:         David Lisbona <dlisbona@ccsg.tau.ac.il>
Subject:      Internet User Addresses

----------------------------Original message----------------------------

I am surprised that nobody has mentioned the PARADISE project, which is the
most user-friendly online directory server I have found yet for Internet
addresses. It acts as a front-end to a lot of other directory servers. It also
lists lots of people not on email but working in institutions connected to
Internet. Try it by telneting to

   128.86.8.56    login as    dua

====================================================================
David Lisbona       DLISBONA@CCSG.TAU.AC.IL    Compuserve:71307,2020
Faculty of the Humanities,  Tel Aviv University,  Tel Aviv,  Israel
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Approved-By:  Public-Access Computer Systems Forum <LIBPACS@UHUPVM1.BITNET>
Newsgroups: bit.listserv.pacs-l
Date:         Wed, 15 Apr 1992 12:49:22 CDT
From:         FAMF000 <FAMF@NMUMUS.BITNET>
Subject:      Gateway rumors

----------------------------Original message----------------------------
> On the issue of getting through to the support line - We have two Gateways.
> We would have more but they aren't on state contract.  We don't need to
> call the support line nearly as often for these machines as many of
> the other brands we have.  And when we do, we get an answer at least
> as fast from Gateway as the others.  The others may answer the phone
> a little faster but they rarely know the answer right off the bat and
> don't get back to us very quickly.  But hopefully some of those new
> people Gateway is hiring are for technical support.
>
> Mary Brandt Jensen University of South Dakota

From:  Mike Strahan, FAMF@NMUMUS.bitnet

I would like to echo Mary's comments.

A colleague also encountered problems getting through to technical
support.  However, when she called them last week, she received
an instant (correct) answer and instruction.

Also, I find it hard to believe that Gateway is in trouble,
considering that they have just just announced new laptop models.

Mike Strahan, Computer Reference Services, Northern Mi. Univ.

** usual disclaimer goes here **
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: bit.listserv.pacs-l
Date:         Tue, 7 Apr 1992 09:28:35 CDT
From:         Public-Access Computer Systems Forum <LIBPACS@UHUPVM1.BITNET>
Subject:      Anonymous Access to OPACs

2 Messages, 63 Lines
*-----

From:         Howard Pasternack <BLIPS15@BROWNVM>
Subject:      RE: Anonymous access to OPACS

>From:         Gord Nickerson <35007_321@uwovax.uwo.ca>
>- I am amazed that your computer center or systems people allowed this
>  setup in the first place!  Each organization connected to the Internet
>  should have a Network Information Center (NIC) that controls access, one
>  of the basic requirments is that all computers must be registered with the
>  NIC and assigned to a user. There can be no general anonymous public access
>  to the Internet.

  I guess I would appreciate it if Mr. Nickerson would cite the document and
  the source for this "policy".  While the above may reflect the situation
  at Mr. Nickerson's institution, it does not reflect the policies or situation
  at mine.

  Howard Pasternack
  Brown University
*-----

From: "Genevieve Engel" <GENOL@UCCMVSA.BITNET>
Subject:  Re:  Anonymous access to OPACS/Internet

Sanjay writes:
>host to do the user validation.  From library's perspective, it's really
>isn't their problem (or at least it doesn't make it any worse).  Any
>local (and presumable untraceable) user can dial into the library's
>machine and attempt the same damage he/she would through telnet.

Yes, the user may attempt to damage the LIBRARY'S system, but that
is a matter of the responsibility the library (or whoever is
managing the OPAC host) has to protect the local system.  There is a
larger responsibility that the host administration has, which is to
plug up as many security holes as possible to keep OPAC users from
wandering unidentified throughout the net, wreaking havoc on OTHER
people's machines.  Users should not be able to turn an anonymous
logon to your OPAC into a free-ranging telnet session.  It's
probably naively optimistic to suppose you won't get someone
sometime who will figure out how to do this -- in fact if it happens
enough, we may yet see the day when it is considered uncouth and
irresponsible not to get your OPAC checked and passed by security
experts or your local tame hackmeisters.  For now I think the main
thing is to avoid giving trivial access to the net at large.  For
example, if you find a host that for some reason actually allows
anonymous telnet in and also allows anonymous (or "guest" or
"temporary" account) telnet access out -- do not add it to your
local OPAC's menu of remote systems!

>connection.  rest is easy, most TCP/IP packages suggest temporary IP
>addresses that may be used, you can borrow one, even one from the

Yikes.  I don't know much about TCP/IP but I sure hope the security
implications of this helpful TCP/IP feature are not as bad as
they sound.

Genevieve Engel                    >  "Information wants to be free"
MELVYL System User Services        >                -- Stewart Brand
University of California           >
gen$ol@uccmvsa.ucop.edu            >
genol@uccmvsa.bitnet               >
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU