Page 1 of 1

Doubt concerning SYSPRINT and SYSUDUMP

PostPosted: Tue Aug 20, 2013 7:42 pm
by bobguo
in the past, i have not noticed SYSPRINT can be used by us to write something we want.
i thought it's one system file, which would be created automatically when abends happened.

when we run our programs, most of time, in the JCL we added:
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*

abviously, in the programs we don't create these 2 files' DCBs, can you explain it?

though SYSPRINT can be rewrote, so SYSUDUMP can be rewrote too? thanks.

Re: OPCODE: BXLE Part 2 (analyzing PARM text)

PostPosted: Tue Aug 20, 2013 8:12 pm
by dick scherrer
Hello,

I do not understand the questions here. . .

In many programs we DO create DCBs for SYSPRINT.

What does "can be rewrote" mean? Any program can open any DCB . . .

Please clarify.

Re: OPCODE: BXLE Part 2 (analyzing PARM text)

PostPosted: Tue Aug 20, 2013 9:14 pm
by steve-myers
bobguo wrote:in the past, i have not noticed SYSPRINT can be used by us to write something we want.
i thought it's one system file, which would be created automatically when abends happened.

when we run our programs, most of time, in the JCL we added:
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*

abviously, in the programs we don't create these 2 files' DCBs, can you explain it?

though SYSPRINT can be rewrote, so SYSUDUMP can be rewrote too? thanks.
For the most part, DD names are at the discretion of the programmer. An Assembler programmer can write a DCB macro like this.
MYDCB    DCB  DDNAME=IHATEJCL
In the JCL used to run the program, in order to use the DCB, there must be a DD statement like this.
//IHATEJCL DD  ...
For the most part, the DD names are arbitrary, but a few names are used by the system. One of these names is SYSUDUMP, which can be used by the system dump program if your program abnormally terminates. Somewhere in the system dump program is a DCB macro with DDNAME=SYSUDUMP.

SYSPRINT on the other hand is only used by programs. Very early in the use of OS/360, the great, great grandfather of z/OS, a loose convention grew up that SYSPRINT was a sort of "standard" DD name to identify a data set containing data that the programmer intended to be printed, and many, though not all, system and user programs follow this standard.

The DCB macro creates a rather large data area. Somewhere this data area the macro stores the text in the DDNAME keyword as an 8 byte character string, like
         DC    CL8'IHATEJCL'
The program can change this text to anything it likes before the program opens the DCB
         MVC   DCBDDNAM,=CL8'ILOVEJCL'
Quite often in my programs you will see DCB macros with DDNAME=FILLMEIN, and you can be certain that somewhere in the program, the DD name text is replaced with the real DD name the program is using.

Re: OPCODE: BXLE Part 2 (analyzing PARM text)

PostPosted: Wed Aug 21, 2013 6:05 am
by bobguo
first, thanks very much for your replay. now i have other quesitons.

how can we set to ensure system prints SYSPRINT when program runs abnormally? because sometimes it appears, sometimes it doesn't.

can we write one file just like SYSPRINT and SYSUDUMP when program finished normally? if so, where can we read the value of EPA/PSW/GPRs/SAVE AREA/memory?
sometimes i have to create one SOC7 abend intentionally if i want to test something, because just under this condition, SYSUDUMP can only be referred.

Re: OPCODE: BXLE Part 2 (analyzing PARM text)

PostPosted: Wed Aug 21, 2013 6:21 am
by bobguo
in the past, i wrote one subprogram which can print GPRs anywhere you like in your program, but i can not find EPA/PSW where they stores.
         L    R6,4(R13)                       
         LA   R6,16(R6)                       
         LA   R7,12                           
LOOP     LA   R6,4(R6)                         
         MVC  FWORD,0(R6)                     
         UNPK DSPLY(9),FWORD(5)                 
         MVZ  DSPLY(8),=XL8'00'               
         TR   DSPLY(8),=CL16'0123456789ABCDEF'
         OI   REGNUM 1,X'F0'                   
         WTO  MF=(E,WTOBUFF)                   
         PACK REGNUMP,REGNUM                 
         AP   REGNUMP,=P'1'                   
         UNPK REGNUM,REGNUMP                 
         OI   REGNUM 1,X'F0'                   
         BCT  R7,LOOP                       

FWORD    DS F
         DS CL1
WTOBUFF  DC Y(16,0)
         DC C'R'
REGNUM   DC ZL2'0'
         DC C':'
DSPLY    DS CL8
         DS CL1
REGNUMP  DS PL2
SAVEAREA DS 18F

Re: OPCODE: BXLE Part 2 (analyzing PARM text)

PostPosted: Wed Aug 21, 2013 9:22 am
by steve-myers
bobguo wrote:...how can we set to ensure system prints SYSPRINT when program runs abnormally? because sometimes it appears, sometimes it doesn't.

