Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

LH moving zero

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler
View previous topic :: :: View next topic  
Author Message
Douglas Allen

New User


Joined: 24 Jul 2012
Posts: 10
Location: United States

PostPosted: Tue Mar 25, 2014 7:25 am    Post subject: LH moving zero
Reply with quote

Ok, the assembler novice here again. The program I'm attempting to write is an E15 exit for sort. The input file is variable length. The first 3000 (+RDW) bytes are always present. The final 250 bytes are always the same data area and what is in between varies.

So, I want to move the first 3004 bytes, then calculate where the final 250 bytes begin. Here is what I have so far:

Code:
IMSRTEXB CSECT
         SIEQREG
         STM   R14,R12,12(13)
         BASR  R12,R0
         USING *,R12
         ST    R13,SAVE+4
         LA    R14,SAVE          SET FORWARD POINTER
         ST    R14,8(R13)        IN SAVE AREA
         LR    R13,R14           SET OUR SAVE AREA ADDR IN R13
***********************************************************************
*  THE PROGRAM RECEIVES THE COMPRESSED IM MASTER FROM SORT AND WILL   *
*  RETURN THE FIXED PORTION FOLLOWED IMMEDIATELY BY THE DC TRAILER    *
***********************************************************************
         LR    R2,R1             SAVE PARM AREA
         L     R3,0(,R2)         LOAD ADDRESS OF THE PASSED RECORD
         LTR   R3,R3             CHECK FOR EOF.  THE ADDR IS 0
         BZ    EOF               WE ARE DONE
***********************************************************************
*  MOVE THE FIXED PORTION OF THE MASTER TO THE OUTPUT AREA
***********************************************************************
         LA    R6,OFIXEDR
         LA    R7,3004
         LR    R8,R3
         LA    R9,3004
         MVCL  R6,R8
         MVI   OFIXEDR+6,C'D'
         MVC   ODCTR(2),0(R3)


