How to send files from a mainframe to a Unix server from Cobol program?
zalek
I need to send files from a mainframe to a Unix server from a Cobol
program. I tried to call FTP - but without success. It has to be from
a cobol program, because number of file varies depending on daily
activity.
Any ideas how to do it?
Thanks,
Zalek
Michael Mattias
news:498652f6-b265-4111...@d45g2000hsc.googlegroups.com...
How/why did FTP fail? I know others use FTP to do this, ergo it must be
do-able.
Although... you might get a better quantity of help with this in some
mainframe-specific peer support group, as opposed to a language-specific
group such as this.
MCM
zalek
> "zalek" <zalekbl...@hotmail.com> wrote in message
I am using IBM MVS mainframe. Here is the error I am getting:
CEE3648S POSIX(ON) run-time option in a nested enclave TESTFTP is not
supported.
Zalek
Robert
This is a very common activity. It is normally done with either FTP or NDM, the mainframe
version of FTP. Normally, FTP is run in scripting language such as ksh or by the job
scheduler. To call it from Cobol, you don't call FTP, you call SYSTEM to create a child
process, passing it the command to run FTP and the FTP command, which will be MGET.
William M. Klein
I am not saying your answer isn't correct, but I haven't ever heard of
CALLing "SYSTEM" on MVS. (Possibly under Unix System Services, but that doesn't
seem to be what the OP is asking for). Are you certain that this is the way to
do this on MVS?
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <n...@e.mail> wrote in message
news:a24p8450m4tconemn...@4ax.com...
William M. Klein
will help or not, but you may want to look at:
http://www.simotime.com/cblsub01.htm
--
Bill Klein
wmklein <at> ix.netcom.com
"zalek" <zalek...@hotmail.com> wrote in message
news:498652f6-b265-4111...@d45g2000hsc.googlegroups.com...
docd...@panix.com
zalek <zalek...@hotmail.com> wrote:
>On Jul 27, 9:36 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
>> "zalek" <zalekbl...@hotmail.com> wrote in message
>>
>> news:498652f6-b265-4111...@d45g2000hsc.googlegroups.com...
>>
>> > Hello,
>>
>> > I need to send files from a mainframe to a Unix server from a Cobol
>> > program. I tried to call FTP - but without success. It has to be from
>> > a cobol program, because number of file varies depending on daily
>> > activity.
>> > Any ideas how to do it?
>>
>> How/why did FTP fail? I know others use FTP to do this, ergo it must be
>> do-able.
[snip]
>I am using IBM MVS mainframe. Here is the error I am getting:
>CEE3648S POSIX(ON) run-time option in a nested enclave TESTFTP is not
>supported.
The Quick entry for this error message contains:
--begin quoted text:
Programmer Response: Specify the POSIX(ON) run-time option for only the
first enclave. Make sure all nested enclaves specify POSIX(OFF).
--end quoted text
Rather than duplicate the errors, please post the code that caused this
error and things might proceed from there.
DD
SkippyPB
Another problem may be the system doesn't have a required APAR
installed. I found the following on IBM's website:
PQ97087: MESSAGE " CEE3648S POSIX(ON) RUN-TIME OPTION IN A NESTED
ENCLAVE REXEC IS NOT SUPPORTED. " IS ISSUED IN ZOS V1R5 AND ZOS V1R6.
The description is:
When REXEC is invoked within an application instead of a stand-
alone TSO command or via a batch job, and the application uses
the LE RTL (runtime libraries), then REXEC is considered to be
an enclave running within an enclave. In zOS V1R5, REXEC was
written in "C", and set POSIX(ON). With the implementation
described above, the following message would be issued
CEE3648S POSIX(ON) run-time option in a nested enclave REXEC
is not supported.
and the application would fail.
Invoking REXEC via TSO or batch works just fine.
KEYWORDS: REXEC CEE3648S POSIX(ON) LE OREXEC
VERIFICATION STEPS: Write an application and call REXEC via a
system() call. If above message is issued,
then this apar will address it.
Having not seen the original code that caused the error and since the
OP didn't tell us which IBM MVS system he/she was on, this is only a
guess that somehow the system thinks you are calling a REXEC routine
and the APAR to fix this problem hasn't been installed.
A workaround is:
Within the JCL that invokes the application, one may STEPLIB to
the zOS V1R4 loadlib which contains the REXEC module. Since
REXEC in V1R4 is written in PASCAL, it would have no bearing on
LE RTL.
Regards,
////
(o o)
-oOO--(_)--OOo-
"I went to a general store, but they wouldn't let me buy anything specific."
--Steven Wright
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
docd...@panix.com
SkippyPB <swie...@Nospam.neo.rr.com> wrote:
>On Sun, 27 Jul 2008 16:21:40 +0000 (UTC), docd...@panix.com () wrote:
>
>>In article <f875bbdf-168b-4f6c...@e53g2000hsa.googlegroups.com>,
>>zalek <zalek...@hotmail.com> wrote:
>>>On Jul 27, 9:36 am, "Michael Mattias" <mmatt...@talsystems.com> wrote:
>>>> "zalek" <zalekbl...@hotmail.com> wrote in message
>>>>
>>>> news:498652f6-b265-4111...@d45g2000hsc.googlegroups.com...
>>>>
>>>> > Hello,
>>>>
>>>> > I need to send files from a mainframe to a Unix server from a Cobol
>>>> > program.
[snip]
>>>I am using IBM MVS mainframe. Here is the error I am getting:
>>>CEE3648S POSIX(ON) run-time option in a nested enclave TESTFTP is not
>>>supported.
>>
>>The Quick entry for this error message contains:
>>
>>--begin quoted text:
>>
>>Programmer Response: Specify the POSIX(ON) run-time option for only the
>>first enclave. Make sure all nested enclaves specify POSIX(OFF).
>>
>>--end quoted text
>>
>>Rather than duplicate the errors, please post the code that caused this
>>error and things might proceed from there.
>>
>
>Another problem may be the system doesn't have a required APAR
>installed.
Ow ow ow... asking the Systems folks to participate can lead to
Interesting Times... but it might be necessary to do so.
(on my current site a while back I had to - based on Mr Yaeger's advice,
given in clear and unambiguous terms - ask the Systems folks to updgrade
DFSort to a version that'd allow for ICETOOL to interpret a code-set more
modern than Linear B... but I lucked out, the response was 'At last...
someone Out There *understands* us!' and now they ask into my good health
and the status of my nieces' algebra scores)
[snip]
>VERIFICATION STEPS: Write an application and call REXEC via a
> system() call. If above message is issued,
> then this apar will address it.
Hmmmmmm... smells like a right helpful hint, to me... if such skills are
to be found in the ones upon which the original poster might call.
>
>Having not seen the original code that caused the error and since the
>OP didn't tell us which IBM MVS system he/she was on, this is only a
>guess that somehow the system thinks you are calling a REXEC routine
>and the APAR to fix this problem hasn't been installed.
So... there's another that seems to say 'show what you've done', let's see
if the advice is taken.
DD
zalek
wrote:
> I think that this is usually done by using the "INTRDR". I don't know if it
> will help or not, but you may want to look at:
>
> http://www.simotime.com/cblsub01.htm
>
> --
> Bill Klein
Thanks Bill, but it is my solution to the problem I described -
unfortunately operations does not like it because it submits jobs
outside of a scheduler.
Thanks,
Zalek
> wmklein <at> ix.netcom.com"zalek" <zalekbl...@hotmail.com> wrote in message
zalek
Robert,
I know you can call FTP from REXX - but the program that will use FTP
is a complicated one, with access to DB2 - I don't want to write it in
REXX.
Can you give me more details how to call SYSTEM from Cobol?
MGET? I thought it is MQ command. Please explain.
Thanks,
Zalek
Richard
Ignore Robert's answer, he didn't read your question. Calling 'SYSTEM'
is what one might do on a Unix machine to run the ftp client program.
'mget' is the 'multiple-file-get' command to that ftp client program.
docd...@panix.com
zalek <zalek...@hotmail.com> wrote:
[snip]
>Thanks Bill, but it is my solution to the problem I described -
>unfortunately operations does not like it because it submits jobs
>outside of a scheduler.
Would it be asking too much to request to see a posting containing
something that you've attempted as a solution?
DD
Michael Mattias
<8e6f9752-6a61-4712...@d1g2000hsg.googlegroups.com>,
> zalek <zalek...@hotmail.com> wrote:
>
>>Thanks Bill, but it is my solution to the problem I described -
>>unfortunately operations does not like it because it submits jobs
>>outside of a scheduler.
If operations has that much clout, surely operations can tell you how they
want it done.
For damn sure if they can say "no" they ought to be able to tell you how
they *DO* want it done.
MCM
Robert
I thought you were 'pulling' the files on Unix rather than 'pushing' them from the
mainframe. From your questions, it now seems I was mistaken. In that case, ignore my
suggestion to call SYSTEM.
MGET is the FTP command for Multiple Get. If you are pushing multiple files, you would use
MPUT. But I don't know how to start FTP on z/OS and feed it that command.
Robert
I thought a non-native-English-speaker was using 'send' when he meant 'transmit'.The
requirement to send multiple files threw me off. Why doesn't the mainframe send ONE file
when it's created? When the number of files is unknown, that implies a client process.
William M. Klein
POSIX run-time option) on Unix?
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert" <n...@e.mail> wrote in message
news:bsiq84le0abmudvrr...@4ax.com...
Richard
In what way is 'transmit' different from 'send' such that you thought
it was 'fetch' ?
> The
> requirement to send multiple files threw me off.
> Why doesn't the mainframe send ONE file
> when it's created? When the number of files is unknown, that implies a client process.
Not at all. Haven't you heard of 'put' or 'mput' as ftp commands ?
It would seem that the process generating the files does not send them
but leaves that for some other program to do. It's called modularity.
There may be many reasons to uncouple the generation and the sending,
one that springs to mind is failure to connect, if the ftp step fails
it only needs repeating later rather than regenerating the data.
Another may be that if the transfer mechanism changes then the
generation of the data can remain the same while the ftp program is
replaced by, say, an MQ program.
Pete Dashwood
--
"I used to write COBOL...now I can do anything."
<snip>
>Here is my problem: I have one big file. I need to select few records
>from this big file (in the selection process I need to access DB2) and
>transmit this selected records as a file to a Unix server. Each
>selection must create a different file name - this is a request from
>the Unix user.
Seems pretty straightforward...
>My solution - a Cobol program builds a FTP job with JCL and parms and
>submits this job to the "INTRDR".
This is certainly an approach, but I don't think FTP is the right tool to
use here.
Think about what's happening...
Your COBOL program does some processing (including access to a DB2
database), creates a file, that gets transferred to the Unix system, where
some other program will read the file, process it, and probably use it to
update a DB2 database... :-) Doesn't that strike you as a bit unwieldy?
Why not use the facilities for data sharing that already exist in DB2 for
z/OS?
Suppose, instead of creating an "extract file" you simply updated a
designated table on the Unix machine's database, DIRECTLY from z/OS. You get
all the benefits of SQL transaction isolation (if it fails) and have
complete flexibility in what is exported. (easily changed if it needs to
be). It runs under the standard TCP/IP protocol which you really don't have
to know much about because it is transparent and "under the covers"
In fact most of your solution is then SQL, (CONNECT and INSERT to the UNIX
machine) even though driven from COBOL. No files, no OPENs, CLOSES,
re-OPENS, etc. no JCL, no schedulers, no hassles... :-)
Here are complete details, with an example using z/OS to UNIX, in case you
want to think about this.
http://www.ibm.com/developerworks/db2/library/techarticle/0310chong/0310chong.html
HTH
Pete.
docd...@panix.com
<hay...@gmail.com> wrote:
>On Jul 27, 9:05 pm, docdw...@panix.com () wrote:
>> In article <8e6f9752-6a61-4712-8ef9-ab3074539...@d1g2000hsg.googlegroups.com>,
>>
>> zalek <zalekbl...@hotmail.com> wrote:
>>
>> [snip]
>>
>> >Thanks Bill, but it is my solution to the problem I described -
>> >unfortunately operations does not like it because it submits jobs
>> >outside of a scheduler.
>>
>> Would it be asking too much to request to see a posting containing
>> something that you've attempted as a solution?
>
Here is *my* problem: I see constant requests for assistance without any
evidence whatsoever that something's being done on your end besides
absorbing the work and knowledge that others offer.
Second request: please post something containing one of your own attempts
at a solution and the reasons that this attempt does not satisfy your
requirements.
DD
Howard Brazee
I wrote a CoBOL program that wrote the FTP commands to a file - then
the FTP job read that file and executed it.
In my case that was to create the file names depending on passed
parms.
SkippyPB
wrote:
About 5 years ago a colleague and I wrote a system to pass 6 files
from a consumer loan system to a UNIX server so that the data could be
combined with other loan system data from other sources and a
comprehensive report could be produced on the UNIX system. We did
this by writing out delimited sequential files with headers and
trailers the UNIX system needed. We then used a utility caused
Connect Direct to transmit the delimited files to the UNIX.
CA-Scheduler would not run the Connect Direct job(s) until the jobs
that created the files were successfully run. To the best of my
knowledge, this system/procedure is still in use today. It took my
colleague and I about 2 months to write and test the programs all
written in COBOL.
Regards,
////
(o o)
-oOO--(_)--OOo-
"We have a firm commitment to NATO, we are a part of NATO. We have a
firm commitment to Europe. We are a part of Europe."
-- Dan Quayle
Howard Brazee
<swie...@Nospam.neo.rr.com> wrote:
>We then used a utility caused
>Connect Direct to transmit the delimited files to the UNIX.
>CA-Scheduler would not run the Connect Direct job(s) until the jobs
>that created the files were successfully run.
Our CA-FTP job has the same kind of problem in using the FTP parms
written in the same job. It has to be two jobs.
Arnold Trembley
We use Connect:Direct to send files to other mainframes and to Unix
Servers. I think the product may have been called NDM (Network Data
Mover) in an earlier incarnation.
http://www.sterlingcommerce.com/Products/MFT/
Our scheduler on z/OS is Tivoli/OPC. We have some situations where
our scheduler will automatically kick off a "send" job when a file is
created. There are a couple of things to be aware of. A batch job to
"send" a file using Connect:Direct could complete successfully, but
the actual file transfer could fail, because it's a separate process
which may not even start until after the "send" job has successfully
completed. All it does is make a file available to Connect:Direct for
transmission. There's no notification back to the batch job. I'm not
sure if the target system needs Connect:Direct software to receive the
file, although that seems to be the way it works under z/OS.
As a developer I found Connect:Direct to be less user-friendly than
another tool we used to have, which I think was called XCOM. But that
one only seemed to work for mainframe-to-mainframe file transfer. C:D
appears to be have faster transmit times.
With Connect:Direct, the sending job needs a control card which
contains the name of another control card containing the actual
Connect:Direct commands. That's a minor inconvenience for a
production job, but kind of a pain when you need to send a random test
file to a test system.
Anyway, that's just my opinion. Your mileage may vary.
HeyBub
It's hard to beat the bandwidth of a 747 filled with mag tape.