can we write one file just like SYSPRINT and SYSUDUMP when program finished normally? if so, where can we read the value of EPA/PSW/GPRs/SAVE AREA/memory?
sometimes i have to create one SOC7 abend intentionally if i want to test something, because just under this condition, SYSUDUMP can only be referred.
  1. If your JCL specifies //SYSPRINT DD SYSOUT=* (or something similar), the system will print it if there is something there. You should realize that sometimes if your program abnormally terminates, it may have damaged the control areas for the data set, so there may not be anything to print.
  2. Normally, the data set specified by the SYSUDUMP DD statement will have data in it only if your program abnormally terminates.
  3. The SNAP macro, which your program can issue at any time, can print essentially all the data you seem to want. This little program is a subroutine to do a SNAP macro.
    DOSNAP   RSECT
             PUSH  PRINT
             PRINT NOGEN
             DCBD   DSORG=PS,DEVD=DA
    WA       DSECT
    SAVEAREA DS    9D
    SNAPDCBS DCB   DSORG=PS,MACRF=W,RECFM=VBA,LRECL=125,BLKSIZE=1632,     ->
                   DDNAME=SNAP
    SNAPDCB  EQU   SNAPDCBS,*-SNAPDCBS
    SNAPPARMS SNAP MF=L,DCB=*-*,SDATA=CB,PDATA=(PSW,SA,JPA,SPLS)
    SNAPPARM EQU   SNAPPARMS,*-SNAPPARMS
    OPARMS   OPEN  (*-*,OUTPUT),MF=L
    OPARM    EQU   OPARMS,*-OPARMS
             ORG   OPARM
    CPARMS   CLOSE (*-*),MF=L
    CPARM    EQU   CPARMS,*-CPARMS
             ORG   ,
             POP   PRINT
             DS    0D
    WASIZE   EQU   *-WA
    DOSNAP   RSECT
    DOSNAP   AMODE ANY
    DOSNAP   RMODE ANY
             USING WA,11
             USING *,12
             SAVE  (14,12),,*
             LR    12,15
             LA    5,WASIZE
             GETMAIN RU,LV=(5),LOC=(24,ANY)
             LR    4,1
             LR    11,1
             SR    15,15
             MVCL  4,14
             MVC   SNAPDCB,MASTDCB
             MVC   SNAPPARM,MASTSNAP
             MVC   OPARM,MASTOPEN
             OPEN  (SNAPDCB),MF=(E,OPARM)
             TM    DCBOFLGS-IHADCB+SNAPDCB,DCBOFOPN
             BO    EXECSNAP
             ABEND 201,DUMP
    EXECSNAP SNAP  DCB=SNAPDCB,MF=(E,SNAPPARM)
             MVC   CPARM,MASTCLOS
             CLOSE (SNAPDCB),MF=(E,CPARM)
             L     13,4(,13)
             LA    0,WASIZE
             FREEMAIN RU,LV=(0),A=(11)
             RETURN (14,12),T,RC=0
             PUSH  PRINT
             PRINT NOGEN
    MASTOPEN OPEN  (*-*,OUTPUT),MF=L
    MASTCLOS CLOSE (*-*),MF=L
    MASTDCB  DCB   DSORG=PS,MACRF=W,RECFM=VBA,LRECL=125,BLKSIZE=1632,     ->
                   DDNAME=SNAP
    MASTSNAP SNAP  MF=L,DCB=*-*,SDATA=CB,PDATA=(PSW,SA,JPA,SPLS)
             POP   PRINT
             END   ,

    Everything you want to know (and everything you don't want to know) about the SNAP macro can be found in Assembler Services Reference IAR-XCT for your z/OS release.

Re: OPCODE: BXLE Part 2 (analyzing PARM text)

PostPosted: Wed Aug 21, 2013 11:55 pm
by steve-myers
bobguo wrote:in the past, i wrote one subprogram which can print GPRs anywhere you like in your program, but i can not find EPA/PSW where they stores. ...
EPA? Which EPA?

PSW - The dump invoked by the SNAP macro can retrieve the PSW from a system control block called a Request Block (RB) that was active when the SNAP macro was issued. Similarly, a dump invoked from an ABEND will retrieve the registers from a control block called an SDWA (System Diagnostic Work Aarea). The ABEND handler buiids the SDWA. For your register dumper, the PSW is not available unless it was called by a LINK macro, when you can find it in the PSW in the RB that was active when the LINK macro was issued.

GPRs - For SNAP, pretty much the same as the PSW, though they are in a different RB than the PSW. For a dump after an ABEND, they are in the SDWA. For your register dumper, use the register areas in the save area active when the routine was called. Obviously register 14 will not be accurate when it is called by a LINK macro.

I will think about your register dumper more later.

Re: Doubt concerning SYSPRINT and SYSUDUMP

PostPosted: Mon Aug 26, 2013 6:35 am
by steve-myers
bobguo wrote:...abviously, in the programs we don't create these 2 files' DCBs, can you explain it? ...


DCB macros in a program can create the DCB attributes. Most of my batch programs have

PRINT DCB DSORG=PS,MACRF=PM,DDNAME=SYSPRINT,RECFM=VBA,LRECL=125

When done this way OPEN will fill in BLKSIZE, hopefully with something appropriate.

OPEN sets data set attributes in this order.

  • The DCB macro.
  • DCB attributes specified in the JCL DD statement.
  • DCB attributes specified in the data set label.
This is discussed in more detail in MVS JCL User's Guide for your z/OS release.

The SYSUDUMP data set has very restricted DCB attributes. These DCB attributes are discussed in the discussion of the SNAP macro in MVS Assembler Services Guide and MVS Assembler Services Reference IAR-XCT for your z/OS release. ABEND processing will make sure the appropriate DCB attributes are used.

Another way to store DCB attributes is in the DCB open exit. This is discussed in more detail in DFSMS Using Data Sets. Before System Determined Blksize, many of my production programs had elaborate DCB OPEN exits to perform the equivalent of System Determined Blksize, but now it's not worth the effort.

If you are wondering about the LRECL value many programs use, there is a reason. The IBM 1403 line printer was the most common printing device used in the 1960s and early 1970s, and the IBM 3203 (I think I have the correct model number), which used the printing mechanism of the 1403 was often encountered in the 1980s and 1990s. The 1403 came in a variety of line sizes. The most common were 120 characters and 132 characters. When carriage control characters are used an extra, non printing carriage control character is specified, which makes the LRECL 121 or 133. When variable length records are specified, you add 4 additional bytes for the RDW, which makes the LRECL 125 or 137. Now, of course, these values are in the nature of historical artifacts, but they are still commonly used, especially by dinosaurs like me.