I found the most simple one we've got.  Much easier for you to unravel. Some
notes

   - PIPEs gives a INMR123 REXX stage to block pipe records into NETDATA
   format .  We modified this a little, and named that NETDATA+ REXX.
   - The sample is SMFMVS EXEC.  It reads a VM:OPER logfile to extract all
   LOGON/LOGOFF records and send those to MVS in an SMF-like format.  The
   reason: initially we were asked to send RACF"s SMF log to MVS where they
   would extract LOGON/LOGOFF events to see who was logged on at a system in
   which time period.  As RACF didn't collect LOGOFFs in its SMF file, we
   scanned the VM operator log and mimicked a bit an SMF file.
   - At line 201 we store some PIPE stages in a REXX variable: in testmode,
   the stages are simple: create a CMS file, otherwise the stages create MVS
   JCL and call NETDATA+ to format the SMF-like records we created from the
   operator log.
   - At line 266 we read the operator log, and at line 288 the pipe stages
   created in the previous step are inserted in the pipeline.
   - At line 370 the data punched by the pipe are sent to MVS via RSCS.


2011/3/8 Shumate, Scott <scshum...@bbandt.com>

>  That would be great.  Can I take a look at it?
>
>
> Thanks
> Scott
>
>
>  ------------------------------
> *From:* The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU] *On
> Behalf Of *Kris Buelens
> *Sent:* Tuesday, March 08, 2011 3:47 PM
> *To:* IBMVM@LISTSERV.UARK.EDU
> *Subject:* Re: Sending files to JES
>
> On our VM systems, we had some processes that sent a CMS file embedded in
> an MVS job.  The MVS job started TSO in batch to receive the file.  At last
> that single job could carry multiple CMS files.  As a result, the REXX code
> became less than easy to read for beginners.  I can dig that up, on
> condition that the receiver is prepared to unravel that a bit (I'm convinced
> I already sent that once to someone).
>
> 2011/3/8 David Boyes <dbo...@sinenomine.net>
>
>> On 3/8/11 2:21 PM, "Ward, Mike S" <mw...@ssfcu.org> wrote:
>>
>> >Why not FTP it?
>>
>> Simple enough: Automating NJE transfer is trivial -- NJE is
>> fire-and-forget in that the system daemons handle routing, retries, and
>> guaranteed delivery (short of someone clearing spool for some stupid
>> reason). If you've got the NJE connection, it's really, really easy to do
>> this. NJE also doesn't require an active userid on the remote system to
>> transfer files, and it doesn't tie up your userid while the file transfer
>> is going on.
>>
>> Automating FTP transfer is a PITA, especially if you care if it actually
>> arrives and/or if you hit a problem mid-transfer. Out of space errors  (or
>> any other trivial problem) are hard to recover from in a FTP script
>>
>
>
>
> --
> Kris Buelens,
> IBM Belgium, VM customer support
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Reply via email to