Stored Procedures in OS/390 V6

[Rhino]

This question relates to DB2 Version 6 on OS/390.

Can a (COBOL) stored procedure on this platform do file I/O, i.e. write to a
sequential file?

I am trying to debug a stored procedure. As far as I know, DB2 stored
procedures cannot do terminal I/O on any operating system but I know that
(Java) stored procedures in Windows/Linux/Unix can write to files and I have
done this many times.

I am trying to do the same thing in OS/390 but nothing is getting written to
my file. As a result, I can't tell if the client is failing to get into the
stored procedure or not. Maybe it is getting into the stored proc just fine
but COBOL stored procs in OS/390 can't do file I/O, unlike the case in
Windows.

Unfortunately, I haven't yet found anything in the manuals I've consulted to
say one way or the other if COBOL stored procs can do file I/O in DB2 V6 on
OS/390.

Can anyone clarify if I can do file I/O in my circumstances? I really just
want to write a few lines *somewhere* so that I can verify that the stored
proc was entered and what happened when it was there.

Rhino

[klh]

If you just want to debug, you can use a COBOL DISPLAY in a COBOL
Stored Procedure.

The output gets written to the DB2 job used to start the stored
procedure address space.

HTH,
klh

Can anyone clarify if I can do file I/O in my circumstances? I really just want to write a few lines *somewhere* so that I can verify that the stored proc was entered and what happened when it was there.

Rhino

[Walter Schneider]

Hello,

your stored procedure COBOL program can do almost *anything* because DB2 is
not aware about the program statements as long as they do not refer to DB2
itself. So you can write records to any file you want, but this file must be
associated with an OS data set or JES SYSOUT by a "//filename DD..." JCL
statement contained within the DB2 stored procedure address space startup
JCL. For debugging purposes your systems administrator should already have
included a //SYSPRINT DD - Statement there which can be used as standard
COBOL output.

Regards - Walter SCHNEIDER.
"Rhino" <rh****@NOSPAM.sympatico.ca> schrieb im Newsbeitrag
news:gV******************@news20.bellglobal.com...

This question relates to DB2 Version 6 on OS/390.

Can a (COBOL) stored procedure on this platform do file I/O, i.e. write to a sequential file?

I am trying to debug a stored procedure. As far as I know, DB2 stored
procedures cannot do terminal I/O on any operating system but I know that
(Java) stored procedures in Windows/Linux/Unix can write to files and I have done this many times.

I am trying to do the same thing in OS/390 but nothing is getting written to my file. As a result, I can't tell if the client is failing to get into the stored procedure or not. Maybe it is getting into the stored proc just fine but COBOL stored procs in OS/390 can't do file I/O, unlike the case in
Windows.

Unfortunately, I haven't yet found anything in the manuals I've consulted to say one way or the other if COBOL stored procs can do file I/O in DB2 V6 on OS/390.

Can anyone clarify if I can do file I/O in my circumstances? I really just
want to write a few lines *somewhere* so that I can verify that the stored
proc was entered and what happened when it was there.

Rhino

[Rhino]

I didn't know that 'display' statements ended up in that job! When they
didn't come out on the screen, I assumed that you couldn't do displays at
all. Stored procs in DB2 for Windows/Linux/Unix are not allowed to do screen
I/O at all so I assumed it was the same for DB2 on OS/390. I'm glad to hear
that I'm wrong; display statements are less hassle than writing to a file!

Thanks for sharing that information, it has really helped me get to the
bottom of my problem (or at least one of them).

Rhino

"klh" <kh******@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

If you just want to debug, you can use a COBOL DISPLAY in a COBOL
Stored Procedure.

The output gets written to the DB2 job used to start the stored
procedure address space.

HTH,
klh

Can anyone clarify if I can do file I/O in my circumstances? I really

just

want to write a few lines *somewhere* so that I can verify that the

stored

proc was entered and what happened when it was there.

Rhino

[Rhino]

I see!

That explains a lot. After I had seen klh's note about display statements
appearing in the job that starts the DB2 stored procedure address spaces, I
saw a message that I was generating about the log file; the message said the
file status after attempting to open the log file was 96. After looking up
the meaning of that status, I found that it was complaining that it didn't
have a DD statement for the log file and I was baffled because I had
provided a DD statement and I couldn't see anything wrong with it.

Your note has solved the mystery; I put the DD statement in the job that ran
the client which invoked the stored procedure but that was the wrong place:
it should have been in the job that starts the stored proc!!

I'm probably not going to be able to change the JCL for the stored proc
address space to include my log file but it doesn't matter as long as my
displays show up in the DSN1SPAS job. That means I don't need the log file
in the first place, which will make debugging a bit easier.

I'm glad I know why the log file wouldn't open though; that was really
bothering me!

