View previous topic :: View next topic
|
Author |
Message |
jerryte
Active User
Joined: 29 Oct 2010 Posts: 202 Location: Toronto, ON, Canada
|
|
|
|
I want to call a REXX from a cobol program. The REXX will do a LISTDSI to get the dataset name assigned to a dd. I need to pass the name back to COBOL. Not sure if there is another way to get the name.
To pass back the name I thought of getting the address of a variable in the COBOL program, then convert it to a display number, and pass this to my routine. Rexx can then convert the number to a hex address and use the STORAGE function to update.
Is there an easier way? If I do a PUSH onto a data stack then is there a call in COBOL I can use to get the data? |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Is there some reason you want to use rexx? By chasing "control blocks" you can find a dataset name for a DD statememt in cobol . . . |
|
Back to top |
|
|
jerryte
Active User
Joined: 29 Oct 2010 Posts: 202 Location: Toronto, ON, Canada
|
|
|
|
dick scherrer wrote: |
By chasing "control blocks" you can find a dataset name for a DD statememt in cobol . . . |
That requires Assembler and I don't know it well enough. Rexx is so much easier |
|
Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006 Posts: 1353 Location: Israel
|
|
|
|
You can use ISPF services: VPUT in your rexx program, and VGET in your cobol. |
|
Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
|
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
That requires Assembler and I don't know it well enough. Rexx is so much easier |
Actually, no it does not. You can find the DSN name for a DD name using nothing but pure COBOL statements. |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
|
|
|
|
Why do you actually need to know the name of an output dataset ? |
|
Back to top |
|
|
jerryte
Active User
Joined: 29 Oct 2010 Posts: 202 Location: Toronto, ON, Canada
|
|
|
|
I didn't think it was possible to use COBOL to access the control blocks.
I am still looking for a more general answer of passing data from a rexx back to COBOL. I could write to a file but there should be a simplier way. If I use IRXJCL to invoke the rexx then it will initialize an environment. Can I then use IRXEXCOM to access the rexx variables after calling the rexx? Has anyone tried this? |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
|
|
|
|
expat wrote: |
Why do you actually need to know the name of an output dataset ? |
|
|
Back to top |
|
|
jerryte
Active User
Joined: 29 Oct 2010 Posts: 202 Location: Toronto, ON, Canada
|
|
|
|
expat wrote: |
Why do you actually need to know the name of an output dataset ? |
This is the requirement that was given to me. The designers want the name of the input dataset to be written to an output dataset. My job is to find a way to make it work. They pay my salary - I code the programs. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
Quote: |
They pay my salary |
not our salary!
since You ask and we reply that gives us some more privileges !
since we do not get paid we are free to ask question
remember, replying is on
voluntary base
our own time
our own equipment
free of charge
interest in the argument of the topic
anyway there is no general no easy way of getting back values from REXX to any language
environment settings, control block mangling, not worth the effort at all
it would be wiser to review the architecture
( for example having rexx as the orchestra director instead of COBOL or whatsoever ) |
|
Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
|
|
|
|
Jerry no inference on you, but where on earth do these hairbrained requirements come from ???
I'm not sure but LISTDSI may only return the first dataset in a concatenation, so if for some reason there is a concatenated input then you may be creating a wrong output file. |
|
Back to top |
|
|
Pedro
Global Moderator
Joined: 01 Sep 2006 Posts: 2546 Location: Silicon Valley
|
|
|
|
Agree with Marso: VPUT in your rexx program, and VGET in your cobol |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
jerryte wrote: |
I didn't think it was possible to use COBOL to access the control blocks.
I am still looking for a more general answer of passing data from a rexx back to COBOL. I could write to a file but there should be a simplier way. If I use IRXJCL to invoke the rexx then it will initialize an environment. Can I then use IRXEXCOM to access the rexx variables after calling the rexx? Has anyone tried this? |
Yes, I have done this, but not in the same context that you are faced with. In my case the Rexx called the Cobol program, and the Cobol program used IRXEXCOM to retrieve/set Rexx variables that were later used by the calling Rexx. |
|
Back to top |
|
|
jerryte
Active User
Joined: 29 Oct 2010 Posts: 202 Location: Toronto, ON, Canada
|
|
|
|
expat wrote: |
Jerry no inference on you, but where on earth do these hairbrained requirements come from ???
I'm not sure but LISTDSI may only return the first dataset in a concatenation, so if for some reason there is a concatenated input then you may be creating a wrong output file. |
I ask that question myself sometimes.
In this case there is only one dataset but it is a gdg so the name changes every time a generation is created.
I could do the reverse ie. use a rexx to get the name and then call the cobol program and pass the name in as a parameter.
Thanks to everyone for your input. I will figure something out. |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
I once saw a system with a similar requirement. Many years ago, Canadian banks exchanged payment information via physical tapes. The payment exchange application was required to produce a report listing the DSN and VOLSER of all the tapes it created. This was used as a 'packing list' for the mailroom when they shipped the tapes.
The application used a locally developed Assembler subroutine to obtain the DSN and VOLSER information. |
|
Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006 Posts: 792 Location: Pennsylvania
|
|
|
|
You could call the rexx program in step1 of the jcl, allocate the output file as disp=new and write the dataset name as the first and only record.
In step2 you could call your cobol program unchanged, with the output dataset allocated as disp=mod.
Just an option. |
|
Back to top |
|
|
ofer71
Global Moderator
Joined: 27 Dec 2005 Posts: 2358 Location: Israel
|
|
|
|
You may also invoke the TSO command LISTALC from within COBOL and parse the results (SYSTSPRT).
O. |
|
Back to top |
|
|
acevedo
Active User
Joined: 11 May 2005 Posts: 344 Location: Spain
|
|
|
|
I have programs calling an assembler routine to get the DSNAME for a DDNAME, 'surfing' Data Areas from Cobol...but when a peer asked me for the cleanest method... I just coded a Rexx like this:
Quote: |
/*Rexx */
arg DDNAME
X = LISTDSI(DDNAME "FILE")
queue LEFT(SYSDSNAME,44) Syslrecl SYSrecfm
"execio 1 diskw DDINFO"
Exit |
and the cobol program just read the DDINFO.
just my 2 cents. |
|
Back to top |
|
|
acevedo
Active User
Joined: 11 May 2005 Posts: 344 Location: Spain
|
|
|
|
the code of the previous post belongs to a version in which the file is included in the step of the rexx program in the same way as in the Cobol program, other version could be:
Code: |
/*Rexx */
arg DsNAME
X = listdsi("'"dsname"'" )
queue LEFT(SYSDSNAME,44) Syslrecl SYSrecfm
"execio 1 diskw DDINFO"
Exit
|
;) |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
I have programs calling an assembler routine to get the DSNAME for a DDNAME, 'surfing' Data Areas from Cobol... |
Does your "COBOL only" code work in z/OS 1.9? There have been a couple of COBOL routines posted here (in the forum) but when i tried to use them on a client machine, they did not work completely correctly (problem with actually returning the dsn).
A couple of my clients have no REXX expertise and are unwilling to use "stuff" they feel they cannot support. . .
Are you willing/able to post your routine? If not, no problem, i'll just delete this part of the topic |
|
Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006 Posts: 1353 Location: Israel
|
|
|
|
Or you could agree with Pedro:
Pedro wrote: |
Agree with Marso: VPUT in your rexx program, and VGET in your cobol |
|
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
for the long windy, useless road check FAN140.SEAGSAM(EAGGXCOB)
for an easier way google for COBOL DDNAME and You should get a link to something like
Getting DSN name in a COBOL program - Application Forum at ...
which contain a cobol code snippet that will do just that...
given an allocated DDNAME return the DSNAME
did not seem so complicated to me to google |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
did not seem so complicated to me to google |
Yup, easy to Google and get "hits". Unfortunately, none of the code i tried would work correctly on the client's 1.9 system - which is not scheduled to be upgraded uneil sometime next year. . .
d |
|
Back to top |
|
|
acevedo
Active User
Joined: 11 May 2005 Posts: 344 Location: Spain
|
|
|
|
dick scherrer wrote: |
Are you willing/able to post your routine? If not, no problem, i'll just delete this part of the topic |
OF COURSE, we are here under 1.9 and this code runs fine, I remember translating from Rexx to cobol the SWAREQ function, change it according to your needs, or make it a module as we did it here, nowadays we have only the Rexx and Assembler options.
Code: |
CBL TRUNC(BIN)
*================================================================*
* DSNAMES desde la DSAB *
*
*
* /*--------------------------------------------------------------
* swareq: procedure
* if right(c2x(arg(1)),1)¬=translate('F') then /* swa=below ?
* return c2d(arg(1))+16 /* yes, return sva+16
* numeric digits 10 /* allow up to 7ffffff
* sva=c2d(arg(1)) /* convert to decimal
* tcb = c2d(storage(21c,4)) /* tcb psatold
* jscb = c2d(storage(d2x(tcb+180),4)) /* jscb tcbjscb
* qmpl = c2d(storage(d2x(jscb+244),4)) /* qmpl jscbqmp
* qmat = c2d(storage(d2x(qmpl+24),4)) /* qmat qmadd
* do while sva>65536
* qmat = c2d(storage(d2x(qmat+12),4)) /* next qmat qmat+12
* sva=sva-65536 /* 010006f -> 000006f
* end
* return c2d(storage(d2x(qmat+sva+1),4))+16
*
*--------------------------------------------------------------
* identification division
*================================================================*
identification division.
program-id. qw3calo.
data division.
*----------------------------------------------------------------*
* working-storage section
*----------------------------------------------------------------*
working-storage section.
01 filler.
05 swa-place pic x(5).
05 four-bytes.
10 w-binary-4 pic s9(8) comp.
10 w-pointer-4 redefines w-binary-4 pointer.
05 w-binary pic s9(8) comp.
*----------------------------------------------------------------*
* linkage section
*----------------------------------------------------------------*
linkage section.
01 psa.
05 filler pic x(540).
05 psatold pointer.
01 tcb.
05 filler pic x(180).
05 tcbjscb pointer.
01 jscb.
05 filler pic x(244).
05 jscbqmpi pointer.
05 filler pic x(13).
05 jscjctp pic x(3).
05 filler pic x(56).
05 jscdsabq pointer.
01 jct.
05 filler pic x(31).
05 jctjcsmf pic x.
05 filler pic x(84).
05 jctstat2 pic x.
* 01 qmpl. pic x(32).
01 qmpl.
05 filler pic x(24).
05 qmat-x.
10 qmat-fw pic s9(8) comp.
10 qmat-p redefines qmat-fw pointer.
01 qmat.
10 filler pointer occurs 16384.
01 qdb.
05 filler pic x(12).
05 dsqfrstp pointer.
01 dsab.
05 dsabid pic x(4).
05 dsabfchn pointer.
05 filler pic x(13).
05 dsabssva pic x(3).
05 filler pic x(24).
05 dsabssnm pic x(4).
01 siot.
05 filler pic x(4).
05 sctddnam pic x(8).
05 filler pic x(144).
05 sjfcbptr pointer.
01 jfcb.
05 jfcbdsnm pic x(44).
05 jfcbelem pic x(8).
05 filler pic x(66).
05 jfcbvols pic x(30).
procedure division.
set address of psa to null
set address of tcb to psatold
set address of jscb to tcbjscb
set address of qmpl to jscbqmpi
set address of qdb to jscdsabq
set address of dsab to dsqfrstp
** determinar emplazamiento de la swa
move jscjctp to four-bytes(2:3)
add 16 to w-binary-4
set address of jct to w-pointer-4
move jctstat2 to four-bytes(4:1)
divide w-binary-4 by 2 giving w-binary-4 remainder w-binary
if w-binary = 1 then
move 'ABOVE' to swa-place
else
move 'BELOW' to swa-place
end-if
display ' class=' jctjcsmf
' swa=' swa-place
** recuperar allocates desde la dsab.
perform varying w-binary-4 from 1 by 1
until dsabid not = 'DSAB'
move dsabssva to four-bytes(2:3)
if swa-place = 'ABOVE' then
* set address of qmat to qmat-p
move low-values to four-bytes(1:1)
compute w-binary-4 = w-binary-4 + qmat-fw + 1
set address of qmat to w-pointer-4
move qmat(1:4) to four-bytes
end-if
add 16 to w-binary-4
set address of siot to w-pointer-4
set address of jfcb to sjfcbptr
if dsabssnm = low-values then
display ' ddname=' sctddnam
' dsname=' jfcbdsnm
' member=' jfcbelem
' volser=' jfcbvols
else
display ' ddname=' sctddnam
' dsname=' jfcbdsnm
' subsys=' dsabssnm
' class=' siot(81:1)
' form=' siot(77:4)
end-if
* proximo
set address of dsab to dsabfchn
end-perform
goback.
|
dick scherrer wrote: |
A couple of my clients have no REXX expertise and are unwilling to use "stuff" they feel they cannot support. . . : |
I'm not a Cobol expert nor a Rexx expert, but IMHO this:
Code: |
/*Rexx */
arg DDNAME
X = LISTDSI(DDNAME "FILE")
queue LEFT(SYSDSNAME,44) Syslrecl SYSrecfm
"execio 1 diskw DDINFO"
Exit |
it's much easier to maintain and understand than the Cobol option.
hth
;) |
|
Back to top |
|
|
|