Up this point in the program, things work. I put that move of a "D" to that position so that I could verify that the output was truly being manipulated by this program. It is. So I know I moved the first 3004 bytes of the input to the output and successfully pointed to the output area (which is further down in the program.

So, next I have these statement:

Code:
***********************************************************************
*  MOVE THE DC TRAILER AREA NEXT TO OUTPUT FIXE PORTION
***********************************************************************
         LH    R4,0(,R3)         GET INPUT RDW
         SH    R4,DCLEN          SUBTRACT DC LENGTH
         STH   R4,DCDISP         MOVE DC DISPLACEMENT TO DCDISP
         STH   R4,ODCLEN
         LA    R10,L'DCDISP(R0,R3)  ADDRESS OF INPUT DC TRLR TO R10??

R3 is still the address of the original input record. The first halfword of which is the RDW. But when the LH executes to move the half word at address in R3, it always places zero in R4. Always. At least that is what it appears to do in Xpeditor. I don't understand why this is so. I copied this from other examples.

Thoughts? I will be happy to provide additional information that may be needed.
Back to top
View user's profile Send private message

steve-myers

Active User


Joined: 30 Nov 2013
Posts: 461
Location: The Universe

PostPosted: Tue Mar 25, 2014 9:09 am    Post subject:
Reply with quote

LA R10,L'DCDISP(R0,R3)

I find this confusing. Are you trying to use reg 0 as an index register? I hate tell you, but register 0 cannot be used as either an index register or a base register. R10,L'DCDISP(R0,R3) is usually coded as R10,L'DCDISP(,R3). The generated object code is the same, but it avoids showing R0 as a pseudo index register.

In general, the code you provide cannot be analyzed because the definition for many data areas mentioned in the code is not shown; a prime - though by no means the only example - is DCDISP.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2422
Location: Netherlands, Amstelveen

PostPosted: Tue Mar 25, 2014 2:11 pm    Post subject:
Reply with quote

Well Douglas, you didnt even respond on your S0C4 topic.

And now you are dropping a new one, that is as incomplete
as the previous one.

What do you expect? Us running around wild guessing what the hell
is going on?

Has this maybe all to do with your E15 Sort exit?
Back to top
View user's profile Send private message
Douglas Allen

New User


Joined: 24 Jul 2012
Posts: 10
Location: United States

PostPosted: Tue Mar 25, 2014 6:22 pm    Post subject:
Reply with quote

You are right, I failed to respond to the other thread that I had gotten past the 0C4 and I apologize. Someone else looking at my program pointed out that I didn't need the DSECT since my area wasn't over 4096. Sorry to all. I thought it best to begin this thread because the problem had changed. My bad.

And no, I don't expect anyone to be "running around" doing anything. If my posts need more info, I again apologize. If everyone is as busy as I am, I value your time, your experience and knowledge. I wish not to waste anyone's time.

Yes, I am trying to put together a simple E15 exit. I am about to throw it in the trash can but have decided to reach out for some other opinions.

So, I will try to post enough information once again and if I can't get it right, I will just go away.

Code:
IMSRTEXB CSECT
         SIEQREG
         STM   R14,R12,12(13)
         BASR  R12,R0
         USING *,R12
         ST    R13,SAVE+4
         LA    R14,SAVE          SET FORWARD POINTER
         ST    R14,8(R13)        IN SAVE AREA
         LR    R13,R14           SET OUR SAVE AREA ADDR IN R13
***********************************************************************
*  THE PROGRAM RECEIVES THE COMPRESSED IM MASTER FROM SORT AND WILL   *
*  RETURN THE FIXED PORTION FOLLOWED IMMEDIATELY BY THE DC TRAILER    *
***********************************************************************
         LR    R2,R1             SAVE PARM AREA
         L     R3,0(,R2)         LOAD ADDRESS OF THE PASSED RECORD
         LTR   R3,R3             CHECK FOR EOF.  THE ADDR IS 0
         BZ    EOF               WE ARE DONE
***********************************************************************
*  MOVE THE FIXED PORTION OF THE MASTER TO THE OUTPUT AREA
***********************************************************************
         LA    R6,OFIXEDR
         LA    R7,3004
         LR    R8,R3
         LA    R9,3004
         MVCL  R6,R8
         MVI   OFIXEDR+6,C'D'    A TEST TO SEE IF DATA MOVED
***********************************************************************
*  MOVE THE DC TRAILER AREA NEXT TO OUTPUT FIXE PORTION
***********************************************************************
         LH    R4,0(,R3)         GET INPUT RDW
         SH    R4,DCLEN          SUBTRACT DC LENGTH
         STH   R4,DCDISP         MOVE DC DISPLACEMENT TO DCDISP
         LA    R10,L'DCDISP(R0,R3)  ADDRESS OF INPUT DC TRLR TO R10??
***********************************************************************
         LA    R6,ODCTR          POINT TO OUTPUT DC TRLR
         LH    R7,DCLEN          LENGHT OF MOVE
         LR    R8,R10            POINT TO INPUT DC TRLR
         LH    R9,DCLEN          LENGTH OF MOVE
         MVCL  R6,R8             MOVE DCTRLR TO OUTPUT
***********************************************************************
HEADHOME EQU *
         LA    R1,OFIXEDR        POINT R1 TO OUTPUT RECORD
         SR    R15,R15           SET RC=0
         B     GOBACK
EOF      DS    0H
         L     R15,8             SET RC=8
GOBACK   DS    0H
         L     R13,4(,R13)       POINT TO BACKWARD POINTER
         L     R14,12(,R13)      RESTORE R14
         LM    R2,R12,28(R13)    RESTORE R2 - R12
         BR    R14               GO BACK
SAVE     DS    18F
DCDISP   DS    H
FXLEN    DS    H'3004'
DCLEN    DS    H'250'
OFIXEDR  DS    0H
OFXRDW   DS    H
         DC    H'0'
OFIXED   DS    CL3000
ODCTR    DS    0C
ODCLEN   DS    H
ODCDATA  DS    CL248
         END   IMSRTEXB


So, as I tried to describe earlier, the move of the first 3004 bytes is OK. I tested this by branching from there to the HEADHOME and sort got that data back ok.

It is when I get to the LH R4,0(,R3) that things seem to go south. It seems that R4 gets a value of zero.

Steve, to answer you about the LA R10,L'DCDISP(R0,R3), I am grasping at straws here. The goal was to calculate the displacement from the beginning of the variable input record where this final 250 bytes begins. What I was attempting here is this:

Put the input record length into R4
Subtract the length of the final trailer, which is DCLEN, 250
Now, put that new value in R4.
Store that displacement value in DCDISP
Load into R10 the address at the displacement DCDISP off of R3,which is where the original input record is it. As for the base register R0, I realize that. I think I saw that in some stuff I was reading and used it. I understand it really contributes nothing here.

If I had successfully be able to get the adresss of the final 250 bytes, I have coded a MVCL to use that address. I also realize now as I type this that I don't need MVCL to move this 250 bytes, but that is what I have at the moment.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Tue Mar 25, 2014 7:09 pm    Post subject: Reply to: LH moving zero
Reply with quote

Doug,

If you plan on using labels FXLEN and DCLEN and their defined values, note that they are DS (Define Storage) and their values will be X'00's.

Instead, define them as DC (Define Constant) and you'll be good to go.

The following will work -

Code:

FXLEN    DC    AL2(L'OFIXED+4)         WILL YIELD H'3004'               
DCLEN    DC    AL2(L'ODCDATA+2)        WILL YIELD H'250'               

Regarding your other predicament, are you sure that the RDW at 0(,R3) that you're loading into R4 is a halfword? Maybe it's a fullword, in which case, change your LH to an L.

BTW, no need for apologies. We all must crawl. icon_wink.gif

HTH....
Back to top
View user's profile Send private message
Douglas Allen

New User


Joined: 24 Jul 2012
Posts: 10
Location: United States

PostPosted: Tue Mar 25, 2014 7:42 pm    Post subject:
Reply with quote

R3 still have the address of the input record, which is variable length. I used fileaid to do a hex dump of the file, here is the first record. The first 2 bytes is the length of the record. That's why I'm thinking halfword here.

Code:
F I L E - A I D  V9.3.1  25 - MAR - 2014   07.05.25                     PAGE 1
DD01=IMTD.DSA.PSM.IMACTM.RECS2000    VOL=BTLV24

REC        1 DATA 8215 CHAR     02000000000000010000181              00000001 000001  0
01801-00-001 DATA27998 ZONE 2100FFFFFFFFFFFFFFFFFFFFFFF44444444444444FFFFFFFF4FFFFFF44F44444444444444444444
                       NUMR 0700020000000000000100001810000000000000000000001000000100000000000000000000000
                            1...5...10...15...20...25...30...35...40...45...50...55...60...65...70...75...8
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Tue Mar 25, 2014 7:52 pm    Post subject: Reply to: LH moving zero
Reply with quote

Doug,

X'2017' is decimal 8215 and your Fileaid display confirms this.

Just after the Load of R3 from 0(,R2), insert the following -

Code:

         ST    R3,RECADDR        STORE RECORD-ADDRESS                         

Now, you've saved the record-address.

Just before the Load Halfword into R4 from 0(,R3), insert the following -

Code:

         L     R3,RECADDR        LOAD RECORD-ADDRESS                   

Just after your 18F save-area, insert the following -

Code:

RECADDR  DS    F                 RECORD-ADDRESS SAVEAREA                         

Give these changes a try and see how it goes.

HTH....
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Thu Mar 27, 2014 1:40 am    Post subject:
Reply with quote

Quote:
The first 2 bytes is the length of the record. That's why I'm thinking halfword here.
A Record Descriptor Word (RDW) is actually 4 bytes -- the last two bytes will be zero unless the data set is Variable Spanned (VS or VBS). Using a halfword for the length is correct, but make sure you don't try to treat the next two bytes as part of the record as they are not.
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 461
Location: The Universe

PostPosted: Thu Mar 27, 2014 2:01 am    Post subject:
Reply with quote

Robert Sample wrote:
Quote:
The first 2 bytes is the length of the record. That's why I'm thinking halfword here.
A Record Descriptor Word (RDW) is actually 4 bytes -- the last two bytes will be zero unless the data set is Variable Spanned (VS or VBS). Using a halfword for the length is correct, but make sure you don't try to treat the next two bytes as part of the record as they are not.
The only time a programmer need be concerned about the second 2 bytes in an RDW is if he is reading or writing a VS or VBS data set using BSAM and has to manually construct the record segments. A program using GET or PUT macros with a DCB that specifies BFTEK=A need not be concerned. In the last two years I've written several programs that process SMF data and never once worried about the mechanics of spanned records.
Back to top
View user's profile Send private message
Douglas Allen

New User


Joined: 24 Jul 2012
Posts: 10
Location: United States

PostPosted: Thu Mar 27, 2014 11:12 pm    Post subject: Reply to: LH moving zero
Reply with quote

Just an update, with help here and one our systems programmers that came back from vacation, I got my small program working and doing what it should.

Thanks to all!

Until next time.......
Back to top
View user's profile Send private message
dick scherrer

Site Director


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

PostPosted: Thu Mar 27, 2014 11:43 pm    Post subject:
Reply with quote

Good to hear it is working - thank you for letting us know icon_smile.gif

d
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> PL/I & Assembler All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Moving a PD to PD spoorni DFSORT/ICETOOL 8 Fri Oct 07, 2016 9:52 pm
No new posts Moving character data to smallint in db2 rikdeb DB2 5 Thu Jul 14, 2016 12:38 am
No new posts MOVING COMP-3 into binary akodakka COBOL Programming 2 Tue Dec 01, 2015 5:02 pm
No new posts CICS- Moving to High availability vicky10001 CICS 8 Fri Oct 23, 2015 7:49 pm
No new posts What is the best way for moving from ... Hooman24 All Other Mainframe Topics 0 Sun Apr 26, 2015 6:36 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us