IBM Mainframe Forum

Hi folks.

I have an assembly module that reads any kind of file (V,VB,F,FB,U) and returns it to a COBOL caller.
To process the record inside my COBOL program I need some information about the record obtained inside my Assembly program.
Anyone else know an easy way to get it when I execute my GET macro.

here is my DCB:


I'm trying to use the RDJFCB macro after Opening file:


But i'm getting S0C4:


I can provide more information if needed.
Any help is apreciated...

Thanks in advance.

You have at least three problems here.

1. The DCB does not specify the address of an exit list that has an entry that points to the storage area for the JFCB,
   Select all

   ADCB     DCB   DCBE=*-*,DSORG=PS,MACRF=R,...,EXLST=*-*
   AEXLST   DC    0A(0),AL1(X'80'+7),AL3(AJFCB)
   AJFCB    DC    0XL176'0'
            IEFJFCBN ,
   ADCBE    DCBE  ...
   
   In a reenterable program, the exit list and JFCB must be in working storage, so the address of the exit list must be stored in the DCB, and the exit list must be stored in the real DCB, as opposed to the model DCB.
   Select all

            LA    0,AJFCB
            ST    0,AEXLST
            MVI   AEXLST,X'80'+7
            LA    0,AEXLST
            STCM  0,B'0111',((DCBEXLST-IHADCB)+1)+ADCB
2. As hinted at in my little example, a DCBE has a very precise format. Like a DCB, in a reenterable program, the model DCBE must be copied to your work area and its actual address must be stored in the DCB. Unlike the DCB, the exit list, and the JFCB, a DCBE can be located above the line.
   Select all

            LA    0,ADCBE
            ST    0,(DCBDCBE-IHADCB)+ADCB
   
   You probably want to do this before you open the DCB.
3. Your DCB specifies MACRF=GM. This implies you intend to use the GET macro with a record address specified. Other pieces of your code imply you want to use the READ and CHECK macros. You cannot mix the two interfaces; you must use one or the other.

In general, it is quite difficult to guess at DCB attributes based on a single block read using a DCB with RECFM=U,BLKSIZE=32760. Code that might detect if the data is V or VB might beThis code uses the DECB definition in the IHADECB macro. It calculates the actual length of the data read by the READ macro, and compares it with the possible BDW in the I/O buffer. If they are not equal, it is definitely not RECFM=V or VB.

I went back to the original post and realized you did not want to try to deduce the DCB attributes of a data set from the contents of the records. You just, mainly, want the the current record length.

Now here's the deal. With QSAM - nothing I say here applies to BSAM - for RECFM U and RECFM F, you get the current record length from DCBLRECL; for RECFM V you get the record length from the RDW.

Teasing the record format from DCBRECFM is a little more difficult since you do not want to alter DCBRECFM.
Once this sequence exits, the length of data is in a register of your choosing and the address of the data is in register 1. Setting register 0 to 4 stores the length of the RDW of a V format record into the register; the SR and AR instruction s adjust the record length to indicate the data length and data address.

The DCBRECL and DCBRECV symbols are defined in the DCBD IBM macro.

These users thanked the author steve-myers for the post:

rogelinm (Fri Sep 22, 2017 11:03 pm)

Thank you very much, @steve-myers.

My actual working code is something like this:


I'm trying to implement/merge your example in my code.

Regards.

For QSAM input, I think you're usually better off using locate mode (MACRF=GL in the DCB macro) rather than providing your own record area. This is much faster because GET does not have to move the data to your record buffer, and you don't have to provide the storage.

In your GET macro, you just need (R6) for your DCB address. A tiny hint, though: just load the DCB address into register 1, and use (1). GET does not have to copy the DCB address to register 1, and if you specify (1) rather than (R1) the macro is smart enough not to do something sort of dumb, like LR 1,R1.

Sorry,
But I didn't follow you on "SAVEREC" I suppose it's like my data area (where my record is after GET).

SAVEREC is intended to be a one byte data area - its location is up to you. The NI instruction just leaves the two bits that define the record type - F, V, or U. The DCBRECV symbol defines the two bits used for V.

rogelinm wrote:Thank you very much, @steve-myers.

My actual working code is something like this:

Select all

*
READFILE EQU   *
         L     R4,DATADRSS                 > MY DATA ADDRESS
         L     R6,FILEX                    > R6=HANDLE/MY DCB ADDRESS
*
         GET   ((R6)),0(R4)                > HERE I GET THE RECORD. WORKS OK.
*
         MVC   A273O_BUFFER_PTR,DATADRSS   > MOVE RECORD ADDRESS TO COBOL
         MVI   A273O_STATUS,C'O'           > MOVE MY SATUS (USED IN COBOL)
*
*
         B     FIMPROGR                    > RETURN TO COBOL CALLER CALLE
*

I'm trying to implement/merge your example in my code.

Regards.

Your GET is OK, but I'd use
Beginners don't appreciate that the register save area can be used as a short term work area when a subroutine (or data management macro like GET) you're calling is not using it for registers. Offset 12 in the save area is normally where register 14 is saved, though data management macros do not seem to use the "standard" convention.

These users thanked the author steve-myers for the post:

rogelinm (Mon Sep 25, 2017 11:08 pm)

Thank you very much, steve-myers.
It actually solved my 4 weeks problem... I almost gave up on this.
You are very helpful.

SOLVED.

Thanks again, Steve.

I just changed it a little...



The WKRECFM is DS B in my working area.

Regards.