Kris,

If that was meant for me, it's a nonstarter.  This was developed for a BIG 
files. 
 
Compare the differences...

The FTP solution required the EXEC to write the JCL (pretty trivial), 
submit the very small z/OS batch job via FTP, then the job to execute on 
z/OS, which reads the very large file FTP and writes it, untransformed, to 
SPOOL.

The proposed solution would require reading the very large file from disk, 
transforming it to NETDATA format (LRECL 80, with IIRC only 72 usable 
bytes per record), write it to z/OS, then run TSO (a costly 
consideration!) in batch to read the very large file again, transform it 
from NETDATA back to its old format, then write the file to SPOOL. 

Even with the most-excellent Pipes, that's a lot of extra work on very 
large and wide files compared to read once/write once.  And running the 
TSO TMP in batch, really?  IMHO, TSO is pretty much always "processor 
aware" - meaning that if it can find processor resources, it will use 
them.  ;-) 

Respectfully,

Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.



"Kris Buelens" <kris.buel...@gmail.com> 

Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>
12/22/2010 12:54 PM
Please respond to
"The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU>



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: How Submit a JOB from Z/VM to Z/OS using RSCS ?






We created some REXX exec to make it possible for pipeline data to be sent 
to MVS in a job (that is, not need to pass b-via a CMS file: we transform 
the data into a NETDATA format, put JCL before & after and run TSO in 
batch to receive it.
If you want it, I can dig it up.

2010/12/22 Mike Walter <mike.wal...@hewitt.com>
Thanks, Hank!

There's no sense in my re-posting your whole idea of submitting z/OS jobs
via FTP from z/VM to z/OS.

Here's another way that can be used...
After a very, very old and pretty much unsupported Network Systems
HyperChannel box failed of extended old age, I was forced to find way to
send very large (in terms of LRECL and of the sheer number of records)
from CMS to z/OS JES2 SPOOL.  RSCS didn't cut it although it works fine
for most output).

So I converted an existing EXEC to create the requisite JCL (getting the
password from the user's NETRC DATA file; I sure wish there as a better
way to do that!), FTPs the batch job to z/OS, then wait for the batch job
to end before exiting.  The z/OS batch job establishes an FTP connection
back to z/VM (using the VM userid and password from that NETRC DATA file -
uuuugllleeee!), and "GET"s the file for output directly to JES2 SPOOL.
When the job ends, the NOTIFY message is sent by JES2 to the submitting
z/VM user running the exec.  The exec traps the reply (and return code),
ending with an appropriate message to the user.

Not being a z/OS JCL super-expert, it took a bit of digging around to get
all the moving parts aligned, but the result has been terrific.  We can
now send those very large print files from z/VM to z/OS for printing at
very high speed, even from VM:Batch (which require a bit more in the way
of local mods).

Mike Walter
Aon Corporation
The opinions expressed herein are mine alone, not my employer's.



The information contained in this e-mail and any accompanying documents 
may contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if 
this message has been addressed to you in error, please immediately alert 
the sender by reply e-mail and then delete this message, including any 
attachments. Any dissemination, distribution or other use of the contents 
of this message by anyone other than the intended recipient is strictly 
prohibited. All messages sent to and from this e-mail address may be 
monitored as permitted by applicable law and regulations to ensure 
compliance with our internal policies and to protect our business. E-mails 
are not secure and cannot be guaranteed to be error free as they can be 
intercepted, amended, lost or destroyed, or contain viruses. You are 
deemed to have accepted these risks if you communicate with us by e-mail.



-- 
Kris Buelens,
IBM Belgium, VM customer support



The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail. 


Reply via email to