IBM Mainframe Forum

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.

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.

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.In the JCL used to run the program, in order to use the DCB, there must be a DD statement like this.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, likeThe program can change this text to anything it likes before the program opens the DCB 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.

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.

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.

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.
   Select all

   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.

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

bobguo (Fri Aug 23, 2013 10:35 am)

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.

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.