IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Pass data back from Rexx to COBOL


IBM Mainframe Forums -> CLIST & REXX
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
jerryte

Active User


Joined: 29 Oct 2010
Posts: 202
Location: Toronto, ON, Canada

PostPosted: Tue Dec 21, 2010 4:15 am
Reply with quote

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
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Tue Dec 21, 2010 4:23 am
Reply with quote

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
View user's profile Send private message
jerryte

Active User


Joined: 29 Oct 2010
Posts: 202
Location: Toronto, ON, Canada

PostPosted: Tue Dec 21, 2010 4:32 am
Reply with quote

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
View user's profile Send private message
Marso

REXX Moderator


Joined: 13 Mar 2006
Posts: 1353
Location: Israel

PostPosted: Tue Dec 21, 2010 4:42 am
Reply with quote

You can use ISPF services: VPUT in your rexx program, and VGET in your cobol.
Back to top
View user's profile Send private message
superk

Global Moderator


Joined: 26 Apr 2004
Posts: 4652
Location: Raleigh, NC, USA

PostPosted: Tue Dec 21, 2010 5:55 am
Reply with quote

You might want to review this previous topic.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Dec 21, 2010 7:50 am
Reply with quote

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
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Tue Dec 21, 2010 1:00 pm
Reply with quote

Why do you actually need to know the name of an output dataset ?
Back to top
View user's profile Send private message
jerryte

Active User


Joined: 29 Oct 2010
Posts: 202
Location: Toronto, ON, Canada

PostPosted: Tue Dec 21, 2010 7:30 pm
Reply with quote

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
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Tue Dec 21, 2010 7:38 pm
Reply with quote

expat wrote:
Why do you actually need to know the name of an output dataset ?
Back to top
View user's profile Send private message
jerryte

Active User


Joined: 29 Oct 2010
Posts: 202
Location: Toronto, ON, Canada

PostPosted: Tue Dec 21, 2010 8:26 pm
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Dec 21, 2010 8:41 pm
Reply with quote

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
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Tue Dec 21, 2010 8:50 pm
Reply with quote

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
View user's profile Send private message
Pedro

Global Moderator


Joined: 01 Sep 2006
Posts: 2546
Location: Silicon Valley

PostPosted: Tue Dec 21, 2010 9:05 pm
Reply with quote

Agree with Marso: VPUT in your rexx program, and VGET in your cobol
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Tue Dec 21, 2010 9:15 pm
Reply with quote

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
View user's profile Send private message
jerryte

Active User


Joined: 29 Oct 2010
Posts: 202
Location: Toronto, ON, Canada

PostPosted: Tue Dec 21, 2010 10:58 pm
Reply with quote

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
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Tue Dec 21, 2010 11:26 pm
Reply with quote

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
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania

PostPosted: Tue Dec 21, 2010 11:36 pm
Reply with quote

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
View user's profile Send private message
ofer71

Global Moderator


Joined: 27 Dec 2005
Posts: 2358
Location: Israel

PostPosted: Tue Dec 21, 2010 11:43 pm
Reply with quote

You may also invoke the TSO command LISTALC from within COBOL and parse the results (SYSTSPRT).

O.
Back to top
View user's profile Send private message
acevedo

Active User


Joined: 11 May 2005
Posts: 344
Location: Spain

PostPosted: Wed Dec 22, 2010 6:15 pm
Reply with quote

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
View user's profile Send private message
acevedo

Active User


Joined: 11 May 2005
Posts: 344
Location: Spain

PostPosted: Wed Dec 22, 2010 7:14 pm
Reply with quote

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
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Wed Dec 22, 2010 8:47 pm
Reply with quote

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 icon_wink.gif
Back to top
View user's profile Send private message
Marso

REXX Moderator


Joined: 13 Mar 2006
Posts: 1353
Location: Israel

PostPosted: Wed Dec 22, 2010 8:50 pm
Reply with quote

Or you could agree with Pedro:
Pedro wrote:
Agree with Marso: VPUT in your rexx program, and VGET in your cobol
icon_smile.gif
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Wed Dec 22, 2010 10:27 pm
Reply with quote

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 icon_cool.gif
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Thu Dec 23, 2010 12:43 am
Reply with quote

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
View user's profile Send private message
acevedo

Active User


Joined: 11 May 2005
Posts: 344
Location: Spain

PostPosted: Thu Dec 23, 2010 3:02 pm
Reply with quote

dick scherrer wrote:

Are you willing/able to post your routine? If not, no problem, i'll just delete this part of the topic icon_wink.gif



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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CLIST & REXX Goto page 1, 2  Next

 


Similar Topics
Topic Forum Replies
No new posts Replace each space in cobol string wi... COBOL Programming 2
No new posts Running REXX through JOB CLIST & REXX 13
No new posts Error to read log with rexx CLIST & REXX 11
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
No new posts isfline didnt work in rexx at z/OS ve... CLIST & REXX 7
Search our Forums:

Back to Top