Thank you. Very much. I don't know what specifically caused the S0C4, you say it was the EODAD address?
Part of the causes of my problems are most likely due to the overly pedantic way that I go about learning something new. First I got the OPEN to work. Then CLOSE, then a test PUT. Then the GET/PUT loop. When I couldn't figure out where the problem was I put an ABEND one statement after the other until I figured out what line caused the problem. This is in my ASM code: COPYFILE CSECT , COPYFILE AMODE 24 COPYFILE RMODE 24 And this is what I told the LKED: //LKED EXEC PGM=IEWL,REGION=2M,COND=(0,NE), // PARM='LIST,XREF,MAP,RENT,REUS,REFR,NCAL' //SYSPRINT DD SYSOUT=* //SYSUT1 DD UNIT=(DISK,SEP=(SYSLIN,SYSLMOD)),SPACE=(CYL,(1,1)) //SYSLMOD DD DISP=SHR,DSN=IBMUSER.LINDY.LOAD //SYSLIN DD DISP=(OLD,PASS),DSN=&&OBJ1 // DD * ENTRY COPYFILE NAME COPYFILE(R) /*EOF -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Martin Truebner Sent: Thursday, December 08, 2011 6:15 PM To: [email protected] Subject: Re: ASM Program to copy a file Lindy, here is some more >> 2. Those horrible S0C4's. First one was a S0C4-10, unknown module, >> and happened on the OPEN. How could I have debugged this? The >> problem that I found from reading (yes reading the docs, I do) the >> docs carefully, was that DCB's have to be in 24 bit mode storage. >> Whoops. Where (and what kind of) in the dump would show that >> information? If you look at the expansion of the DCB macro...you will see that EODAD is stored in a 3 byte fields. I know that the VSE LNKEDT does tell you that the module you try to link with an attribute of RMODE ANY/31 does have addresses that use only 3 bytes. I have no clue why the BINDER does not behave the same...wait, it could be that you had RMODE in the control-information for the LNKEDT/binder in which case the system determines...if s/he demands it...no need to complain - (he knows what he is doing).