Thanks!!
Walter Schneider" <wa**************@telekom.at.nospam> wrote in message
news:42***********************@newsreader02.highwa y.telekom.at...

Hello,

your stored procedure COBOL program can do almost *anything* because DB2 is not aware about the program statements as long as they do not refer to DB2
itself. So you can write records to any file you want, but this file must be associated with an OS data set or JES SYSOUT by a "//filename DD..." JCL
statement contained within the DB2 stored procedure address space startup
JCL. For debugging purposes your systems administrator should already have
included a //SYSPRINT DD - Statement there which can be used as standard
COBOL output.

Regards - Walter SCHNEIDER.
"Rhino" <rh****@NOSPAM.sympatico.ca> schrieb im Newsbeitrag
news:gV******************@news20.bellglobal.com...

This question relates to DB2 Version 6 on OS/390.

Can a (COBOL) stored procedure on this platform do file I/O, i.e. write to

a

sequential file?

I am trying to debug a stored procedure. As far as I know, DB2 stored
procedures cannot do terminal I/O on any operating system but I know

that (Java) stored procedures in Windows/Linux/Unix can write to files and I

have

done this many times.

I am trying to do the same thing in OS/390 but nothing is getting written to

my file. As a result, I can't tell if the client is failing to get into the

stored procedure or not. Maybe it is getting into the stored proc just

fine

but COBOL stored procs in OS/390 can't do file I/O, unlike the case in
Windows.

Unfortunately, I haven't yet found anything in the manuals I've

consulted to

say one way or the other if COBOL stored procs can do file I/O in DB2 V6

on

OS/390.

Can anyone clarify if I can do file I/O in my circumstances? I really

just want to write a few lines *somewhere* so that I can verify that the stored proc was entered and what happened when it was there.

Rhino

[wfs]

>>I'm probably not going to be able to change the JCL for the stored proc

you could always dynamically allocate the datasets...

Bill
"Rhino" <rh****@NOSPAMsympatico.ca> wrote in message
news:So********************@news20.bellglobal.com. ..

I see!

That explains a lot. After I had seen klh's note about display statements
appearing in the job that starts the DB2 stored procedure address spaces,
I
saw a message that I was generating about the log file; the message said
the
file status after attempting to open the log file was 96. After looking up
the meaning of that status, I found that it was complaining that it didn't
have a DD statement for the log file and I was baffled because I had
provided a DD statement and I couldn't see anything wrong with it.

Your note has solved the mystery; I put the DD statement in the job that
ran
the client which invoked the stored procedure but that was the wrong
place:
it should have been in the job that starts the stored proc!!

I'm probably not going to be able to change the JCL for the stored proc
address space to include my log file but it doesn't matter as long as my
displays show up in the DSN1SPAS job. That means I don't need the log file
in the first place, which will make debugging a bit easier.

I'm glad I know why the log file wouldn't open though; that was really
bothering me!

Thanks!!
Walter Schneider" <wa**************@telekom.at.nospam> wrote in message
news:42***********************@newsreader02.highwa y.telekom.at...

Hello,

your stored procedure COBOL program can do almost *anything* because DB2

is

not aware about the program statements as long as they do not refer to
DB2
itself. So you can write records to any file you want, but this file must

be

associated with an OS data set or JES SYSOUT by a "//filename DD..." JCL
statement contained within the DB2 stored procedure address space startup
JCL. For debugging purposes your systems administrator should already
have
included a //SYSPRINT DD - Statement there which can be used as standard
COBOL output.

Regards - Walter SCHNEIDER.
"Rhino" <rh****@NOSPAM.sympatico.ca> schrieb im Newsbeitrag
news:gV******************@news20.bellglobal.com...

> This question relates to DB2 Version 6 on OS/390.
>
> Can a (COBOL) stored procedure on this platform do file I/O, i.e. write to

a

> sequential file?
>
> I am trying to debug a stored procedure. As far as I know, DB2 stored
> procedures cannot do terminal I/O on any operating system but I know

that > (Java) stored procedures in Windows/Linux/Unix can write to files and I

have

> done this many times.
>
> I am trying to do the same thing in OS/390 but nothing is getting written

to

> my file. As a result, I can't tell if the client is failing to get into

the

> stored procedure or not. Maybe it is getting into the stored proc just

fine

> but COBOL stored procs in OS/390 can't do file I/O, unlike the case in
> Windows.
>
> Unfortunately, I haven't yet found anything in the manuals I've

consulted

to

> say one way or the other if COBOL stored procs can do file I/O in DB2
> V6

on

> OS/390.
>
> Can anyone clarify if I can do file I/O in my circumstances? I really

just > want to write a few lines *somewhere* so that I can verify that the stored > proc was entered and what happened when it was there.
>
> Rhino
>
>